My Kernel is Rusting
I have been doing Java, C, C++, Python, PHP, Javascript, Lua, C#, Go, assembly and a whole bunch of other languages for over 30 years. I've started looking into Rust about a year ago and I was immediately intrigued. Fast forward a year and I frankly don't want to use anything else anymore. Be that for fat applications, backends, web frontends, or even embedded devices and vintage computers. If you believe certain people, that is because one year ago I joined a cult. There can be no other explanation.
In all seriousness though, I just like how Rust works and how everything feels like it was made by someone who's seen all the things I have seen, made similar mistakes and experiences, and wants to learn from all that and make something better. It's the first time in what feels like forever that a programming language isn't just different, but feels fresh and new. Is it perfect? Absolutely not. But since when was "waiting for the perfect solution" a valid strategy for technology selection?
Here we are in 2024 and there is massive Drama about Rust support in the Linux Kernel, with maintainer Wedson Filho stepping down after a particularly terrible talk that was completely derailed by C kernel developers. This is the most embarassing bikeshedding session I have ever seen. When someone starts a sentence with "I know nothing about Rust, but..", you know you're in for an informed opinion.
The thing the Rust devs requested, in a nice tone (Watch the video!) and noting that this wasn't gonna be high up the priority list of kernel maintainers, was that C developers start documenting their interfaces and perhaps look at certain refactorings to make both the life of a Rust binding easier and making the C interface easier to maintain and work with. There is actually nothing super Rust specific in that request. The reaction of certain kernel maintainers was pure outrage and vitriol, mixed with weird outbursts like Red Hat's Tso screaming "You'll never force me to learn Rust".
Wedson has added some more comments about his resignation in an interview with TheRegister:
"I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix."
But things get worse. There is a certain group of people who think that Rust is not only a cult, but something even more sinister: It's by and for transgender people.
Just look at Bryan Lunduke's take on Rust. The TLDW:
- He doesn't like Rust
- It looks weird
- It's a cult
- It's by and for transgender people and furries
His take on the current kernel situation isn't much better and boils down to "how dare they tell us how to write code", in response to maintainers and other Rust devs reacting (1) (2) (3) to the shouting show of the C devs.
So what is it that the Rust people want? Let's look at Lina's post:
When I wrote the DRM scheduler abstractions, I ran into many memory safety issues caused by bad design of the underlying C code. The lifetime requirements were undocumented and boiled down to "design your driver like amdgpu to make it work, or else". My driver is not like amdgpu, it fundamentally can't work the same way. When I tried to upstream minor fixes to the C code to make the behavior more robust and the lifetime requirements sensible, the maintainer blocked it and said I should just do "what other drivers do".
This doesn't sound like cult to me. It sounds more like someone has expressed very specific technical issues, and the response is "but the Rust people are cultists".
Now, bad takes and uninformed opinions aside, Linus Torvalds has himself voiced concern about certain issues with regards to Rust in the Kernel in the past, but those were actual issues, as in, technical issues that need fixing. Not "I don't want to document my C code". Another valid concern is time and developer availability. But the request for cleaning up and documentation should not give rise to such shouting matches. For the record, I tried contributing to the Linux kernel exactly once. It was a spinlock issue that while not critical, did leave some performance on the table. The maintainer eventually simply declined without further comment. Then a few months later I saw that he had simply incorporated my fix under his own name with no attribution.
Here's another more technical angle: Some people suggest that C++ can do all the things Rust offers, including memory safety, thread safety, etc. just by adding certain tooling and libraries. That is unfortunately only half true. Not only is this always said by developers who don't use said tooling and libraries, it also omits the fact that these features come at a compile time cost in Rust, while they incur a runtime cost in C++. So yes my answer to that is always: "That's great. Are you doing all that?"
If you are Rust-curious and want to join the cult, here is a 10 minute tutorial.
And if you want to see what an entire operating system written in Rust looks like, check out Redox OS.
I leave you with this image of some sample rust code compiled to Mega65 machine code and running on a physical Mega65:
