Skip to main content

The Linux kernel will officially support Rust... but why?

The Linux kernel has always been written in C for the entirety of its existence since its first version, published in 1991. Linus Torvalds himself, as the creator and owner of the project, has always defended this decision very, very strongly (sometimes to the point of outright embarrassing behavior), for decades and decades.

One of the more rational strong arguments why the kernel has been kept using pure C is this: C is the de facto universal embedded systems programming language, and the amount of C experts, who know the language inside out and have several decades of experience (often literally 30, 40, and even more years) is enormous. Thus the pool of potential developers, maintainers and experts with the proper qualifications is huge.

Unsurprisingly, dozens and dozens of alternatives have been suggested over the decades, pretty much since the very beginning. The total list of proposed alternative programming languages would probably be quite large, perhaps even in the hundreds. "Safe" languages, "better" languages, and so on and so forth. All these suggestions have always been rejected by Linus himself, and the kernel development community in general.

And it's not like the alternatives have been bad. There have been many programming languages that have had all the features, capabilities and properties needed for the Linux kernel, and which arguably have better and safer features than C, and some of which even match its efficiency and memory usage, give or take.

They have all been rejected, and one of the reasons for that is precisely what I mentioned: Many of these languages are niche, or they are not really designed for embedded systems and haven't been used much in such contexts, and many of those languages are very new. And all of that means the potential pool of qualified experts with decades of experience in embedded systems programming with the language is small.

Yet, enter Rust, a new language with a very small pool of experienced developers, and which is just one of the many, many similar programming languages with similar features and safety features... and somehow things are different.

Suddenly the Linux kernel developers, including Linus Torvalds himself, are completely open to add support for it in the kernel source. They are, in fact, now making it official: It's not an experimental stage anymore. Now it will be supported officially.

From the literally hundreds of programming languages that have been suggested for the Linux kernel, many of them quite apt for that task, and all of which have been summarily rejected... somehow Rust is now accepted. This even though Rust doesn't really offer anything that many of those other languages didn't.

Why?

That's the thing: Nobody seems to know!

I have literally never heard a single argument or explanation why they suddenly decided to grant Rust in particular this special privilege, from among all possible programming languages. I have never heard why Linus himself, who has rejected literally dozens and dozens of other programming languages, became receptive to this one. He just did it because... reasons?

It's extremely strange.

And the funny thing is that Linux developers who have aggressively pushed Rust into Linux have already demonstrated time and again that it tends to produce buggy and less efficient code.

For example the Ubuntu team has been aggressively pushing Rust into their distro for a couple of years now, replacing all the GNU core utils with their own versions written in Rust... and the end result has been a complete mess: Incomplete features, broken utilities, severe bugs (for example a bug in the sudo utility that could be used for privilege escalation), increased memory usage (meaning that the new utilities are unable to handle files as large as the originals) and in several cases severe degradation of performance (with some of the utilities being up to 17 times slower than the originals. Not 17%. 17 times!)

Yet, they don't care. They literally don't care. They have no intent in matching the features of the original core utils, nor to fix the inefficiency problems. They have literally become the Microsoft of Linux. 

Comments