Greg Kroah-Hartman… urged fellow contributors to embrace those interested in contributing Rust code to improve the kernel.
"Adding another language really shouldn’t be a problem… embrace the people offering to join us
Thoughts on this?
In my mind, introducing Rust would only make sense if:
- There was a serious lack of current kernel developers (which I don’t think there is)
- New hardware and tech was evolving at a rate that the Linux Kernel could not keep up (again, I don’t think this is am issue)
- The end goal is to migrate the entire Kernel to Rust.
Regarding point 3, having both C and Rust really only makes sense as a transition phase (measured in years) - as it would require kernel developers to be savvy in both C and Rust, or would force developers to stay within whatever domains were implemented in C or Rust.
it would require kernel developers to be savvy in both C and Rust
From my experience knowing how both C and rust works makes you a better developer in both languages.
Learning Rust made me a better C# programmer.
Oh absolutely, but you could argue the same for learning lisp or mastering any functional programming language (list comprehensions, etc). It will improve your design patterns when you go back to an object oriented language with some elements of functional programming.
Nah it’s a different axis. Rust doesn’t have a GC, you do need to think about memory, it’s just that the compiler generally enforces things for you. You learn to think like borrowck thinks because you don’t want to get yelled at. Going back to C then you suddenly mistrust a lot of code a lot more, and rightly so.
Exactly. The kinds of things Rust yells at you for, you should consider changing in C as well.
What’s in your mind does not coincide with the professional experience of Greg KH. You shoyld read what he had to say on the subject.
What?!? Actually, read the article? What is this, Reddit? /s
Seriously, though - let me spin the question around: what, in your mind, overlaps with what Greg said?
(plus, OP was just interested in people opinions - not whether they align/contradict with Greg, Linus, etc)
To add something to this: linux has avoided internal SPIs for a long time. It’s often lauded as one of the reasons it hasn’t ossified.
However, some subsystems have a huge amount of complexity and hidden constraint in how you correctly use them. Some of that may be inherent, but more of it will be accidental.
Wrapping type-erased shims around this that attempt to capture (some of) those semantics shines a light onto the problem. The effort raises good technical questions around whether the C layer can be improved. Where maintainers have approached that with an open mind, the results are positive for both C and Rust consumers. Difficult interfaces are a source of bugs; it’s always worth asking whether that difficulty is inherent or accidental.
For the lazy, I liked these parts:
Rust isn’t a “silver bullet” that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn’t we want that?
…
Yes, I understand our overworked maintainer problem (being one of these people myself), but here we have people actually doing the work!
The whole thing is great.
Rust lacks a language standard. Without that is meaningless programming something with pieces that may change in the future (like what happened with Python) is not a good idea in my opinion.
Technically, the kernel doesn’t compile with pure standard C, they require strict aliasing to be disabled, so that alone doesn’t seem to be strictly required.
Not saying that standards aren’t useful, but they’re not some dividing line separating the true languages from the joke languages, they’re just a useful document that earns a language a few “good language” points, but those points can be earned other ways too.
For example, rust has pretty good versioning, so even if the devs did totally wreck the language in the next version, it’d maintain compatibility with older code just fine, which sort of invalidates your point, unless you’re worried that the devs turn malicious, but the language is open source, so I imagine that would get it forked pretty quickly.
Comparing python to rust, rust has far fewer breaking updates than python, and thats a fact. Feature updates can and do break older code in python, whereas in rust this is simply not allowed with few exceptions.
The language is allowed to change in compatible ways with editions. Every few years a new edition is released which allows otherwise breaking changes to be implemented, but the old and new code can still work together. Developers can rev the edition version when they want. I also think cargo might be able to help upgrade to a new edition as well.
Rust isn’t perfect, but python fails to learn the lessons that even perl implemented decades ago.
Just fork it, do a complete rewrite in Rust, and call it “Runix”
More OS options is better for everyone.
Theres heaps of stuff that is under-developed or mssing, but they prefer to rewrite working code in Rust, because ideology.
We are witnessing the death of Linux here, no less, replacing a working kernal with an still undefined language that everyone will have forgotten in 5 years.
I’ve gotten into the most hilariously circular debates with rust opponents on this point. Their arguments tend to come down to “just don’t write bad code”.
The team is only as strong as the weakest link. The release is only as good as the least talented dev. Tools that raise the entire foundation are objectively good. Even better are tools that outright prohibit you from even writing entire categories of bugs. Rust is that tool.
And yeah I know it’s not perfect, and it shouldn’t be treated as a panacea. But its advantages should be lauded, not derided because some contributors like to maintain the walled garden of knowledge as if it were a secret spellbook.
- Humans write code
- Humans make mistakes
∴ Humans write bad code
And that’s why I don’t work in software development!
I don’t know about you, but I prefer provably correct code over “just trust me bro.”
There’s an analogy I like here. A manager at a trucking company was hiring a new driver, and he asked each of them how close they could get to the edge on a mountain pass. The first said, “I can get within a wheel’s width.” The second said, “I can drive on the edge, with part of the tire hanging off.” And the third said, “I stay away from the edge.” The third applicant got the job, because why take the risk?
That’s how I feel about C/C++. Why use them if Rust can do the job? You get a lot more safety features without sacrificing performance, what’s not to like?
Did somebody say “provably correct”?
Haskell has entered the chat
That’s kind the entirety of my point: if Rust is a tool that can make expressing algorithms safer and less prone to error - and it can, in a logically provable sense - then what the fuck ground do you have to push back on?
I’m still kind of on the fence about Rust in the kernel. Linux isn’t some random hobby project, there are serious people working for serious companies in the project. Rust has a clear value proposition w.r.t. it’s qualities as a language, but I don’t think it’s as clear on a system level.
Say I’m working for a large company as a dev, maintaining a subsystem (let’s say a driver). Letting other people (filthy casual hobbyists) mess around with their filthy type safety will eventually spill into my subsystem and cause extra work. I don’t want the extra work, I just want to have my driver working and then go home. And even if I’m okay with the extra work, my boss won’t be. Even the risk of extra costs down the line will be enough for some to shut it down completely.
There are boring people working for huge corporations with huge stakes in the Linux kernel. I don’t think they see that much value in Rust at the moment, and I think the Rust crowd might need to hire some MBAs if they want to expand their presence in the kernel.
Oh, so that’s actually a thing I specifically do not care about.
I tolerate MBA types at my job because they’re part of an equation that yields a paycheck to me. I don’t believe those MBA types should be in the discussion at this level at all.
In fact, that sort of insistence on implementation details from product and manager types who can’t ever fucking commit to addressing tech debt issues until the system is falling apart is one of the primary frustrations I have in my career.
I don’t believe those MBA types should be in the discussion at this level at all.
That’s the thing. They are in the discussion. It doesn’t matter what we think about it. If touching Rust risks yielding lower profits this quarter, it’s an automatic ”fuck off you filthy hobbyists”. Even having the discussion costs money.
Rust in the kernel isn’t about technology, it’s about economics and risk management. I’d like to see the discussion move on from ”C bad unsafe rust gud typesaf” to a level where the suggested benefits of Rust are made clear to the people holding the bags of money, preferably presenting some actual monetary benefits. (Oh, and to make things worse, there are thousands of different stakeholders, with different interests, many of which are in conflict. Good luck!)
So yeah, I get that you don’t care about it. But you probably should.
I feel like better tooling is a safer bet. I know people hate on AI here but tooling that can detect flaws in C memory management would be basically as good as Rust itself.
True. We should have both better tooling and better languages. Someone posted this thread with Greg KH, which has this gem:
The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That’s why I’m wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)
I’m all for moving our C codebase toward making these types of problems impossible to hit, the work that Kees and Gustavo and others are doing here is wonderful and totally needed, we have 30 million lines of C code that isn’t going anywhere any year soon. That’s a worthy effort and is not going to stop and should not stop no matter what.
But for new code / drivers, writing them in rust where these types of bugs just can’t happen (or happen much much less) is a win for all of us, why wouldn’t we do this?
In short, let’s do both.
