Linux royalty backs adoption of Rust for kernel code
-
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?
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.
-
I think they know C a little better than just to be „productive” with it. And also a lot of those people are not so young anymore to learn a new language well enough to feel comfortable with writing a kernel in.
As do I. I could jump into a modern C codebase and feel comfortable. I've worked on microcontrollers, built servers (UDP, TCP, and HTTP), and worked with cross thread communication. If I know what I want to build, I can achieve it with C. Maybe not as quickly as someone who works with it every day (it has been a while), but within a month I'd be back in shape.
I feel the same about Python, Go, JavaScript (both on server and FE, either React or straight DOM manipulation), and Rust (I use it for personal projects extensively). When I write C++, it usually turns out like C with vectors and smart pointers, so I'll add that in as well. Except for Rust, I've used all of these in a professional capacity (and I did technically do a couple POCs in Rust). I could list a bunch of other languages I'm less confident in, but could also use professionally if needed without needing to study first.
I'm not suggesting they go out and do the same, I'm merely suggesting that when an option comes along that solves some serious problems they run into every day, maybe they should try it. Most of the languages I mentioned are useless for kernel development, so it makes no sense for them to bother with them. However, Rust is really interesting because it comes with some very compelling guarantees, and you don't get many guarantees when it comes to low level development.
If I told a kernel dev that I had a tool that can identify most if not all memory safety/soundness issues in their C code, they wouldn't hesitate to try it out. But if I ask them to try out Rust (same guarantees), they'll refuse. Why? Hubris and stubbornness.
-
Despite my drive-by shitposts in the rest of this thread I want to make a serious point here.
There's a large part of software engineering that thinks languages are chosen based on the problem, as a tool for a job.
They aren't. They're chosen based on the team, on how well the team knows and can use the tool.
On how many people can be hired with the knowledge of the tool to work immediately.Sometimes, even if the team knows C well, there can be a problem so different it's worth using another tool. say python for some testing scripts on a C project.
But rust and C are too similar for this to apply.
If you want rust to be used for the kernel you have to push for it to be more well known and used, so more Devs come into teams already knowing it well.
Anyone agreeing to work on a team using rust is making a career decision that will be stay on their CV forever and you need them to feel good about this, that it will give them more opportunity in future.It'll take 20+ years because that's how long legacy code is often maintained for and we already have 20+ years of future legacy code for C teams to deal with. We're all making more future legacy C code than future legacy rust code too.
I'm trapped in C++ so I'm doomed but good luck C and Rust coders.
"Iam trapped in c++", lol
-
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.
-
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.
-
Unsafe Rust may be similar to C, though even though there's wibbles like the borrow checker still running, you still get more guarantees about the code than with C. Safe Rust can, on occasion, look more like Haskell than C.
Are they both systems languages? Yes of course otherwise we wouldn't be talking about using them in the kernel. Makes no sense to extend the possible comparison candidates to include Prolog, arbitrarily making look C and Rust more similar by introducing a far-off comparison point.
Unsafe Rust may be similar to C
It's really not. I'd much rather use C than unsafe Rust...
The best part about Rust is you can isolate your memory safety problems to the unsafe bits, whereas with C, you have to constantly deal with it.
-
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.
-
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.
-
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.
-
That does NOT sound like a good idea.
We've turned our development model into a well-oiled engineering marvel,
Exactly, and I'm pretty sure one of the reasons is that it's remained on C, and NOT switched to C++, as has been often suggested.
The second they make it a mixed code base, that's the same second quality will deteriorate. Mixed code base is a recipe for disaster.Edit:
Torvalds eventually responded by defending the Linux kernel development process and scolding Martin for grandstanding on social media about the issue. Martin later quit as a Linux maintainer and resigned from the Asahi Linux project.
Seems like Linus isn't onboard with this.
But I guess all the downvoters know better?
opening for a mixed code base is a recipe for disaster.
Greg Kroah-Hartman:
Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers, dammit.
That's special pleading, that lacks basis in reality. Still he admits it's rough to mix codebases.
I'm not claiming Rust wouldn't be brilliant in some situations, but the detraction of a mixed codebase is worse than the benefit.
It's not like Linux compiles down to one binary or anything, most of it is linked together over a pre-determined API. Anything that can satisfy that API (and ABI) can drop in. There are some "magic" bindings, but they still conform to that API.
Read the rest of Greg KH's thread, here's the last half of that paragraph:
Adding another language really shouldn't be a problem, we've handled
much worse things in the past and we shouldn't give up now on wanting to
ensure that our project succeeds for the next 20+ years. We've got to
keep pushing forward when confronted with new good ideas, and embrace
the people offering to join us in actually doing the work to help make
sure that we all succeed together.And earlier:
Rust also gives us the ability to define our in-kernel apis in ways that
make them almost impossible to get wrong when using them. We have way
too many difficult/tricky apis that require way too much maintainer
review just to "ensure that you got this right" that is a combination of
both how our apis have evolved over the years (how many different ways
can you use a 'struct cdev' in a safe way?) and how C doesn't allow us
to express apis in a way that makes them easier/safer to use. Forcing
us maintainers of these apis to rethink them is a GOOD thing, as it is
causing us to clean them up for EVERYONE, C users included already,
making Linux better overall.Those are solid arguments. As long as the APIs are well designed and documented, a mixed codebase is fine, and you get most of the benefits of Rust where it's used.
-
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.
Again from my experience, knowing lisp (yay guix and emacs) definitely helps me write more elegant code in every language.
I also have to explain almost every single thing I write in code review.
-
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.
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.
-
System shared this topic on