Linux royalty backs adoption of Rust for kernel code
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
"Iam trapped in c++", lol
-
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.
-
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
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.
-
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.
-
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.
-
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.
-
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.
-
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.