[build2] Rust

Tue Jan 21 14:28:04 UTC 2020

On Tue, Jan 21, 2020 at 4:31 AM Boris Kolpackov <boris at codesynthesis.com> wrote:
>
> While that's the default, there is support for producing shared
> libraries.

Yeah, I know there is some sort of support for producing them, but it
seems to me like they're not used much in practice (except the
standard library?).

> Maybe we can help on this front seeing that we made it work for C/C++.

Perhaps so, but Rust also would have to make this an explicit goal
(i.e. to prefer shared linking over static linking), and I'm not sure
that's the case or if they even think it's desirable. Funnily enough,
it looks like Rust might use the same name-mangling as for C++:

$ readelf -Ws /usr/lib64/libstd-5420060374c44e8e.so | c++filt | less

> 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.

Yeah, I saw discussions around that as well, but I came away from them
thinking if and when they do make a "GCC frontend", they're still
going to be relying on the rustc frontend[1,2]. This has the obvious
advantage of re-using the fast-moving rustc FE, but then it's not
really an independent implementation.

Also, having multiple backends will probably slow down the language evolution.

I'm not sure the backends are the bottleneck for Rust language
evolution, though, are they? From the discussions around the GCC FE,
it seemed like MIR output of rustc was relatively stable, whereas the
language FE itself is evolving more rapidly.

> 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++.

I'm not sure this scales in the same way that multiple implementations
of a given standard/language does. LLVM and GCC are more or less
substitutable for one another for a given language, but the same does
not hold for developing and (more importantly) learning a new
language. New languages fracture development and end users, whereas
new implementations of a standard create competition while re-using
existing skills/knowledge and tooling/infrastructure.

There are many reasons that D, Rust, and Circle[3] have not or are
unlikely to replace C++ any time soon, but the high cost relative to
the small gains of learning a new language is probably foremost among
them. At the end of the day, it seems to me like developers are the
bottleneck, whereas there's a pretty low cost of substituting a
compiler implementation for a given language.

Of course, C++ evolves as well, but it evolves in a way which is
incremental (in the sense that it is mostly additive and consistent
with the existing foundations) and controlled. One could argue that
this is a disadvantage compared to e.g. the rapid development of Rust,
but I think C++ is in the right place in terms of speed of development
of new features--too fast, and you risk a chaotic bombardment of
ideas/features that do not work well (together); too slow, and you
risk stagnation and obsolescence. But I digress.

> Yes, we also would want to invoke rustc ourselves, at least for the
> project's (as opposed to dependencies) source code.

Yeah, this is probably preferable.

> 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.

In principle, build2 has one already: pkg-config. The problem is I
guess this is mostly only useful for C/C++(/fortran?) packages, and
not all C/C++ projects provide pkg-config files. So yeah, you're
probably right that there needs to be a way to consume packages from
other package managers.

> 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
> external crates.

Sounds reasonable.

> I also want to explore the mixed (e.g., C/C++ and Rust) applications more.

Yeah, that would be useful, especially for projects which are
transitioning from C/C++ to Rust (e.g. librsvg).

> 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).

Sounds reasonable.

> Yes, and I believe this is true for Debian as well.

Good to know.

> Thanks for the links.

No problem.

> Crate dependency discovery:          https://internals.rust-lang.org/t/crate-dependency-discovery/11418

Interesting read. Seems like this is still unresolved, though, and
it's unclear if there's interest in improving the dependency
discovery.

> Cross-language (C/C++ and Rust) LTO: http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html

I've seen this, and it's good to see someone working on it, but unless
I'm mistaken, the GCC LTO is more comprehensive (i.e. whole program)
than LLVM LTO[4], so it'd be nice to have the same capability in GCC.

[1] https://github.com/sapir/gcc-rust/tree/rust#how-does-it-work
[2] https://www.bountysource.com/issues/86138921-rfe-add-a-frontend-for-the-rust-programming-language
[3] https://www.circle-lang.org/
[4] http://hubicka.blogspot.com/2018/12/even-more-fun-with-building-and.html