I respect the opinion in this article that Linux should be simple and Rust is adding a lot of complexity to the build and ABI, but the advantage of Rust is not just memory safety.
Rust is massively more expressive. You get actual tagged enums, modules, sane dependency management, generics, polymorphism, optionals, no unchecked nullability, collections, and many other things. Writing systems software with it - even if you completely ignore memory safety! - is a very pleasant experience once you've grokked the language.
> There are some other arguable benefits which mainly boil down to finding Rust to have a superior language design to C or to be more enjoyable to use. These are subjective and generally are not the most important traits a kernel hacker has to consider when choosing a language, so I’m leaving them aside for now.
I agree that these features are nice; I added many of them to my own language and take advantage of them in my kernel. But they are a secondary concern to the constraints of the kernel's problem space and the conservatism required of a project like Linux.
Because all things are not equal, unfortunately. Per the article:
> As Linus recently put it, “kernel needs trump any Rust needs”. The kernel is simply not an environment which will bend to accommodate a language; it must go the other way around.
A single person argued to Linus a broad amount of the kernel's internal API should be painstakingly refactored to be philosophically rust-y. Linus said no way, that's not what we're doing here.
Luckily, that's not what the Rust for Linux project has been doing either.
The question is not if Rust is more expressive but if C is expressive enough for the Linux kernel. So far there is no evidence that Rust adds any value here. And if C is missing certain features, they can be added. It looks like ISO is looking at that very thing in C2x and beyond.
C might be enough, but Rust is better.
Rust makes programming more productive. Are you denying that?
And C is not going to get Rust features: C's philosophy to stay limited on purpose.
With such expressivity, there is a risk in a big project of individuals conjuring wildly different mechanisms to express similar if not identical ideas, losing out on understandability and consistency. The solution is often a strong style guide that everyone must read and follow. If Rust ever makes it to the kernel, I hope such a guide is written...
I would think that the extremely complicated algorithms that are often used are just intrinsically difficult, and things like metaprogramming allow a lot of expressivity in C already.
Having to think through race conditions is likely more of an issue than having to think through 3 obvious but distinct ways of doing the same thing syntactically.
Even though I would prefer there be only one obvious way to do things.
Because you need to emulate in C the features that more advanced languages have buitin, such as virtual tables, tagged union, lists, hash map, and whatnot.
This is just a lot of conventions that are specific to each project that need to be learned and put in some style guide or development guide. In big projects, different developers will use different conventions in different part of the code, that's unavoidable.
This seems pretty straightforwardly wrong? All else equal it's better to have things be less work. And saying that isn't an insult to people who had to do the hard work in the past.
> It’s insulting to present this as an improvement over what was achieved by those doing all this hard work.
From my perspective, Rust does not belong in kernel. But meanwhile Linux kernel does not belong in modern infrastructure. Until the day a mature kernel-oriented language and an established kernel showed themselves, Frankenstein experiments will continue to trump both parties.
I'll say what I said about about Drew Devault just a few months ago, "He also never makes an argument. After awhile you realize he's not really saying anything at all. It's fundamentally contentless... It's all just vibes, like Fox News's opinion journalism or Trump is just vibes."
20 comments
[ 2.9 ms ] story [ 54.2 ms ] threadRust is massively more expressive. You get actual tagged enums, modules, sane dependency management, generics, polymorphism, optionals, no unchecked nullability, collections, and many other things. Writing systems software with it - even if you completely ignore memory safety! - is a very pleasant experience once you've grokked the language.
> There are some other arguable benefits which mainly boil down to finding Rust to have a superior language design to C or to be more enjoyable to use. These are subjective and generally are not the most important traits a kernel hacker has to consider when choosing a language, so I’m leaving them aside for now.
I agree that these features are nice; I added many of them to my own language and take advantage of them in my kernel. But they are a secondary concern to the constraints of the kernel's problem space and the conservatism required of a project like Linux.
Why wouldn't things being easier lead to better results, all else equal?
> As Linus recently put it, “kernel needs trump any Rust needs”. The kernel is simply not an environment which will bend to accommodate a language; it must go the other way around.
Stuff like faillible memory allocations are being worked and rust doesn't have so many needs by itself.
Luckily, that's not what the Rust for Linux project has been doing either.
That line came from Linus educating a single wrong member of the rust community.
It only shows that person wasn't using rust in a way that accommodated kernel needs, not that it's impossible or even difficult to do so.
Albeit it is subject, compared to C, yes.
Not so much compared to D.
The question is not if Rust is more expressive but if C is expressive enough for the Linux kernel. So far there is no evidence that Rust adds any value here. And if C is missing certain features, they can be added. It looks like ISO is looking at that very thing in C2x and beyond.
Having to think through race conditions is likely more of an issue than having to think through 3 obvious but distinct ways of doing the same thing syntactically.
Even though I would prefer there be only one obvious way to do things.
Because you need to emulate in C the features that more advanced languages have buitin, such as virtual tables, tagged union, lists, hash map, and whatnot. This is just a lot of conventions that are specific to each project that need to be learned and put in some style guide or development guide. In big projects, different developers will use different conventions in different part of the code, that's unavoidable.
Rust is cleaning up the Linux codebase like porting to Alpha cleaned up the Linux codebase.
The lessons learned attempting to integrate Rust into the Linux kernel will inform the creation of next generation of programming languages.
> It’s insulting to present this as an improvement over what was achieved by those doing all this hard work.
I think this sums it up pretty well.