I don’t know why this reads so skeptical:
“The team has been setting the groundwork for new components/drivers to be written in Rust but as these are developed, we’re running into some roadblocks,” he told us. “[Linux creator Linus] Torvalds doesn’t seem to care, or perhaps believes they are appropriate. Time will tell.”
Some days ago what I read was this:
Switching to a more modern topic, the introduction of the Rust language into Linux, Torvalds is disappointed that its adoption isn’t going faster. “I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don’t know Rust. They’re not exactly excited about having to learn a new language that is, in some respects, very different. So there’s been some pushback on Rust.”
Hell, I’m 19, using C for 5 years or so now and not even I like the Rust syntax and compiler!
Bluepilled by null.
And of course the conclusion is
If working with other open source developers is too hard, they could always fork the project.
Just fork it 🤓
It definitely feels like a knee jerk reaction, but there would be some merit to it: The Rust language feels apt to implement a kernel with. If I remember correctly that’s what Redox is trying to accomplish? https://redox-os.org/
I think there’s a problem with the ‘C only’ devs refusing to be accomodating to the Rust developers. Instead of being stubborn; why not provide them what is needed and help the Rust team learn how to maintain what is needed themselves?
None of the reasons I’ve seen mentioned are legitimate reasons for refusing to at least help them a few times, and helping them to learn how to do the onerous task themselves so they can keep it off the main plate for too long.
C devs do not need to learn Rust to provide critical information; they need only be present and cooperative with Rust devs to help them find, convert, and localize data structures for Rust use. They can stand to sit and pair code with their Rust Dev counterparts long enough to teach a Rust Dev counterpart how and what they need to look for in C code. It’s not that big of an ask, and it’s not something that really is a large ask. Provide the bindings for a short period of time, and work on training a team of Rust Devs to maintain the bindings.
That way both sides are stepping up to meet the others and the data isn’t being sat on by the C-only Devs.
Absolutely correct!
“I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix.”
Linux has no owner, really, aside from Linus. How can IBM wrangle a reversal in the sale of it back to Novell who has no more devs to maintain it - because they sold it - and they put it on the shelf for 20 years until it’s dead?
I don’t get how this is like how Unix was killed; at all.
BSD was a mortal wound on UNIX, AT&T lawyers killed BSD, Linux swooped in.
From an outsiders perspective, a lot of the “politics” seemed to be that Rust devs would try to change behavior they saw as bugs and Linus would have to be like: “it doesn’t matter, we don’t break userspace functionality with changes we make to the kernel! [not a direct quote, but a paraphrase]”
Devs not wanting to learn Rust is something I’m not at all equipped to comment on since I don’t know C or Rust (some C++, python, Powershell and a few other scripting languages though) so I can’t say how difficult that transition would be, but at the very least it seems like they must not be convinced of its need.
Anyone with more knowledge able to chime in on if it seems this is a self induced problem on their end or genuinely something the other kernel devs are being difficult to work with?
ETA: My memory of this seems to be completely incorrect! Sorry for the misinformation!
Do you have an example where Rust devs wanted to break backwards compatibility? The complaints I’ve seen were mostly “I don’t want to learn another language, so your Rust stuff will be broken by us”
In fairness, “I don’t want to maintain bindings for a language I never intend to use” is a perfectly reasonable position.
The typical answer here is for the language evangelist to implement and maintain the bindings, and accept the responsibility of keeping them in sync with the upstream (or understand that they will be broken for however long it takes for another community member to update them).
Which is exactly the position that the Rust for Linux devs have understood and accepted for themselves, and yet they still get yelled at (literally, in public, on recordings) by C Linux devs for existing.
Oh and they get snidely told that introducing the Rust language must be a mistake because suggestions to introduce other languages to the kernel turned out to be mistakes and obviously Rust is the same as all those other languages according to C developers who, by their own admission, have never used or learned anything about Rust beyond a superficial glance at some of its syntax (again this was recorded from a public event).
Ted Ts’o was way out of line in that conference and was clearly channeling his inner ca. 2001 Torvalds.
I think Rust is a better path forward for a majority of the kernel/driver code maintained currently, but it is definitely going to take time for it to gain a foothold. I also think there is some condescension on both sides that is completely unjustified and needs to stop.
The hardline C devs that don’t want to learn Rust need to accept that at some point they will have to either adapt or pass the torch, and that no amount of whining or bitching in public forums is going to change that.
The Rust devs that are getting upset because people are “attacking” their favorite language need to accept that there will be substantial and impassioned resistance to making broad language changes to a set of projects that have existed for decades. It would be an uphill battle for any language to try to supersede C in the kernel; this is not a condemnation or attack on Rust or its zealots, it’s a matter of momentum and greybeard stubbornness.
A quick search and I’m not able to find anything, so either I’m not using the right search terms or I’m completely off the mark and am mixing up my Tovald Rants.
If I mixed that up, I’m so sorry for spreading FUD!
There was a rant like that but directed at a specific developer that was pushing a userspace breaking change. It was not related to a Rust.
Thanks! I know I’ve seen more than and I thought a couple had been about Rust, for some reason!
I am sorry, but these rust evangelist’s are a bit ridiculous. Rust is I great language. But saying that the Linux kernal not having a future because not everyone will adapt a new programming language is stupid. Does he not realize he is putting alot more technical burden on the remaining maintainers that need to learn a completely different language because he decided the kernel suddenly neeeds rust, thanks I guess?
Nobody gets forced to port kernel stuff to rust. Also the rust compiler takes a lot of burden from maintainers by the safety it enforces.
The whole conflict ist not a technical one, it is entirely human. Some long-term kernel developers don’t like people turning up and replacing the code they wrote. Instead of being proud that the concepts they built get to be elevated in a superior implementation, they throw tantrum and sabotage.
The article itself proves you wrong on this one, my friend. The situation is less simple and more subtle than you’re claiming.
Of course ego is a factor. That’s true for every organization in the world. But there are many other highly relevant factors in play here.
Could you name some then. I don’t really see any in the article.
Spreading bs i see. Go watch the source video
C has not aged well, despite its popularity in many applications. I’m grateful for the incredible body of work that kernel developers have assembled over the decades, but there are some very useful aspects of rust that might help alleviate some of the hurdles that aspiring contributors face. This was not a push by rust evangelists, but an attempt to enable modernization efforts at least for new driver development. If it doesn’t work out, that’s fair enough but I’m grateful for the willingness - especially of Linus - to try something new.
In a different article, he said he had issues with the ext4 maintainer who was acting high and mighty about C despite being responsible for a number of huge CVEs from code that he wrote.
That being said, I don’t really see the benefit of rewriting modules in Rust.
Technically, it’s still not a 1:1 replacement because Rust will many times not generate the exact same machine code as C, which does result in a small loss of speed (and in some small cases, vice versa).
It’s acceptable for anything new, but unless there’s a notoriously painful part of the kernel, there’s no pont in redoing existing parts and even core userspace binaries.
C quite literally makes you manipulate memory like a caveman holding a machine gun, but that’s important because it’s exactly what the machine is doing, which is required when you need to maximize efficiency. In Rust, you’d have to abstract some of that to the compiler to handle your logic which doesn’t match what a machine is doing. There is no such thing as “borrowing” and “ownership” in machine code.
(As if spoken by the King to Simba:)
Rust: Everything from the bottom of this cliff to the acacia tree there is ours. Make sure you ask permission before you take something, take nothing you are not permitted to take. We don’t go beyond that tree; and if you even think about the elephant graveyard beyond it; I’ll kill you myself.
C: Everything the sun touches is yours. I caution you to not venture into the shadows; but I will not stop you, for you are a king, and nothing a king can do is unnecessary if it is for his people.
