Rust GCC back end was officially accepted into the compiler
github.com
github.com
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.
(This outcome is probably also bad, to be clear, but maybe of less practical consequence to people who continue to use mainline rustc.)
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.
I'd bet that having exactly two implementations will be a good place to be
I think you're probably right that two Rust implementations with a cooperative mentality would be a good thing in the long run.
As for your list, I never had many issues keeping a code compiling across MSVC, aCC, xlC, SunPro, GCC.
In fact aCC on HP-UX 11 was the one that gave me more problems.
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.
Most features can be added on to an experimental version of the existing code base, or done as a prototype. Not much needs a full competing compiler.
I rather not be using edlin of programming languages when given the option.
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.
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.
https://github.com/rust-lang/compiler-team/issues/442#issuec...
It does however mean that if you distribute rustc with this GCC backend, you have to comply with the GPLv3.