- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
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?
That does NOT sound like a good idea.
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:
Seems like Linus isn’t onboard with this.
But I guess all the downvoters know better?
Greg Kroah-Hartman:
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:
And earlier:
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.
To the contrary:
https://lemmy.ml/post/26272942
Moving from C to C++ would also not solve any real problem. C++ of course adds OOP which I think can be nice (not everyone agrees with this!) but it also adds an insane amount of language complexity and instability. Mentally reasoning about C code is hard, reasoning about C++ code is nearly impossible.
Rust however brings a novel solution to classes of problems like ownership and mutability with the borrow checker. It’s now accepted to be a great tool for writing high performance code while preventing a substantial amount of common, but often subtle, bugs from slipping through. It’s not arbitrarily the first non-C code to be accepted in the kernel. And it’s used in other operating systems like Android and Windows already.
In general, for me, Rust > C > C++.
I’ve heard people say that C is like a loaded and cocked revolver, and if you’re not careful, you could blow your foot off, whereas C++ is like a loaded and cocked sawed-off shotgun, and if you’re not careful, you could blow your leg off.
C++ is a semi automatic shotgun with 200 barrels pointing in all directions.
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.
Mostly this ^.
There’s just not really demand for C++ in the kernel; that’s not the case with Rust.
I think rust would also bring in more developers. So more changes would eventually make its way into the kernel.
I envy your confidence!
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.
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.