The rust portability story is in the process of being addressed, by two different projects:
gcc-rs[0] adds a Rust frontend to GCC.
rustc-codegen-gcc[1] adds a GCC backend to rustc.
Both are progressing pretty well, but it will likely still take a while until they reach maturity.
> Or will this change restrict the number of platforms the Linux kernel will be usable on?
There won't be any Rust inside the Linux core, only for drivers. So no, the linux kernel will always be usable on all platforms. However, the drivers written in Rust won't be usable on platforms not supported by LLVM until a GCC alternative becomes mature.
> what will the advantages be?
There are multiple: Safety, improved stability, and developer productivity. Compile time will likely take a hit (Rust is famously slow to compile), but I don't expect a big shift in runtime performance (could be slightly better due to the extra opportunities the compiler has for optimization, but it's not super likely).
As for having any effects on Rust: it already has! A lot of unstable features got prioritized due to being necessary for the kernel, such as fallible allocations.
[0]: https://github.com/Rust-GCC/gccrs - monthly reports at https://thephilbert.io/category/gccrs-status-updates/
[1]: https://github.com/rust-lang/rustc_codegen_gcc - monthly reports at https://blog.antoyo.xyz/
One is a Rust frontend to GCC (https://github.com/Rust-GCC/gccrs) while the other is a GCC backend to the existing Rust compiler (https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-12). It might take a while for these to bear fruit, but it’ll be awesome when they do. That should address the very valid concern that the full Linux kernel won’t compile for all supported architectures.
And it’s not really a problem that the GCC effort will take time. The headline of this article implies that the Rust integration is nearly done but it’s only the beginning. Based on the issue tracker there’s years of work left to get everything working perfectly. That’s enough time to get GCC supported well.
The project discussed in the video above is a new front end to GCC (written in C++, as is typical for GCC frontends) and is developed here: https://github.com/Rust-GCC/gccrs
The other project involves plugging GCC's backend into the existing rustc frontend, and is developed here: https://github.com/rust-lang/rustc_codegen_gcc
Both projects intend to eventually allow Rust code to make use of GCC. But they will likely appeal to different sets of users: the former project appeals to people invested in the GCC ecosystem who want to use Rust without installing a whole separate toolchain, and the latter to people invested in the Rust ecosystem who want to benefit from GCC's broader target support.
Take the "defer" keyword in GNU C - it's valid in anything that has the GNU extensions but isn't standard C at all. And yet, some projects swear by it (it's not a bad feature, just nonstandard).
There's a lot of weirdness in C implementations even looking across LLVM, GNU, or even when picking which libc you want! Try porting any nontrivial project to work with musl-libc. You might find that it's not as easy as swapping in a target and building statically!
This is perhaps the whole rub with standardization - it's bought us as developers a lot, but it doesn't cover everything. The veil was kind of lifted for me when I started trying to use different Scheme implementations in a "standardized" way. I eventually gave up on that and just use whatever implementation I am most happy with (often CHICKEN, but that's a digression).
This gets more complicated with C++, which modern standards mostly requires C11, but then also doesn't support everything that C11 requires either. They're different languages but yeah, compilers are gonna disagree on some of the edges there.
[1] https://github.com/Rust-GCC/gccrs
[2] tangentially, Rust also avoids some UB discussion because the type system is a bit more complete in terms of its properties than C is, so they can resort to Option or Result when things get dicey in an API. Further, there's no official Rust ABI unlike C, so you don't have to worry about that either...
Rust has been a very stable language since Rust 1.0. They have a stellar record of keeping things working - with most code breaking being due to said code invoking UB. The edition system is a brilliant invention that allows evolving the language _without_ causing an ecosystem split. Thanks to this, Rust ends up having a much better stability story than even C++ (for whom you can't really mix and match different C++ versions).
The bootstrapping situation is really not that bad? We have mrustc (A C++ rust->C transpiler) which allows compiling modern versions of rustc (latest supported rustc version being 1.54), which we can then iteratively bootstrap from up to the latest version. And things are getting better, with gccrs[0] in particular promising a rust frontend for GCC, written in C.
As for the "curl something|bash", I suppose you're talking about rustup. You're free to download the script, and review it before installing it. And rust is also distributed many different ways. At least `curl something|bash` does not require root account, unlike `sudo apt install`, which can be very convenient. Like all things: Multiple options are generally better.
https://lwn.net/Articles/871283/ https://github.com/Rust-GCC/gccrs https://github.com/antoyo/rustc_codegen_gcc
> Please note, the compiler is in a very early stage and not usable yet for compiling real Rust programs.
> gccrs is a full alternative implementation of the Rust language ontop of GCC with the goal to become fully upstream with the GNU toolchain.
I'm happy that there's work on alternative Rust compilers though!
https://thephilbert.io/ is the primary developer's blog and has status updates.
https://github.com/antoyo/rustc_codegen_gcc https://github.com/Rust-GCC/gccrs https://github.com/sapir/gcc-rust/
I wonder how these two projects compare.
I think, ideally, there would be a concerted effort to extend LLVM compatibility to those platforms. But I don't think it's unreasonable to assume that there simply won't be--I sometimes run into problems on aarch64, and most of these are far more niche than that. As the article mentioned, it seems likely that eventually the ability for certain platforms for get support on new compilers will be a make-or-break for their ability to stay current with upgrades for a lot of the more fundamental packages.
Alternatively, I guess, there could be effort to get a new gcc-backend for more langauges; I believe there's an ongoing effort for Rust[2], but who knows down the line what that might look like. Eventually, this will probably need to come to a head.
There are already alternative compilers, though most of them are WIP, e.g. mrustc[1], rust front-end for gcc[2][3], or using cranelift[4] for the back-end.
[1] https://github.com/thepowersgang/mrustc
[2] https://github.com/sapir/gcc-rust/tree/rust