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.
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...
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.
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.
> 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.
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.