Every week or so there seems to be drama about some old dude shouting about how rust in the Linux kernel is bad. Given all the open hostility, is there easier way for R4L to continue their work?
I dont think that there is another way. They are gonna have to coexist with the old guard. The problem is, they are both right. Rust is the better language, its basically made for this task, but C runs everywhere, it has a much larger userbase, and introducing a second language into a huge low level program like Linux will make it much, much harder to maintain.
Why would you say that Rust is made for low level hardware interfacing? I am generally curious.
I was only alluding to the fact that its a low level language like C, but with a more modern design and safety features, not anything specific, sorry!
I once heard that a major problem is that you have to disable or work around Rusts safety features once you write hardware interfacing code like a os kernel
Not really. While working at the OS-level can typically require ‘unsafe’ operations a core tenet of writing Rust is making safe abstractions around unsafe operations. Rust’s ‘unsafe’ mode doesn’t disable all safety checks either - there are still many invariants that the Rust compiler enforces that a C compiler won’t, even in an ‘unsafe’ block.
And even ignoring all of that, if 10% of the code needs to be written in Rust’s ‘unsafe’ mode that means the other 90% is automatically error-checked for you, compared with 0% if you’re writing C.
Why do you think its a problem that this is discussed a lot? Its a huge deal, so its only good its discussed and not accepted by everyone. I think this is healthy. We only read about the drama and a few quotes, but if you look closer then their argumentation makes a bit more sense. It is not just drama for the sake of drama. Some maybe toxic, that is another thing, because they would be toxic with other topics too.
Here is in a videoformat from ThePrimeagen (programmer at Netflix, or he was, not sure about current state) going through a recent discussion in the Linux Kernel mailing list about this topic. It’s about a hour long and adds some thoughts on its own too, which was valuable to me. - https://www.youtube.com/watch?v=8QcQ_128OIw
Writing a kernel in two languages when it has for its entire history been written in one is just asking for needless complexity.
If Rust wants to have a kernel, then perhaps port or re-write Linux in Rust from scratch as a separate project. Once it’s reached a point of being self-hosting, let ‘the market’ decide in an open competition.
If the Rust version is demonstrably superior and more secure, then it’ll naturally supplant ‘legacy Linux’.
You say it’s “needless” complexity. But that’s what’s up for debate, and most people, including Linus seem to disagree with you.
It’s not a matter of whether Rust is demonstrably superior and more secure, that it is seems to be the common understanding and agreement.
A new project matching reasonable Kernel feature-parity would be too much effort. It’s unrealistic.
The value is in moving the Kernel itself into a safer space and tool-space.
The idea that a technically superior solution would naturally supplant an earlier one with a huge market penetration and stability is wishful thinking. We see it in many areas. Without significant issues people at large will stay with what they know and what is popular.
I know at some point in history there was talk about going to C++ but Linus brushed it off because he didn’t liked it. This time he thinks otherwise.
So trying to get Linux into another language is no new talk.
And Zig is becoming a thing. I do not know if it will be ever suitable for such task, but it seems like moving on from C or complementing C’s kernel development with Rust, Zig or whatever comes with the future is just a matter of time.
It will not happen overnight as a fork will not happen overnight so the only way forward seems to be patience.
With the amount of people burning out and the open hostility, no matter how much support seems to be said in the practical sense it doesn’t materialize. The interests are clearly not aligned and keep grinding like this won’t do any good to anyone mentally for sure.
I can only imagine it happening with a downstream out of the tree patchset where the rust people will just do what they need to do and eventually a bunch of drivers will start to be done in that branch that will never be ported to the mainline. It could take a decade more for that work to maybe go back into the kernel. Like other similar efforts happened before.
Fork.
I don’t understand why they haven’t yet. Prove your rust kernel is more efficient than the C/C++ kernel and it’ll be adopted.
There is no point in forking. The problem is not adding Rust to the Kernel, the problem is the C developers to get to work on it together. Forking does not solve this issue. Its not about proving being more efficient or not.
There is no reason for it. The odds of success would be low compared to the current process which for the most part is going along pretty well despite all the melodrama surrounding it.
I agree 100%. I was just commenting that those creating the drama should go waste their resources to reinvent the wheel. See what they can come up with. Gets them and their nonsense out of my feeds for a bit.
I don’t understand why the R4L are even trying to get it into THE kernel at this point. Especially after the open hostility, but also after basically offering to be “downstream” of whatever C people do.
The difference to forking and gradually transitioning things to Rust seem technically minimally negative and socially enormously positive to me.
And when and if people want to use the linux kernel with Rust, made by the R4L people, they would then be able to do that? Idk.
I have no stakes in either side, so I don’t really care.
I think the issue with that would be increasingly working catch-up on newer developments of replaced functionalities.
If your end-goal is integration then it’s better to integrate early rather than late.
Developing and maintaining an interface and abstraction and having to keep that up to date is one thing. But after replacing some modules and components, any developments on their originals raises the question of how does that apply to our Rust module? If it already were in the Kernel and had replaced that module or component, that effort would not arise.
