Linux royalty backs adoption of Rust for kernel code
-
"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.