Linux royalty backs adoption of Rust for kernel code
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?
You're viewing a single thread.
In my mind, introducing Rust would only make sense if:
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.
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.
- There was a serious lack of current kernel developers (which I don't think there is)
Maybe not at the moment, but my understanding is that the pool of qualified C programmers is shrinking rapidly, because the old guard is all ageing out and there simply are not enough intermediate developers coding in C at the level that Kernel development requires.
Having a larger (and growing) pool of upcoming developers interested in systems programming and software excellence is one of the explicit stated reasons that Linus et al. considered Rust in the first place.
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.
