Linux royalty backs adoption of Rust for kernel code
-
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?
-
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 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.
-
There was a "Lindows" back in the day...
-
Maybe I'm wrong, but as I read the article, Linus isn't convinced this is a good idea either.
I'm not saying things can never change, but opening for a mixed code base is a recipe for disaster. -
C++ is a semi automatic shotgun with 200 barrels pointing in all directions.
-
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.
-
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.
-
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.
-
You're wrong, but it's possible the article gave you that impression. Read the mailing-list thread.
It's particularly worth reading Ted T'so's contribution, which (considering his rude behaviour at the recent con led to a previous round of this nonsense) seems much more positive.
-
Did somebody say "provably correct"?
Haskell has entered the chat
-
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.
-
-
Because people already know C/C++.
-
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.
-
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.
-
Whilst it's gotten a lot better in the -17 and -20 iterations, the fact that there was recently a doorstop book published solely on the subject of C++ initialisation semantics is pretty telling.
I really like what Herb Sutter's doing around cppfront; I still wouldn't use C++ unless I absolutely had to.
-
T [email protected] shared this topic
-
- 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.
