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.
Yup. Most of my career has been working on embedded realtime software, so interpreted languages are right out and really only C and a subset of C++ are available. I’ve now been using Rust in that way for about nine months now and while the syntax is sometimes silly feeling, being able to not worry about some many other issues has made development much better.
C/C++ don’t help you avoid any of these footguns.
But libraries like Boost do… if you’re writing in raw C++ you’re doing it wrong. A big part of the power of C/C++ is the mature and modern ecosystem built around it.
if you’re writing in raw C++ you’re doing it wrong.
So, C++ is the new Python?
Yes, but nobody in their right mind will use boost at OS kernel or driver level. Also, using C++ has vtable/exception overhead. No-go.
I worked at companies that tried both. They no longer exist.
I’ve worked at plenty of companies that no longer exist, and startups that “made it big,” and big companies that lumber along… how good their programming practices were, how well thier software performed, has just about zero correlation with how well they do in business.
As you point out: different tools are more/less appropriate for different applications. Rust has good overlap with C and C++ places, and in kernel land it’s subbing for C.
I’ve never tinkered in kernel space much - repaired a few OpenGL drivers because nobody else would step up and do it, but I usually stay in the higher abstraction levels. What do kernel people think of libraries like GLib?
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’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.
5 minutes sounds like way too much, unless you mean a fresh compile. But then you shouldn’t need to wait that long between changes, since incremental compilation should kick in then.
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 mean, if you have your modules structured in a tree structure and with proper visibility, then it isn’t a particularly big leap to put it into a separate crate. You just move the files, maybe fix some visibility modifiers still, and then a bit of boilerplate to add it to the workspace.
It’s only really when you’re publishing to crates.io, that you don’t particularly want to keep changing the names/scopes of the crates, as they’ll stick around on there for the foreseeable future.
It’s around 100k loc sized project, so from what I’ve seen that’s about what you can expect with Rust.
5m seems about right. Lemmy’s from scratch builds are ~3.5m on a fast machine, and we have ~60k lines of code, and are using some with large libraries with lots of features enabled.
But you really should only ever have to do a from scratch build either at the beginning, or when you deploy. When developing, your IDE should only ever really run
checkorclippy, which should take seconds at most.
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
haha this reminds me of my days working with websphere :)
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
What part of Rust is fun?
C is fun to me because the syntax is easy to understand and straight to the point. C is also great for learning low level coding, I find Rust so confusing
Rust requires you to unlearn some of the C and CPP habits. And so it’s like learning a language that approaches things differently. That is pretty fun to see how another language solves a problem etc. I think rust is a very fun and interesting language tbh. But you are free to not like it, that’s all good man. That’s why we have different languages. After getting into rust, for me, you need to convince me to use C or Cpp, they have their niches for sure, but rust allows that too like embedded programming etc.
This checks out. I tried some Rust coding challenges and couldn’t get my stuff to compile mostly. When I see the solution it seems straightforward but also not intuitive.
Yeah, there’s a lot a cool ways to chain ways to process things and all. Its like building a muscle, I’ve noticed with time and practice (sometimes just repetition after seeing the answer if that works for you) and things get more intuitive. Cause theres a lot of thought on why a pattern is a certain way, and on C you could use teh same hammer for everything. Here you have different tools in a way.
Yes, C syntax is easy understand
The first picture isn’t what people write, even though it’s technically compilable, it’s not what C is.
The second is a normal syntax, pretty simple to understand if you write enough code.
C is very simple language at it’s core, and it allows for it to be used in a very complicated systems.Nobody is arguing C is complex. The argument is that it’s not the optimal syntax.
For example, case statements needing breaks can cause logical issues with incorrect merges.
How about this
https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug
The if statement not requiring brackets caused this bug. Rust fixes these issues with pattern matching and mandatory curly braces in if body statements
Yeah, it’s not optimal, I don’t think anyone argues that it is. It has a bunch of ways to shot yourself in the foot, no questions about that, people were writing books about that for decades. Not like there is an optimal language that doesn’t allow you to make some stupid mistakes.
But also, a lot of that non-optimality is what gives it advantage. Well, that and enormous amount of legacy code and expertise.
Sometimes you need to pass around raw pointers without caring about memory ownership, and for that situation it’s optimal. I’m glad you have your mandatory curly brackets, but sometimes I just want my microcontroller to blink an LED and for that I’m in turn glad that I can be as quick and dirty as my filthy mind allows me.
And for serious projects we’re all MISRA compliant anyway, and it mandates curly brackets for ifs and proper cases for switch.Let’s not get too abstract. Just because Rust made its own mistakes doesn’t mean it didn’t fix the mistakes I pointed out
Serious projects have huge memory safety issues that don’t exist in Rust. More than half of security CVEs are due to the nature of C. Rust just has fewer bugs like Heartbleed because it doesn’t let you do a buffer overrun
that don’t exist in Rust
That’s because serious projects basically don’t exist in Rust. Yet, probably, Rust seem to be a good language that people like, so those are to follow, but for now they’re rare.
Or don’t, if we discover that Rust has some other issue that only happens when the project grows old enough.
Personally, I’m sticking to the devil I know, the one that has almost 60 years of accumulated knowledge and best practices.Rustls can already replace OpenSSL, but maybe that’s not serious enough for you. Sure, the ring backend embeds assembly for the crypto operations, but that’s the point:
You can have a safe interface for interacting with potentially unsafe code. Do all of the memory allocation and string manipulation stuff in Rust and call out to crypto in assembly
