Rust Support In The Linux Kernel Undergoing Another Round Of Discussions

[Grinch]

What parts of the Linux kernel would benefit the most from Rust?

Every area of the kernel could theoretically benefit from the memory safety Rust provides, and they are zero-cost performance-wise.

So from a safety perspective it's hard not to find Rust appealing.

However, introducing a new language to the kernel adds a lot of complexity, particularly when it's quite a high-barrier language of which I would assume a large majority of kernel developers aren't well versed in, if having used it at all. It requires at the very least that all the maintainers of subsystems containing Rust code become expert Rust programmers alongside being expert C programmers, as they are responsible for accepting/rejecting code submitted to said subsystems.

Then we have the toolchain dependency, accepting Rust code creates a hard dependency on the Rust compiler being available which means you can no longer build Linux solely using GCC, and to top it off, the Rust compiler is really slow (this will likely improve, but it will always be slower than a C compiler given that it does more verification). Also the language design itself seems to still be in a state of flux.

I don't think Rust is ready for Linux mainline inclusion, not on the tooling side, and likewise not on the developer side.

[pmorph]

It's a bit of a gamble, but probably something like this is eventually needed anyway, to help keep linux a relevant choice for a kernel also in the future. So it's only good to start early.

[Luke_Wolf]

Then we have the toolchain dependency, accepting Rust code creates a hard dependency on the Rust compiler being available which means you can no longer build Linux solely using GCC, and to top it off, the Rust compiler is really slow (this will likely improve, but it will always be slower than a C compiler given that it does more verification). Also the language design itself seems to still be in a state of flux.

Rust isn't actually slow to compile at all (unless you're abusing macros). It's that the people making those complaints are coming from Python, Go, and the like where things are "near instant". In my own development I've found Rust no different from C++ code that isn't making heavy use of templates, and the cycle is much faster than a language that actually is slow to compile like Scala which relies upon bringing up a whole interactive shell for some reason.

[SvenK]

It's being worked on. (Through two different avenues, actually. The former being to rewrite a Rust compiler frontend for GCC in the same kind of C++ used for GCC itself so it'll be a first-class GCC citizen like any other native GCC frontend, and the latter being to glue the existing rustc frontend onto the GCC backend to get maximally-compatible-with-the-language results quickly.)

The former will be in a first good state at end of this year. https://docs.google.com/spreadsheets...23M/edit#gid=0 but there are some features that will not be finished at end of this year, so I would say let's add rust support in the linux kernel at end of this year, when there are only a few things not yet supported in gcc.

However, introducing a new language to the kernel adds a lot of complexity, particularly when it's quite a high-barrier language of which I would assume a large majority of kernel developers aren't well versed in, if having used it at all. It requires at the very least that all the maintainers of subsystems containing Rust code become expert Rust programmers alongside being expert C programmers, as they are responsible for accepting/rejecting code submitted to said subsystems.

Or we need a second maintainer for patches in rust, who is a expert rust programmer.

[lyamc]

"Is arguing so hard lyamc had to resort to slippery slope to say anything at all?"

lol, that’s not what slippery slope means, and I used the same logic that you did

[Almindor]

The tricky part is the editor integration.
Vim can recognize #if 0 #endif, but afaik there is no standard pattern for cfg (no, "if cfg!(false)" doesn't work)

That's a very weak argument. ifdef is a hack, cfg is much better, same goes for the macros and pretty much any aspect of the languages when compared. There's nothing preventing someone adding vim support to cfg flags.

[angrypie]

lol, that’s not what slippery slope means, and I used the same logic that you did

It is, and you didn't, because my question didn't imply anything. You wouldn't know logic if it bit you in the ass.

[programmerjake]

That's a very weak argument. ifdef is a hack, cfg is much better, same goes for the macros and pretty much any aspect of the languages when compared. There's nothing preventing someone adding vim support to cfg flags.

iirc vscode has support for greying-out cfg-disabled code when used with rust-analyzer, I'd expect vim might have similar support since I think it's rust-analyzer doing all the work and vscode just using the language server protocol support, which vim also has.

[cynical]

There's been a lot of discussion about them in the RFCs. One of the big problems is that those are both "easier said than done" features in a language that cares about competing with C and being a "make costs explicit" language.

I can already tell it's not going to happen. It's not a matter of cost imo, it's that once you implement such a thing, you'll want a nicer API (just look at the variations of split/trim methods for string) and that would mean the older methods would be deprecated (which truthfully would be horrible). That ship has sailed imo.

We're all wired to look for familiar things (useful as they may be), but that is a red herring when assessing a new language. No language implements every feature ever thought of, the true measure of success is whether you can be productive with whatever features it does happen to implement (and yes, that totally means that I may be ok with a language you hate).

My go to example for the above is Go: few OOP traits, garbage collected, limited enum support, no pattern matching in switch expressions, no generics (soon-ish to change). Yet if you give it a try, you can be very, very productive with the features it does have. And that includes its runtime and tools.

Absolutely true, but note what you said about generics. Some things are just plain nice to have, even if you could do without them. I think Rust is fine as is (which is quite nice), it's just not as elegant as it could be. I'm coming from the perspective of a high-level language user though. Rust is a massive improvement over C or C++ for me so it's a win in the end.

[Grinch]

Rust isn't actually slow to compile at all

Granted it was over a year ago that I ported some code of mine from C to Rust in order to get a feel for the language, but yes the difference in compilation time was very noticeable then. Even this very RFC we are discussing brings it up as a negative:

Slower compilation in general, due to more complex language features and limitations in the current compiler.

So it sounds like it's very much still an issue.