As background, this is a separate effort from the "GCC Rust" project.
This project is using libgccjit, which is basically a library interface to GCC (intended for JITs, but here being used for ahead-of-time compilation), as an alternative to LLVM for the standard Rust compiler ("rustc" aka https://github.com/rust-lang/rust). This allows reusing all the logic inside the Rust compiler for compiling code, checking types and lifetimes, etc. while targeting platforms that LLVM does not support.
The GCC Rust project https://rust-gcc.github.io/ is an alternative implementation of Rust inside the GCC project, in much the same way that, say, gccgo is an alternative implementation of Go or GCJ is an alternative implementation of Java. It's adding a Rust frontend to GCC, instead of adding a GCC backend to rustc.
From a pure functionality standpoint, the libgccjit approach is preferable, because as soon as a feature is in rustc, it's usable. You share the same implementation.
Personally, I'm very happy to see it approved because it immediately solves a difficult issue with getting Rust into the Linux kernel - that the Linux kernel supports many more architectures than LLVM does, and rustc doesn't even support all of those (https://github.com/fishinabarrel/linux-kernel-module-rust/is... is where things were last time I looked in detail), and without some answer for how to get things to compile on every architecture, Rust kernel code will have to be limited to drivers that are only used on architectures that Rust supports.
From an avoiding-monoculture standpoint, GCC Rust is preferable specifically because it's an alternative implementation. I think it will be good, long-term, to have that as an option too.
Also, as I understand it, a reason that the company behind grsecurity is sponsoring GCC Rust is that they have various GCC compiler plugins for hardening, and those would apply straightforwardly to GCC Rust, but they wouldn't necessarily apply to libgccjit. From https://opensrcsec.com/open_source_security_announces_rust_g... :
> As the source of the GCC plugin infrastructure in the Linux kernel and nearly all of the GCC plugins adapted for inclusion in the upstream Linux kernel, we too immediately spotted the importance of this problem and set out to ensure both those plugins as well as the security features built-in to GCC itself are able to instrument code from all languages supported by the Linux kernel with compatible and consistent security properties.
I disagree that multiple frontend implementations is going to be a good thing for Rust. Multiple backends is great, but multiple frontends could result in Rust getting held back to the lowest common denominator. C and C++ have multiple frontends because of proprietary nonsense. Rust doesn’t have that problem.
Multiple implementations allows for competition by novel approaches. (It doesn’t guarantee that that’s the way it’ll work out, but it makes it possible.)
Look at browsers: IE stagnated, Firefox got things going again, and IE eventually improved. And then as Firefox had become bloated, Chrome came along and showed that better performance was possible, and so Firefox improved as effort to match Chrome was exerted.
Or npm: it got mired as people couldn’t agree on the way to resolve some pretty big issues (centring on performance), so some people started Yarn, and its success helped unstick npm, so that now many that had switched to Yarn were able to move back to npm once it caught up again.
And these are just a couple of examples I’m familiar with.
Yes, there are costs to diversity of implementation, but there are benefits. The reasons why multiple backends is great can largely apply to multiple frontends.
Rust’s backend and frontend are both performance bottlenecks. One perfectly plausible course of events is that someone builds a new Rust compiler focused on end-to-end performance. That could help both the ecosystem and rustc.
Now, that may be true. (Or it may not be. I won’t judge the matter.) In ten years’ time? Again maybe, maybe not; but history of parallel cases suggests it’s less likely to be true in time to come than it is likely to be true now.
FWIW, an alternative outcome to lowest-common-denominator is what's happened with, for example, alternative Python implementations: there's still a main blessed one, most library authors don't care about whether or not anything works on any of the others, and users who want to avail themselves of the benefits of one of the alternatives (e.g., better runtime performance on PyPy) probably just can't, if the libraries they need aren't supported, unless they go to the effort of adding support themselves.
(This outcome is probably also bad, to be clear, but maybe of less practical consequence to people who continue to use mainline rustc.)
Yeah, that outcome is still pretty bad. I don’t think there’s any value gained from multiple frontends here. It’s unlike the PyPy situation in that a Rust GCC frontend is not going to have better performance, at least at runtime, from rustc with a GCC backend. Any compile performance differences could be resolved.
> I disagree that multiple frontend implementations is going to be a good thing for Rust.
Specialization, GATs, and const generics that aren't painfully limited are taking a very long time to deliver. As a selfish user I would love to see a Clang vs GCC style friendly rivalry develop.
As a counterargument, the web platform has multiple "frontends" (multiple, unrelated codebases that interpret HTML and JS and CSS, not just multiple engines/renderers), and the argument to avoid the monoculture seems good there.
Although, hm, I suppose you could argue that if there were one libhtml5 and Gecko and Blink and WebKit all used that, but they had different "backends," that might be even better than the current situation - that the value of having multiple web browsers is in the equivalent to the backends, not in the equivalent to the frontends.
This is new, though. Back in the 90s and early 2000s the compiler situation for C++ held back the language because the intersection of features from the "standard" available through both MSCV and GCC wasn't ideal. Both were good compilers. But in different ways.
Nowadays it's pretty trivial to get a codebase to compile across MSVC, GCC and Clang. Back then it was often weeks and weeks of work.
This sounds like a social issue though (compiler teams cooperating and keeping things up to date). It seems like when you have a smaller number of implementations they tend to be more agile; look at the modern web browser landscape vs that of the 2000s, for example
I'd bet that having exactly two implementations will be a good place to be
Yes, it was definitely social at least in part because MS leadership at that time didn't see something like GCC as a legitimate partner to cooperate with. They wanted open source to go away. Things definitely changed in that regard later.
I think you're probably right that two Rust implementations with a cooperative mentality would be a good thing in the long run.
As long as the current rustc front end is the canonical one I think it’ll end up fine. As the parent post explains, there are niches that want the gcc frontend and they should be able to get it.
This project is using libgccjit, which is basically a library interface to GCC (intended for JITs, but here being used for ahead-of-time compilation), as an alternative to LLVM for the standard Rust compiler ("rustc" aka https://github.com/rust-lang/rust). This allows reusing all the logic inside the Rust compiler for compiling code, checking types and lifetimes, etc. while targeting platforms that LLVM does not support.
The GCC Rust project https://rust-gcc.github.io/ is an alternative implementation of Rust inside the GCC project, in much the same way that, say, gccgo is an alternative implementation of Go or GCJ is an alternative implementation of Java. It's adding a Rust frontend to GCC, instead of adding a GCC backend to rustc.
From a pure functionality standpoint, the libgccjit approach is preferable, because as soon as a feature is in rustc, it's usable. You share the same implementation.
Personally, I'm very happy to see it approved because it immediately solves a difficult issue with getting Rust into the Linux kernel - that the Linux kernel supports many more architectures than LLVM does, and rustc doesn't even support all of those (https://github.com/fishinabarrel/linux-kernel-module-rust/is... is where things were last time I looked in detail), and without some answer for how to get things to compile on every architecture, Rust kernel code will have to be limited to drivers that are only used on architectures that Rust supports.
From an avoiding-monoculture standpoint, GCC Rust is preferable specifically because it's an alternative implementation. I think it will be good, long-term, to have that as an option too.
Also, as I understand it, a reason that the company behind grsecurity is sponsoring GCC Rust is that they have various GCC compiler plugins for hardening, and those would apply straightforwardly to GCC Rust, but they wouldn't necessarily apply to libgccjit. From https://opensrcsec.com/open_source_security_announces_rust_g... :
> As the source of the GCC plugin infrastructure in the Linux kernel and nearly all of the GCC plugins adapted for inclusion in the upstream Linux kernel, we too immediately spotted the importance of this problem and set out to ensure both those plugins as well as the security features built-in to GCC itself are able to instrument code from all languages supported by the Linux kernel with compatible and consistent security properties.