boris at codesynthesis.com
Tue Jan 21 09:30:55 UTC 2020
[CC'ing users at build2.org to a reply from private conversation]
Matthew Krupcale <mkrupcale at matthewkrupcale.com> writes:
> My interest in Rust is primarily due to the fact that it is marketed
> as a compiled, "systems" programming language focused on achieving
> high performance with memory safety. This has garnered it a lot of
> popularity lately, although I myself still prefer C++ for several
> reasons, including:
> 1. it still hasn't really achieved performance parity with C++ in many cases
> 2. its compile times are even (far?) worse than C++
> 3. it is focused on building statically linked artifacts which do not
> integrate well with the traditional Linux FOSS ecosystem
While that's the default, there is support for producing shared
libraries. I agree this can't be ignored forever but making shared
library builds usable across platforms is not easy (to put it very
mildly and based on personal experience). And so I can't really blame
them for ignoring this mess for the time being.
Maybe we can help on this front seeing that we made it work for C/C++.
> 4. its crates packaging system, while it allows for easy integration
> of external projects into ones own (this is a nice feature to have in
> general, including for C++), also comes with the downside of creating
> large dependency chains typical of most other language-level package
> managers (although maybe not quite as bad as e.g. NPM since the bar
> for writing something useful is higher for Rust than JS, I would say)
> 5. it lacks toolchain diversity (i.e. it's still a monolithic system
> built around LLVM). This also means it doesn't support as many target
> architectures (although maybe not ones about which most people care).
Yes, that's true, though there is talk about having a Rust frontend in
GCC. Whether it will result in anything and if so, how soon, is another
question, of course. Also, having multiple backends will probably slow
down the language evolution.
BTW, it just occurred to me that the same toolchain diversity argument
can be applies to languages: it would be nice to have alternatives when
it comes to C++.
> 6. C++ is still more capable with respect to things like templates I believe
> That said, I have worked on some Rust projects (albeit mostly
> peripherally, i.e. mostly insofar as the project uses C/C++) and have
> learned a little bit about how the language/tooling works to some
> extent, but I'm not sure I know any more than you might. I have also
> peripherally watched what Meson has done with Rust (Meson has become
> pretty popular in GNOME projects, some of which also use Rust), and I
> believe they are mostly limited to projects which are fully
> self-contained (i.e. no external crate dependencies) because Cargo
> is such a complex system that the Rust devs so far[2,3] have not
> designed to allow any other build system to replicate the complicated
> (and ever changing) incantations necessary to invoke rustc for a given
> "real-world" project (Meson specifically wanted to deal with Rust by
> invoking rustc itself, like all other languages). Thus, they
> haven't really bothered so far trying to create some sort of API which
> alternative build-systems could use, and much like the Rust language
> itself, the single, monolithic implementation of Cargo and the Rust
> toolchain is the de facto standard as opposed to some more general
> "Rust 2018" standard.
Yes, we also would want to invoke rustc ourselves, at least for the
project's (as opposed to dependencies) source code.
I've been thinking about this (and this idea is also echoed in the
issues you have linked): it feels like we need some sort of "foreign
package" support in build2 that can be used to consume dependencies
from other package managers.
> > I've been looking into writing a build2 build system module for
> > Rust compilation.
> I saw you had created a new repo for it on GH, but given everything I
> mentioned above, I'm not sure it's currently feasible to make a proper
> build2 module for Rust unless you:
> 1. limit it to fully self-contained crates as Meson currently does
> 2. fully utilize and depend on both Cargo (along with its heavy
> reliance on crates.io) for invoking rustc and building Rust artifacts
For starters I am focusing on (1) but we will want to figure out (2)
at some point as well. There is only so far you can get in Rust without
I also want to explore the mixed (e.g., C/C++ and Rust) applications
If anyone is interested in working on this, let me know.
> Even these though don't really address the linkage issues associated
> with Rust (see point 3 above).
Yes, and I would like to look into this. Specifically, we will probably
want to customize the linking step to control what linker/options are
used so that we can make sure they are the same as what our cc module
is using and take advantage of things like rpath, etc. Interestingly,
I looked into how Bazel (currently) does it, and it's the same idea
(i.e., invoke rustc but instruct it to use our linker/options).
> Unless I'm mistaken, the current approach Fedora has taken to packaging
> Rust is that the crates (which I believe are basically just tar archives
> of the Rust source code) are equivalent to -devel packages only used
> during build time to produce the various static artifacts which are
> the actually distributed binaries.
Yes, and I believe this is true for Debian as well.
> All of this is to say that I more or less have avoided Rust because
> despite its claimed advantages, they cannot (or have not prioritized)
> seem to make a system which integrates well with the traditional Linux
> ecosystem in an implementation-agnostic way. As a Linux packager, this
> is important to me.
>  https://github.com/mesonbuild/meson/issues/2173
>  https://github.com/rust-lang/cargo/issues/5579
>  https://github.com/rust-lang/cargo/issues/7614
>  https://github.com/mesonbuild/meson/pull/2617
Thanks for the links. A couple of interesting/relevant ones from my side:
Crate dependency discovery: https://internals.rust-lang.org/t/crate-dependency-discovery/11418
Safe interop between Rust and C++: https://github.com/dtolnay/cxx
Cross-language (C/C++ and Rust) LTO: http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html
More information about the users