I like Rust and I'd love to see it in the Linux kernel, but not before the GCC+Rust issues are all fixed. You shouldn't need non-GCC compilers to compile Linux and from what I can tell there isn't any GCC Rust compiler that's fully equivalent to the standard Rust compiler just yet.
They say that Rust support is optional, but when the first big driver gets written in Rust it'll become mandatory. So either the Rust integration will fail and nothing important will get written in it, or it won't be optional. I'm not sure what comfort that's supposed to bring.
The GCC story isn’t that far behind - there are two complementary efforts to get GCC support into the Rust ecosystem.
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.
> It might take a while for these to bear fruit, (...)
That's the problem. There are no GCC-based Rust compilers, nor is there a fixed timeline for one to be delivered, specially in the short term.
Therefore, as the OP pointed out, as things stand either Rust in the Linux kernel is dead in the water or it poses a major problem for the Linux community.
The initial work is just scaffolding that allows using Rust for some drivers, and projects intended to test said scaffolding. (Basically, rewrites of some drivers that are already in the kernel but that are not considered to be of the greatest of quality.)
It will take quite a while yet before something important is made in Rust, and this early work can be done in parallel with the GCC-Rust work.
Yup. And if you have to use the rustc compiler that means you cannot use the rustc compiler from your repositories. Rust changes in forwards incompatible ways so fast that rustc is literally out of date and unable to compile new Rust code in less than 3 months. It's not because Rust is inherently bad, it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility.
They just assume you'll curl | rustup.whatever and install a new version of rustc every month from a third party website like every single Rust guide suggests. That's not optimal for the linux kernel. But maybe kernel dev types won't be as bad as the typical bleeding edge rust dev.
And given that rapid rate of change in Rust, I don't see how GCC can ever keep up. Maybe in 10 years when Rust is more stable.
Rust has language versions and you can specify the language version to use in your Cargo.toml file. This is possible today and it shouldn't pose a problem for the kernel at all as long as there are rules about what versions to support.
You don't need a super modern version of the spec to use Rust.
As for Rust's incompatibilities, as long as you stay clear from methods marked unstable and the nightly compiler versions you'll be fine. Rust's libraries have breaking changes, but the stable language features haven't had any since the 1.0 release as far as I'm aware.
If your problem is forwards compatibility, well, you can't use clang10 to compile the kernel either. Sometimes the version gets bumped, but it doesn't need to happen too often. I think GCC's rust compiler will keep up just fine.
> it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility.
Feels like a pretty blanket statement. I'd assume that they'd base the minimum version on Rust's editions. An edition is released every 3 years and is meant to be a solid LTS (as far as I'm aware) version of the language. If they use Rust 2021 edition, you can tell the compiler that (like C89 vs C11) and it will reject code that's newer. C has plenty of newer stuff too that isn't allowed in kernel code at the moment as well.
> Rust changes in forwards incompatible ways so fast that rustc is literally out of date and unable to compile new Rust code in less than 3 months. It's not because Rust is inherently bad, it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility.
Funnily enough, I'm using the rustc compiler from Debian repositories (who of course is not well-known for eagerness to adopt bleeding-edge), and I've not run into any Rust code that wouldn't work with that compiler.
Alternatively the sheer weight of the Linux kernel's influence means that the GCC implementation of Rust becomes the dominant one, altering the way people install and manage Rust.
Rust is good, but I also do not like the trend in every language and/or build system having its own package management with its own third party dependencies and its own custom installers separate from the distro. I understand the pragmatic problems this solves, but I think it has serious ramifications for reproducibility, security, auditing, etc.
Sympathetic, but isn't Linux like the poster child for demanding vendors and whoever maintain drivers and stuff without just leaving it working for months to years? Rust is just more bleeding edge than Linux then (which might be a substantial difference, I don't know).
Shouldn't we wait for Rust to be more stable then? I still fear that its restrictions are a bit of a fad. If it is included at one point you will hardly ever get rid of it again.
>You shouldn't need non-GCC compilers to compile Linux
Huh? What relationship the Linux kernel and GCC has?
They're independent projects. It might be handy/nice/convenient to not need non-GCC compilers to compile Linux, but it's not like it's some license requirement or project obligation on behalf of Linux
GCC supports quite a few more architectures than llvm. Kernels for these archs would not be able to use Rust in the current state. So, this will limit rust to platform specific drivers until either llvm is at parity for gcc for archs that linux is available on, or gcc's rust front-end is fully capable of compiling any rust code in the kernel.
In addition to the large maintenance effort for llvm to support so many additional back-ends, there is a non-negligible number of folks who would be very opposed to being forced to use a non-gpl compliler to build a gpl kernel.
It's a weird phrasing, but I agree on the compiler topic, maybe for other reasons: an important project like Linux should not really on a single compiler. I think it is good to have the ability to use either GCC or LLVM to build the kernel. That ensures that you don't accidentally rely on a compiler bug, no lock-in, ... .
For C and C++ code you want to be able to build with different compilers.
I think that also makes sense for Rust, the language and the compiler should be two separate things and there should be multiple compiler suppliers.
Are there arguments why this would be less relevant for Rust than C?
It should be rephrased to "Rust support in Linux shouldn't require two separate compiler toolchains", e.g. either the Rust toolchain can also compile the C parts, or the C toolchain can also compile the Rust parts (can Linux actually be built with a different C compiler than GCC yet? I thought it relies on specific GCC behaviour?)
I don't see why Rust usage in the kernel should be blocked by GCC of all things. Of course kernel has been traditionally compiled by GCC, but there was never a ban on any additional or alternative tools. There is a number of dependencies on things like make, bison and so on.
Okay but think of it this way... maybe this is creating more demand for a GCC Rust compiler. Maybe it finally gives some people the excuse or funding to do what they need to do.
Historically, the answer to that was "yeah totally." But folks have put a lot of work into getting clang to build the kernel, and IIRC Google has been building their Android kernels with clang for a few years now.
~~It's not~~ (see below) It wasn't supported directly by upstream, and in fact historically was pretty much the opposite: the intention was to not care about portability between compilers at all.
It's one thing to say developers have to add a new compiler front end for some drivers if they want to compile them; and, that some developers will just have to add it regardless.
It is wholly another to say that they need adopt a whole different code-generation regime. It adds risk, and adds to what they need to understand to know what they are building. A pro needs to understand where problems come from, and be equipped to dig down to them.
So, OK for hobbyists, but a burden for pros. It is the difference between "neat project, might succeed" and "mature". Rust stands a good chance of becoming mature in a few years, more than can be said about almost everything else.
We've known for some time now that the future would be written in Rust. If you do not have a Rust compiler in addition to a C compiler on your system, now is the time to consider installing one.
Nope, everybody knows that the future will be coded in Jakt.
Jokes aside, I bet Jakt (a completly new language) has introduced fewer language and compiler changes in the last 3 months than Rust (5-10 years old now?).
EDIT: It is very bit unfortunate that my general/off-topic comment is currently the most upvoted. I was not commenting on the Linux integration specifically. I'm a _novice and hobbyist_ when it comes to Rust.
I want to provoke a little bit, but I'm genuinely curious about the following:
I feel like the Rust ecosystem is still quite immature in a lot of areas. Just a few indicators to illustrate what I mean:
- Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language.
- Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.
- Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with.
- Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making.
I really like the language, I have _way_ more good things to say about it than bad things. But am I alone in feeling like this? Other modern language communities come with a philosophy that promotes stability and simplicity. Is the Rust community riding on the merits of Rust's unique value proposition, while forgetting some important fundamentals?
> - Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language.
I'd disagree with both of these. They may not be to your style but that doesn't make them rushed. Both features had long debates around their adoption.
> - Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.
That is irrelevant to this project. You should read the rust kernel docs to see why.
> - Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with.
Also irrelevant. This may be a criticism of Rust but it in no way affects how rust may be adopted into linux.
> - Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making.
Linus is famous for doing fashionable things and forgoing technical decision making.
I'd encourage you to go read the project docs in the kernel for this. This rust project has been ongoing for years and I believe the documentation and discussion there addresses all the issues you raise. This is not a knee jerk "fashionable" decision.
> - Both async/await [...] feel like rushed implementations
This is a recurring comment, but I would argue that it's not "rushed" but rather "incomplete" from supporting ecosystem (like a futures library being reactor-agnostic).
Async/Await is great for a couple of things, but not a silver bullet. So, apart from high-throughput network applications, (like web/app servers), you should stick to regular threads and channels. You can leverage Actor-based concurrency in your program that isn't async.
> - Rust is fashionable.
Because it's genuinely great ! I've been writing Rust code since 2018, and at that time "Golang" in titles would get all the hype. I get the urge to keep things as a secret underground in a true Hacker spirit. Relax : nobody is going to spoil Rust and Rust isn't going to become a new Javascript.
> Some projects pride themselves to not use "unsafe" code
This is normal? not having unsafe code does not guarantee absence of bugs, but at least it isolates the problematic bits in the sections marked as unsafe.
If you need unsafe, you can always use unsafe.
Battle tested codebases like bind or openssh — and many others, independently of the language of implementation — had bugs in the past. It always helps to have extra assurances. Using safe/Unsafe is one more tool to have assurances.
One thing on the plus site: a tech blogger was calling out a tournament for the fastest string tokenizer in any language. I wrote a very naive Rust tokenizer in 5 minutes max and it easily won second place. First place was a highly optimized assembler code.
I am not sure the assembler thing would handle UTF-8 as well as my incredibly low effort Rust solution tho.
What I want to say with this is: There are real, tangible advantages to the language when some noob who would shoot himself into the leg three times while writing the C/C++ equivalent manages to write safe code that performs well while not investing a lot of time.
There have been several carefully planned iterations of the Rust for Linux effort. Every iteration has addressed some feedback from senior kernel developers including Linus Torvalds. The Rust for Linux folks then worked with the Rust project to introduce these features slowly into Rust. An example of such a change is fallible memory allocation. These iteration cycles have been happening for years.
Throughout I have seen nothing but professionalism, courtesy and hard work from all parties involved here - the kernel devs, the Rust for Linux devs and the Rust project devs.
You do them all a disservice by implying that this decision was taken without “objective, technical decision making”.
> not linking with C code
I would need specific examples of C code being better than the Rust equivalent but people using the Rust equivalent anyway. I can give several counter examples. Such as libgit2, a C library with Rust bindings. It is widely used in the Rust ecosystem, including by the Rust project itself instead of the nascent gitoxide project. This shows pragmatism.
There are other examples of projects being rewritten in Rust but usually that’s ends up with the Rust version being very good. Such as when the maintainer of rsvg rewrote it in Rust. Look at the test suite results (https://github.com/RazrFalcon/resvg).
Or when someone wrote a text search tool (ripgrep) in pure Rust instead of using PCRE bindings. Look at the benchmarks (https://github.com/BurntSushi/ripgrep/blob/master/benchsuite...) - it’s faster than any competing tool on nearly all of them. If you’ve used search in VSCode, you were using ripgrep.
Or when someone wrote a pure Rust crypto library rustls when OpenSSL bindings exist. I believe the results of the security audit speak for themselves (https://github.com/rustls/rustls/blob/main/audit/TLS-01-repo...). See the comments on code quality - “Cure53 was unable to uncover any application-breaking security flaws. After spending thirty days on the scope in late May and early June of 2020, the team of auditors considered the general code quality to be exceptional and can attest to a solid impression left consistently by all scope items. Naturally, this is partially thanks to the usage of Rust as the preferred language for the entire implementation of the rustls project”
These examples show that when good developers rewrite something in Rust, we all benefit from the results. If you have an example of a Rust rewrite giving worse results, and being adopted over the C bindings, that would be helpful. I can’t recall any such instance offhand.
> Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.
Could you give examples? From what I’ve seen Rust library authors take care to only pull in what’s necessary. I’d be interested to see these libraries that pull in “unrelated” dependencies.
Note, developing in Rust doesn’t suddenly make mediocre code great. I’m sure there’s mediocre code out there, just like there is in every single ecosystem. The question is, can you get stuff done while only sticking to high quality dependencies? I think you can.
> async-await and question mark.
There is a language strangeness budget each language gets to use. Use up too much of the budget and the language feels alien to newcomers.
Rust already introduces new strange things like lifetimes. New syntax like the question mark and post-fix await strain the budget further. I’ll admit, it’s hard for new people. But I also think this syntax pulls it’s weight. This is subjective and reasonable people can disagree.
That said, these syntax decisions are set in stone. I wouldn’t wait in the hope that they might change.
Thank you for the detailed response. Some of the points are reassuring and/or interesting.
Just wanted to comment shortly on this:
> Could you give examples? From what I’ve seen Rust library authors take care to only pull in what’s necessary. I’d be interested to see these libraries that pull in “unrelated” dependencies.
I would hate to call out specific authors and crates. I would rather see a general awareness and discussion around the issue. Your comment is reassuring though.
For Scala devs this is the sane way :) (Or for anyone who likes RPN ^^) [Or for anyone who simply encountered a bit too many "(await (await x.y).z).w" expressions in other languages.]
However it represents something that I don't like, which is trading language surface complexity and readability for programmer convenience. It is not something that gives you more power, just something that makes code a bit easier to write. Also there was seemingly not that much push-back against the feature which makes me a bit uneasy. Not sure why that is to be honest.
I don't want to start a discussion about the question mark operator specifically. That's not important to me. What I like to gauge is the general culture around the language itself and the community around it. Half devil's advocate, half uncertainty driven.
While I love Rust, I think you're spot on with your concerns (apart from the questionmark operator – it's just delicious pragmatic convenience).
The culture of exploding dependency trees is a recipe for disaster, especially when combined with the prevailing attitude of "use the latest version or bust".
Yeah, I've been down this road before with Java + Maven 10-15 years ago. Exploding dependency trees, DLL hell, etc. And I see it in the (admittedly mostly foreign to me) Node/NPM world. Quantities of third party dependencies with their own graphs can be trouble. At least with Maven there was a publishing/vetting process.
This is my humble opinion, but kernel shouldn't be a place for language diversity. Even code comments should be standardized for such critical and complex project with so many participants.
And being stuck forever with a language that was invented over 50 years ago doesn't seem like a good idea either. If we want to take full advantage of the last half-century of PL research, we should just abandon Linux at some point and go with a completely new codebase instead? (Actually, that sounds kinda good to me, but I get why that may not be the best decision.)
If the internal APIs of the Linux kernel were boiled down to WebAssembly, then many kernel modules and drivers could be written in any language and cheaply isolated, making it harder, maybe impossible to corrupt kernel memory. IMHO that would lead to a more modular, robust kernel with lots of options for programming it, without resorting to a full microkernel design that has costly IPC.
With Wasm you could use any fully-featured programming language that compiles to Wasm, rather than severely-restricted and stylized C with a single toolchain that can generate BPF bytecode. Wasm has a formal specification and many high-performance implementations with near-native performance. BPF predated Wasm by a lot, yet not being a general purpose bytecode, hasn't had the engineering time invested that Wasm has.
Pardon my ignorance, but given the complexity of Rust, the incoherence of the async story etc, wouldn't something like Zig be a more reasonable choice for Linux, with its ability to be introduced gradually etc?
Zig isn't finished yet. Rust has stable language features.
You also don't need async in many if not most cases, especially if you're writing kernel code. I wouldn't want to use a kernel module that pulls in all of tokio/reqwest/hyper just like I don't want a kernel module that links against openssl.
Async makes a lot of sense for userland code, but not so much for kernel code. I haven't seen async get used in any demo for kernel Rust modules and I doubt it'll happen anyway.
Looking at a comparison between common kernel structures and theoretical Rust implementations of those (like on https://security.googleblog.com/2021/04/rust-in-linux-kernel...) I think the kernel can get improved security and reliability from Rust without any "fancy" Rust. Just the basic type system improvements, nullability improvements and explicit checks will be enough for some real benefits.
> You also don't need async in many if not most cases, especially if you're writing kernel code.
Have you seen how much communication with the hardware in drivers is actually very asynchronous? It’s all hand rolled C, of course, but there’s a lot of it.
But look at the bright side: people likely won’t be enjoying hand-rolling asynchronous Rust since language-level primitives exist, so maybe there will be enough pressure and enough of use case diversity to make a more solid implementation that doesn’t suck, or sucks way less than the current one.
Rust is mainly introduced to the kernel to allow writing safer drivers, which makes a lot of sense considering a crashing driver likely means a crashing computer.
I've ran Linux (various) for near on 20 years and ran it on hundreds servers for 15. I've only ever hit one such crash for an external piece of custom hardware with a noddy kernel module. Plenty of crashing kernel modules yea.
I'm just curious what would a panic!() in Rust kernel code look like - an oops log in dmesg? panics happen in Rust for example to handle indexing out of bounds errors with the default bounds checking or to guard against divide by zero.
The "async is bad" meme is getting old. Someone has written an article about JS's limitation (which Rust doesn't have) and how they don't like C# syntax, and it gets endlessly slapped on every language as a vague notion of "colors".
Async in Rust is incredibly well designed, and works very well for such a low-level design that minimizes heap allocations and virtual dispatch. Rust intentionally prefers locally explicit syntax for things that affect control flow, and wants to be back-end agnostic without a runtime, which goes against implicit built-in "colorless" magic.
I have no idea what I'm talking about, but rust can also be introduced gradually, and async isn't a language feature the kernel will use, actually the kernel will probably not even use the standard library because of how rust assumes it'll never run out of RAM.
Zig's safety is lower than Rust's, that's true, but it is still a very big improvement over C, so a case could be made for it in principle. But of course in practice Zig is not stable enough to consider that yet.
Anyhow, this isn't all or nothing: a case could also be made one way or the other about how much 'unsafe' to allow in Rust in the kernel. It's a question of tradeoffs.
Opinionated in the context of programming languages usually means that the language forces it's own abstractions on you, you have to work with and around them.
Zig is not like that, it's pretty much just C, but simpler, ergonomic. It's design is a reasonably simple, portable abstraction of contemporary hardware. It gives you all the power to come up with your own abstractions on top of that.
As other commenters have poked at; I'd hope that if Rust is going into the kernel (even if just for drivers), that means it's hopefully hopefully started to "calm down" as a language.
At least in regards to the features that affect kernel-level development. Stabilizing that doesn't preclude active development in things like async or in the standard library (both of which I'd expect not to see much or any use in the kernel.) But I'd hope for decent work towards backwards and forwards compatibility in the set of language features used there.
> At least in regards to the features that affect kernel-level development.
Strange you should mention this because they’ve been working on and will continue to work features to make Rust more suitable to the Linux kernel. This issue (https://github.com/Rust-for-Linux/linux/issues/355) for features in rustc was opened a year ago and it seems half done.
> backwards and forwards compatibility
Backwards compatibility has existed for 7 years, since Rust 1.0. If your code ever compiled under any version of Rust since 1.0, it will compile with all future versions. Guaranteed.
Forwards compatibility - not sure how this would be guaranteed. If your code uses a new library API, how would an old tool chain compile that? AFAIK, this is a non goal.
> calm down
I think it calmed down after async stabilised 4 years ago. I don’t recall seeing big changes since then.
On a broader note, Rust’s 6-week release cycle might make it seem like big features are being added all the time, but I don’t think this is the case. It’s usually just a few small features or conveniences, some bug fixes, minor improvements to compile times.
It hasn’t. Rust is 12 years old, has no specification, incomplete documentation, a borrow checker that won’t allow some valid code today but may allow that same code tomorrow, and a level of complexity that is seriously next level. It’s about as calm as C++ on cocaine in my opinion.
I expect that Rust will kind of fork, like Python 2.x vs 3.x (remember that?). We'll have "stable Linux rust" and "move-fast-and-break-things meme Rust". Those of us who value stability will say "Thank you Linus Torvalds" and just use the "Linux rust" for everything.
I think this is a bad idea or at least far too soon.
In my opinion the Rust language and eco system is not yet at
the stability of C.
I feel certain that mixing two different languages inside the kernel
will give all new and challenging errors to debug.
Also it is the fallacy of sunken cost.
So much work has gone into the Linux kernel, but efforts should be made
to replace it.
What I would like to see is a project to create a new and modern kernel,
taking a lot of what has been learned by the "prototype" Linux kernel and
create something new and better.
It would also be free to take full advantage of the language improvements
between Rust and C.
Sure it would take a lot of time, but I think it is time well invested, instead
of slowing trying to port the current Linux kernel to Rust.
> So much work has gone into the Linux kernel, but efforts should be made to replace it.
Plenty of people are working on new kernels and operating systems both by hobbyists and companies (c.f. Redox[0], Fuscia (zircon kernel[1], e.t.c.).
The main problem is that linux is an incredibly well developed piece of software, so it will take a very long time for anything to reach feature parity.
> instead of slowing trying to port the current Linux kernel to Rust.
I don't think anyone is suggesting to try and port the current kernel to Rust (and I'm fairly sure any suggestions in that direction would be met with a hard no from linus.) The current suggestion is just to allow language bindings to facilitate the writing of drivers in rust.
Even looking to the future which could see some critical components of the kernel written in rust, I don't think anyone is suggesting that the entire kernel should be ported, since that's a monumental task (and suffers from the exact same issue as above, for questionable benefit).
Readit News
They say that Rust support is optional, but when the first big driver gets written in Rust it'll become mandatory. So either the Rust integration will fail and nothing important will get written in it, or it won't be optional. I'm not sure what comfort that's supposed to bring.
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.
That's the problem. There are no GCC-based Rust compilers, nor is there a fixed timeline for one to be delivered, specially in the short term.
Therefore, as the OP pointed out, as things stand either Rust in the Linux kernel is dead in the water or it poses a major problem for the Linux community.
It will take quite a while yet before something important is made in Rust, and this early work can be done in parallel with the GCC-Rust work.
They just assume you'll curl | rustup.whatever and install a new version of rustc every month from a third party website like every single Rust guide suggests. That's not optimal for the linux kernel. But maybe kernel dev types won't be as bad as the typical bleeding edge rust dev.
And given that rapid rate of change in Rust, I don't see how GCC can ever keep up. Maybe in 10 years when Rust is more stable.
You don't need a super modern version of the spec to use Rust.
As for Rust's incompatibilities, as long as you stay clear from methods marked unstable and the nightly compiler versions you'll be fine. Rust's libraries have breaking changes, but the stable language features haven't had any since the 1.0 release as far as I'm aware.
If your problem is forwards compatibility, well, you can't use clang10 to compile the kernel either. Sometimes the version gets bumped, but it doesn't need to happen too often. I think GCC's rust compiler will keep up just fine.
Feels like a pretty blanket statement. I'd assume that they'd base the minimum version on Rust's editions. An edition is released every 3 years and is meant to be a solid LTS (as far as I'm aware) version of the language. If they use Rust 2021 edition, you can tell the compiler that (like C89 vs C11) and it will reject code that's newer. C has plenty of newer stuff too that isn't allowed in kernel code at the moment as well.
Funnily enough, I'm using the rustc compiler from Debian repositories (who of course is not well-known for eagerness to adopt bleeding-edge), and I've not run into any Rust code that wouldn't work with that compiler.
Rust is good, but I also do not like the trend in every language and/or build system having its own package management with its own third party dependencies and its own custom installers separate from the distro. I understand the pragmatic problems this solves, but I think it has serious ramifications for reproducibility, security, auditing, etc.
Huh? What relationship the Linux kernel and GCC has?
They're independent projects. It might be handy/nice/convenient to not need non-GCC compilers to compile Linux, but it's not like it's some license requirement or project obligation on behalf of Linux
In addition to the large maintenance effort for llvm to support so many additional back-ends, there is a non-negligible number of folks who would be very opposed to being forced to use a non-gpl compliler to build a gpl kernel.
https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Archit...
https://en.wikipedia.org/wiki/LLVM#Back_ends
https://en.wikipedia.org/wiki/List_of_Linux-supported_comput...
For C and C++ code you want to be able to build with different compilers.
I think that also makes sense for Rust, the language and the compiler should be two separate things and there should be multiple compiler suppliers.
Are there arguments why this would be less relevant for Rust than C?
If other compilers implement compatible features such that they can compile the kernel, fine. But gcc has been the supported compiler.
* The kernel requires stability. Building a kernel w/ rustc is like building a house on a flying bullet.
* GCC is insanely good at porting to other architectures, something vendors have been relying on for a long long time.
* Consistency in applying compile flags and optimizations.
Idk, these are all I can think of right now.
Why?
~~It's not~~ (see below) It wasn't supported directly by upstream, and in fact historically was pretty much the opposite: the intention was to not care about portability between compilers at all.
It is wholly another to say that they need adopt a whole different code-generation regime. It adds risk, and adds to what they need to understand to know what they are building. A pro needs to understand where problems come from, and be equipped to dig down to them.
So, OK for hobbyists, but a burden for pros. It is the difference between "neat project, might succeed" and "mature". Rust stands a good chance of becoming mature in a few years, more than can be said about almost everything else.
Jokes aside, I bet Jakt (a completly new language) has introduced fewer language and compiler changes in the last 3 months than Rust (5-10 years old now?).
For example this comment https://news.ycombinator.com/item?id=31849071 is much more interesting and on topic.
---
I want to provoke a little bit, but I'm genuinely curious about the following:
I feel like the Rust ecosystem is still quite immature in a lot of areas. Just a few indicators to illustrate what I mean:
- Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language.
- Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.
- Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with.
- Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making.
I really like the language, I have _way_ more good things to say about it than bad things. But am I alone in feeling like this? Other modern language communities come with a philosophy that promotes stability and simplicity. Is the Rust community riding on the merits of Rust's unique value proposition, while forgetting some important fundamentals?
I'd disagree with both of these. They may not be to your style but that doesn't make them rushed. Both features had long debates around their adoption.
> - Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.
That is irrelevant to this project. You should read the rust kernel docs to see why.
> - Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with.
Also irrelevant. This may be a criticism of Rust but it in no way affects how rust may be adopted into linux.
> - Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making.
Linus is famous for doing fashionable things and forgoing technical decision making.
Has he changed his mind about those things? Or does he not realize they are there, and that kernel code will use them?
This is a recurring comment, but I would argue that it's not "rushed" but rather "incomplete" from supporting ecosystem (like a futures library being reactor-agnostic).
Async/Await is great for a couple of things, but not a silver bullet. So, apart from high-throughput network applications, (like web/app servers), you should stick to regular threads and channels. You can leverage Actor-based concurrency in your program that isn't async.
> - Rust is fashionable.
Because it's genuinely great ! I've been writing Rust code since 2018, and at that time "Golang" in titles would get all the hype. I get the urge to keep things as a secret underground in a true Hacker spirit. Relax : nobody is going to spoil Rust and Rust isn't going to become a new Javascript.
This is normal? not having unsafe code does not guarantee absence of bugs, but at least it isolates the problematic bits in the sections marked as unsafe.
If you need unsafe, you can always use unsafe.
Battle tested codebases like bind or openssh — and many others, independently of the language of implementation — had bugs in the past. It always helps to have extra assurances. Using safe/Unsafe is one more tool to have assurances.
I am not sure the assembler thing would handle UTF-8 as well as my incredibly low effort Rust solution tho.
What I want to say with this is: There are real, tangible advantages to the language when some noob who would shoot himself into the leg three times while writing the C/C++ equivalent manages to write safe code that performs well while not investing a lot of time.
There have been several carefully planned iterations of the Rust for Linux effort. Every iteration has addressed some feedback from senior kernel developers including Linus Torvalds. The Rust for Linux folks then worked with the Rust project to introduce these features slowly into Rust. An example of such a change is fallible memory allocation. These iteration cycles have been happening for years.
Check out the issues, especially the “wanted features and bugfixes” for each rust component (https://github.com/Rust-for-Linux/linux/issues?page=2&q=is%3...) for more details into all the work that’s happened here.
Throughout I have seen nothing but professionalism, courtesy and hard work from all parties involved here - the kernel devs, the Rust for Linux devs and the Rust project devs.
You do them all a disservice by implying that this decision was taken without “objective, technical decision making”.
> not linking with C code
I would need specific examples of C code being better than the Rust equivalent but people using the Rust equivalent anyway. I can give several counter examples. Such as libgit2, a C library with Rust bindings. It is widely used in the Rust ecosystem, including by the Rust project itself instead of the nascent gitoxide project. This shows pragmatism.
There are other examples of projects being rewritten in Rust but usually that’s ends up with the Rust version being very good. Such as when the maintainer of rsvg rewrote it in Rust. Look at the test suite results (https://github.com/RazrFalcon/resvg).
Or when someone wrote a text search tool (ripgrep) in pure Rust instead of using PCRE bindings. Look at the benchmarks (https://github.com/BurntSushi/ripgrep/blob/master/benchsuite...) - it’s faster than any competing tool on nearly all of them. If you’ve used search in VSCode, you were using ripgrep.
Or when someone wrote a pure Rust crypto library rustls when OpenSSL bindings exist. I believe the results of the security audit speak for themselves (https://github.com/rustls/rustls/blob/main/audit/TLS-01-repo...). See the comments on code quality - “Cure53 was unable to uncover any application-breaking security flaws. After spending thirty days on the scope in late May and early June of 2020, the team of auditors considered the general code quality to be exceptional and can attest to a solid impression left consistently by all scope items. Naturally, this is partially thanks to the usage of Rust as the preferred language for the entire implementation of the rustls project”
These examples show that when good developers rewrite something in Rust, we all benefit from the results. If you have an example of a Rust rewrite giving worse results, and being adopted over the C bindings, that would be helpful. I can’t recall any such instance offhand.
> Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.
Could you give examples? From what I’ve seen Rust library authors take care to only pull in what’s necessary. I’d be interested to see these libraries that pull in “unrelated” dependencies.
Note, developing in Rust doesn’t suddenly make mediocre code great. I’m sure there’s mediocre code out there, just like there is in every single ecosystem. The question is, can you get stuff done while only sticking to high quality dependencies? I think you can.
> async-await and question mark.
There is a language strangeness budget each language gets to use. Use up too much of the budget and the language feels alien to newcomers.
Rust already introduces new strange things like lifetimes. New syntax like the question mark and post-fix await strain the budget further. I’ll admit, it’s hard for new people. But I also think this syntax pulls it’s weight. This is subjective and reasonable people can disagree.
That said, these syntax decisions are set in stone. I wouldn’t wait in the hope that they might change.
Just wanted to comment shortly on this:
> Could you give examples? From what I’ve seen Rust library authors take care to only pull in what’s necessary. I’d be interested to see these libraries that pull in “unrelated” dependencies.
I would hate to call out specific authors and crates. I would rather see a general awareness and discussion around the issue. Your comment is reassuring though.
For Scala devs this is the sane way :) (Or for anyone who likes RPN ^^) [Or for anyone who simply encountered a bit too many "(await (await x.y).z).w" expressions in other languages.]
However it represents something that I don't like, which is trading language surface complexity and readability for programmer convenience. It is not something that gives you more power, just something that makes code a bit easier to write. Also there was seemingly not that much push-back against the feature which makes me a bit uneasy. Not sure why that is to be honest.
I don't want to start a discussion about the question mark operator specifically. That's not important to me. What I like to gauge is the general culture around the language itself and the community around it. Half devil's advocate, half uncertainty driven.
https://users.rust-lang.org/t/name-squatting-on-the-crates-i...
The culture of exploding dependency trees is a recipe for disaster, especially when combined with the prevailing attitude of "use the latest version or bust".
Still, it makes dev a lot easier.
Actually, a third language. The Linux kernel already has two: C and assembly.
Deleted Comment
You also don't need async in many if not most cases, especially if you're writing kernel code. I wouldn't want to use a kernel module that pulls in all of tokio/reqwest/hyper just like I don't want a kernel module that links against openssl.
Async makes a lot of sense for userland code, but not so much for kernel code. I haven't seen async get used in any demo for kernel Rust modules and I doubt it'll happen anyway.
Looking at a comparison between common kernel structures and theoretical Rust implementations of those (like on https://security.googleblog.com/2021/04/rust-in-linux-kernel...) I think the kernel can get improved security and reliability from Rust without any "fancy" Rust. Just the basic type system improvements, nullability improvements and explicit checks will be enough for some real benefits.
Have you seen how much communication with the hardware in drivers is actually very asynchronous? It’s all hand rolled C, of course, but there’s a lot of it.
But look at the bright side: people likely won’t be enjoying hand-rolling asynchronous Rust since language-level primitives exist, so maybe there will be enough pressure and enough of use case diversity to make a more solid implementation that doesn’t suck, or sucks way less than the current one.
Async in Rust is incredibly well designed, and works very well for such a low-level design that minimizes heap allocations and virtual dispatch. Rust intentionally prefers locally explicit syntax for things that affect control flow, and wants to be back-end agnostic without a runtime, which goes against implicit built-in "colorless" magic.
Why not thought? Lots of drivers could benefit from async to simplify their state machine as they wait for interrupt for example.
The reason Rust is interesting in the space is the memory safety without a GC. Zig doesn't have that.
Anyhow, this isn't all or nothing: a case could also be made one way or the other about how much 'unsafe' to allow in Rust in the kernel. It's a question of tradeoffs.
Rust is superopinionated. Big and complex as well.
Zig is not like that, it's pretty much just C, but simpler, ergonomic. It's design is a reasonably simple, portable abstraction of contemporary hardware. It gives you all the power to come up with your own abstractions on top of that.
Deleted Comment
At least in regards to the features that affect kernel-level development. Stabilizing that doesn't preclude active development in things like async or in the standard library (both of which I'd expect not to see much or any use in the kernel.) But I'd hope for decent work towards backwards and forwards compatibility in the set of language features used there.
Strange you should mention this because they’ve been working on and will continue to work features to make Rust more suitable to the Linux kernel. This issue (https://github.com/Rust-for-Linux/linux/issues/355) for features in rustc was opened a year ago and it seems half done.
> backwards and forwards compatibility
Backwards compatibility has existed for 7 years, since Rust 1.0. If your code ever compiled under any version of Rust since 1.0, it will compile with all future versions. Guaranteed.
Forwards compatibility - not sure how this would be guaranteed. If your code uses a new library API, how would an old tool chain compile that? AFAIK, this is a non goal.
> calm down
I think it calmed down after async stabilised 4 years ago. I don’t recall seeing big changes since then.
On a broader note, Rust’s 6-week release cycle might make it seem like big features are being added all the time, but I don’t think this is the case. It’s usually just a few small features or conveniences, some bug fixes, minor improvements to compile times.
In my opinion the Rust language and eco system is not yet at the stability of C.
I feel certain that mixing two different languages inside the kernel will give all new and challenging errors to debug.
Also it is the fallacy of sunken cost.
So much work has gone into the Linux kernel, but efforts should be made to replace it.
What I would like to see is a project to create a new and modern kernel, taking a lot of what has been learned by the "prototype" Linux kernel and create something new and better.
It would also be free to take full advantage of the language improvements between Rust and C.
Sure it would take a lot of time, but I think it is time well invested, instead of slowing trying to port the current Linux kernel to Rust.
Plenty of people are working on new kernels and operating systems both by hobbyists and companies (c.f. Redox[0], Fuscia (zircon kernel[1], e.t.c.).
The main problem is that linux is an incredibly well developed piece of software, so it will take a very long time for anything to reach feature parity.
> instead of slowing trying to port the current Linux kernel to Rust.
I don't think anyone is suggesting to try and port the current kernel to Rust (and I'm fairly sure any suggestions in that direction would be met with a hard no from linus.) The current suggestion is just to allow language bindings to facilitate the writing of drivers in rust.
Even looking to the future which could see some critical components of the kernel written in rust, I don't think anyone is suggesting that the entire kernel should be ported, since that's a monumental task (and suffers from the exact same issue as above, for questionable benefit).
[0] https://www.redox-os.org/
[1] https://fuchsia.dev/fuchsia-src/concepts/kernel