Kroah‑Hartman consistently framed language choices in terms of reviewer workload rather than developer convenience. Linux has “over 5,000 developers” but “about 150 core maintainers that review the majority of the code,” a skew that drives his priorities. “We optimize for reviewers. We don’t optimize for developers because we have a lot of developers,” he said, suggesting Rust’s ability to enforce locking and lifetime rules at build time means reviewers can spend their limited bandwidth on logic rather than bookkeeping: “If it builds as a reviewer, I know it’s OK. I can look at the logic.”
That’s a great point. Living open source code must be readable and maintainable. Rust is an excellent match for that.
So many system bugs are because of unclear memory ownership, buffer overflows, and race conditions. C/C++ don’t help you avoid any of these footguns. Any other system that relies on GC is non-deterministic and prone to mystery hiccups, which is why OS and driver tech has been pretty much the same foundation since the 70s.
Rust lets you avoid 2 of those 3 issues (thread race conditions are still a thing). And being compiled, instead of interpreted bytecode means you can get reasonable performance on smaller machines. No wonder these OS guys are so excited.
Don’t know about “fun again” but definitely a lot less nervewracking and paranoia inducing.
It is hard to think in and see through the eyes from a Kernel core maintainer, if you don’t do this kind of stuff at this level. Instead enforcing style guides, looking for edge cases and unexpected issues because C allows to do anything must be terrifying. Part of this “nonsense” goes away using a language that is designed to handle this better. And you know, learning a new language with features you always wanted to have in C might be exciting too, I don’t know. I can imagine Rust being more fun than C in the Kernel for some, so this is not a wild take or anything like that.
I think the most exhausting part of Rust was two fold: a) the language was not designed to be used in the Kernel, they needed to update and discuss after real world usage, and b) the push back from C developers who either didn’t understand Rust or think its bad for the Kernel. The childhood illnesses of Rust in Linux is seemingly over.
I find Rust extremely fun
I’ve got a non trivial project in Rust, and it takes like 5 min to compile on my machine. Personally, I don’t know how anybody can call this fun. I find it insane to have to wait minutes to see the changes and to iterate. And like sure you can break shit up into crates to speed up compilation, but to do that you already have to have a design you’re happy with and that’s stable.
I find it insane to have to wait minutes to see the changes and to iterate.
i did devops between 2015 & 2025 and got used to the cadence of waiting between 15 & 180 minutes for testing/production pipelines to finish vetting the work i submitted to them.
i went back to doing IT last year and setup similar pipelines to update the code base my predecessor left behind and my new boss expressed the same consternation about waiting for your changes to iterate.
i’m thankful for it because it gives me 30-ish minute windows to browse and annoy people on lemmy throughout the day. lol
this comic will forever make me flinch. lol
back around 2010, i did IT at a place that got a new isilon cluster to alleviate storage space woes with our netapps and the software engineers used this comic to make fun of the work we did when it caused a bottleneck over the network. lol
haha this reminds me of my days working with websphere :)
websphere
indeed
Gosh. I remember working with this back in 2019 and earlier. Our legacy products ran on it. I remember a new service we made (before Spring Boot really took off) used TomCat. It was so much easier to mess with. I asked why we don’t use that for our main product. Imagine my surprise when they said we actually used to.
I’m sure they had their reasons, I was a younger dev at the time and didn’t have insight into why they changed it. But still. Everything is so simple now. Java to run your jar. Your jar has your server built in. Done. And that’s not even including containerization.
I do miss Jenkins though. GitHub Actions seems to be the new hotness. Maybe I just don’t have the muscle memory yet, but it can be annoying.
Yeah, not gonna miss app servers. I do find the JVM was kind of made for a different era though. It’s basically designed to act like a VM on top of which all your apps run. So, startup time isn’t really a problem, and it wants to grab as much memory as it can by default. But nowadays everybody just makes small self contained apps that you can scale horizontally, so this whole model the JVM is tailored for isn’t really used outside big enterprise. And Jenkins was alight, I used to use it back in the day too. For the most part, I do find GitHub actions are an improvement though. You just make a script and magic happens.
I think that’s pretty good insight. In some ways, the JVM served the role that things like Docker does today. That’s a good way of looking at it
yeah that’s a perfect analogy actually
I recall looking at mold, but it didn’t end up helping much in my case. And haven’t looked at sccache, that might actually help if it can cache compilation incrementally in an intelligent way.
Five minutes with build cache? Or from cold build?
With cache, then there’s almost certainly something wrong with your computer or project.
Also… you aren’t building with --release every time are you?
No, I’m not using --release every time of course. And sometimes it’s minutes even with the cache.
That’s highly abnormal to have minute long debug build times.
for 100k loc?
Yeah I doubt it. I’ve worked in large Rust codebases too. I’d do some benchmarking. Cargo has some nice flags that let you see exactly what it’s doing. You can open the compilation report up in a browser and zoom in on different steps of the process and see everything.
I’ve tried looking before and couldn’t get a significant improvement. I’ll have to investigate it again I guess.
I’ve got a pretty large Rust/Tauri program going. Breaking things into crates help, but if you touch enough bits of common libraries, everything needs to get rebuilt anyway.
I use Makefiles for everything. What I found helps is breaking out the parts that don’t change much into separate Make commands (like generating icons, linting, frontend, tests, etc), then leaving “make go” as the simplest inner iteration loop. That way, it’s a lot more bearable.
There’s also “make build” and “make fullclean.” You start one of those and take a long break.
Right, you basically have to start building a rube goldberg machine for compiling your app just so you don’t have to wait for minutes on end. And to me it is absolutely bananas that you can make a compiler this slow on modern hardware. Coming from largely working with Clojure where I have a live application I can interactively load code into as I edit it, this whole process feels insane.
Rust would be better if the rust community wasn’t so up everyone’s ass about using rust.
Attacking the messenger because you don’t have any good argument against the message?
This is the Linux kernel project, one of the technically most conservative projects in the FLOSS community.
50 years later and we are still asking “To C or not to C, that is the question” personally i dont like nanny compilers telling me how to write, warnings are much more helpful to nudge me in the right direction.
See this explanation, this is why.
Interesting, that’s a real change to the last discussion in the email chains where they kind pushed rust out of the core development and said they would need to fork the kernel / make their own smaller modules to bs adopted.
I still remember one of the maintainers leaving over concerns about multiple languages in the kernel and Linus Torvalds having to chime in personally to set the new direction.
No, that is settled and it is also a successful, gradual evolution. It just makes sense to start using Rust for drivers and at the periphery of the kernel, and use it in core subsystems perhaps later.
Any successful change in such a large project will be evolutionary. And also, for gaining security benefits, it makes sense to use Rust in new drivers, new modules, perhaps network stacks, and later file systems - but these roll much more slowly.
Ngl I don’t get the downvotes.
I have no opinion on pro or contra rust in the Linux Kernel. I have no dog in the fight and I do not understand it well enough.
Or did I get something wrong? The email chains are there. The core developers did argue. Linus did chime in. That one dev stopped working on it. what am I missing?
I’m so confused.
Greg is evil, don’t mind MIT code in the kernel and it was the main proponent of AI in the maintenance process.
The Linux Foundation (MS, Oracle, Anthropic, IBM, you know the drill, probably Palantir is there too, just in secrecy) guys love him.
Greg is evil, don’t mind MIT code in the kernel and it was the main proponent of AI in the maintenance process.
That’s a mouthful, can you expand with facts?
don’t mind MIT code in the kernel
Last time I checked, the kernel used GPLv2? Could it be you misunderstand something about cross-using code with different licenses ?
