Rust for Linux still contentious after 5 years
A long-time Linux maintainer calls Rust a "cancer" in the Linux codebase and tries to block crucial abstractions from entering the kernel. Another contributor tries getting him banned in return.
When I started this newsletter, I added every Linux subreddit to my “check these news sources twice a week” list because the Linux project is a famous source of drama. The most famous episodes usually originate from Linus Torvalds, the “Benevolent Dictator for Life” and creator of Linux. He is famous for (a) his incredible technical aptitude, and (b) his willingness to absolutely roast people. However, I didn’t expect some of the day-to-day drama would raise as many questions as today’s post.
“Rewrite in Rust” is a meme in coding circles. It’s a joke that implies you should follow a hot trend instead of doing what makes sense. However, it’s not just a meme. Some projects can benefit strongly from adopting Rust. Rust is a systems language designed as the next evolutionary step beyond C and C++, while striving to achieve the same performance. It has modern language features, a “you don’t pay for what you don’t use” philosophy, language-enforced memory safety features, and no garbage collector slowing it down. The larger your C or C++ codebase becomes, the more likely that it would benefit from being written in Rust. So why wouldn’t you start adding Rust to your project? For one, it has an high learning curve. Consequently, few developers actually know Rust1.
What codebase has a lot of C? Linux. Much of its functionality is included in isolated device drivers or kernel modules. In fact, it’d be the perfect proving ground for Rust.
So naturally it created a huge multi-year war, between people who were used to the C way of doing things, and people who wanted to adopt Rust for memory safety. But at the end of the day, Rust for Linux was pulled into the kernel by Linus, so it’s an official part of Linux. Even years later and with slow adoption, he remains optimistic.
Well, fast forward to 2025, and that hasn’t satisfied everyone. One long-time maintainer in particular, Christoph Hellwig, has decided to take a unilateral slash-and-burn approach to try to prevent Rust for Linux from succeeding. In particular, he is opposing the introduction of reusable DMA bindings for Rust device drivers. Since DMA allows devices to interact directly with memory without needing to go through the CPU, it’s obviously existentially important for Rust to get a good DMA interaction.
He says that he is against multi-language codebases and objects to Rust’s introduction.
Which doesn't help me a bit. Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this. This is NOT because I hate Rust. While not my favourite language it's definitively one of the best new ones and I encourage people to use it for new projects where it fits. I do not want it anywhere near a huge C code base that I need to maintain.
He thinks that a second language will spread through the kernel like a cancer.
And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux. Thank you for your understanding!
Hector Martin responded by calling him a saboteur and argued that he should be removed on Code-of-Conduct grounds.
Edit for the Reddit peanut gallery: The reason this is sabotaging the entire R4L project is that DMA abstractions are critical for 99% of drivers, and without them, the R4L project is dead in its tracks. Christoph is fundamentally opposed to the goals and technical plan behind R4L, and offers no viable technical alternatives. If his demands are met, the R4L project is effectively dead with no way out, and that is what he wants. This is the dictionary definition of sabotage.
[…]
Personally, I would consider this grounds for removal of Christoph from the Linux project on Code of Conduct violation grounds, but sadly I doubt much will happen other than draining a lot of people's energy and will to continue the project until Linus says "fuck you" or something.
Handling dissent is definitely one of the least-fun parts of organizational politics. And this is made a lot harder in an open-source project. In a normal company, if you want to get a controversial decision across the line2, you’d need to figure out all of the people who are involved in a decision, work them one-by-one, get an agreement in private from every single one of them, hold a meeting where you go over the plans, show everyone that everyone else is willing to move forward with the plan, and then begin the execution phase. But it’s different in an open-source project. Participants don’t have a manager, or executive-mandated initiatives, or really any reason to want to be nice. They just have to clear the bar of “has not been banned from the project yet” and people will have to put up with them.
So let’s look through the following questions:
Does Hellwig have a good technical argument? Sure, if you look at just the technical merits it’s pretty reasonable. Maintaining two languages is harder than maintaining one. They each have their own builds, conventions, style guides, etc. If he’s devoting all of his energy to the Linux project, it’s understandable
Did Hellwig cross the line? Probably; cancer is definitely an insult. However, there are complicating factors; namely he grew up in Germany so despite having excellent technical English, there is still a gulf between fluency and native-level English. Could you imagine someone thinking, “well, a cancer spreads itself just by existing within the host, and this is how I expect the Rust bindings will behave. Yes it’s harsh, but it’s also the perfect technical analogy.” On the other hand, if it were a misunderstanding, the only appropriate action would be to apologize, which as far as I can tell from reading the mailing list thread, has not happened. So it’s probably not a misunderstanding.
Is it appropriate to call him a saboteur and threaten to have him removed from the project using Code of Conduct violations? Probably not. It’s probably accurate to call him a saboteur3, but it’s also stooping to the same level of someone describing your project as a cancer. Should you be upset with someone trying to block your project on technical grounds? Probably! Should people who sling mud apologize? Probably! Is using the word “cancer” worth losing access to the project permanently? Probably not, that’s really extreme!
The TIOBE index, which attempts to measure programming language popularity, puts it at the 14th-most-popular language, and rates it roughly 1/8th the popularity of C and 1/10th the popularity of C++.
Or just get an executive to mandate it.
I checked the dictionary because I assumed that the action had to be covert to be sabotage. It doesn’t seem to be a requirement.
"So naturally it created a huge multi-year war, between people who were used to the C way of doing things, and people who wanted to adopt Rust for memory safety."
---
Jacob, it would be interesting to get your views on whether Nim (aka #nimlang) would be a better fit for Linux devs in comparison to Rust. Since Nim consumes C/C++ libraries with ease, it's great for hard realtime embedded development thanks to its new default ARC/ORC memory manager.
{ Both ARC and ORC offer deterministic performance for hard realtime systems, but ARC can be easier to reason about for people coming from Ada/C++/C -- roughly speaking the memory for a variable is freed when it goes "out of scope". }
source: Nim's Memory Management
https://nim-lang.org/docs/mm.html
Of course, developers are also able to disable the GC and handle things themselves. And with Nim, you get a language that takes the best concepts & inspiration from Python, C/C++, Ada, Object Pascal/Modula to create a very disruptive language that is "efficient, expressive & elegant" in that order.
As such, developers can compile their Nim code to C, C++, Objective C, JavaScript in order to have the ultimate versatility as a developer on Linux, Windows, MacOS, iOS, Android & BSD Unix. Thus I truly believe Nim will be a great addition to all Linux devs. ;-)
{ "Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems." }
source: https://nim-lang.org