part of the problem is that old-time kernel developers are used to C and don’t know Rust," Torvalds said. “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.”
Linus hit the nail on the head. If you’ve been a Kernel dev for a decade or more, and have spent decades learning the ins and outs of C, why would you want to switch to something that is similar, but different in a lot of ways, just because a small subset of devs think it’s the best way forward? Let them handle Rust and the majority of devs will keep using C, even though Rust is objectively better.
As one of the other quotes suggested: fork the kernel project and rewrite it entirely in Rust, that way there isn’t any push back from the C devs. Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it’s running or being used every day.
This specific talk was about defining shared common interfaces so these different groups could work together and the guy who actually talked him into stepping down essentially said “I’m gonna keep writing C and if that breaks your rust stuff that’s not my problem”. This isn’t about convincing the c devs to write rust it’s about convincing them to work together when some of them seem to have made up their mind to sabotage rust support (either through indifference or willful interface regressions). Personally I’m more ashamed what this points to for someone new wanting to come in contribute to Linux.
Ah, but I still agree with the C devs, it creates unnecessary headaches for them. Also, old habits die hard.
I view it as the same way ZFS is supported: Linus and Greg KH are like “you can maintain it, but we don’t give a shit about it, and if what we do breaks ZFS support, well too bad.”
The reverse is also true. Any dev wanting to contribute to Linux in rust which linus himself allowed (despite his silence on this matter) are just going to have to deal with constant headache trying to maintain compatibility with the C interfaces which the devs keep breaking. Either they should’ve never allowed rust in the kernel or they should force devs to at least act in good faith and collaborate (and any that refuse to, well they should be ousted because they can’t behave responsibly). This entire situation is so toxic and I see that as a failure in leadership. That zfs comment is also a little toxic but I don’t think it’s a direct quote. It also doesn’t seem like a fair comparison because from what I can tell zfs isn’t even part of the kernel code base and due to legal reasons cannot be. While it would be great for the kernel not to break it, it is, for all intents and purposes an external project. This rust debacle is different because it’s rust kernel devs and c kernel devs both operating in the same project and trying to find some kind of alignment. To me it seems like there’s enough of an acknowledgment of the value of memory safety that rust support was considered but there’s no authority figure actually supporting it or defending the devs that were invited to actually contribute in it. What a mess.
I think all the Rust devs should remove their code and leave. And when in the future the Linux devs change their tune and ask for their help, they should refuse.
The kernel is probably too large to rewrite the whole thing at once. This could lead to a future without any new C kernel devs, leading to stagnation, while the Rust kernel could be many years away from being finished. (Assuming we actually move away from C.)
At that point you might as well just start an entirely new kernel and hope it is good enough to eventually replace the Linux one once all devs are gone. Kinda the X11 and wayland thing.
the Rust kernel could be many years away from being finished.
the number I saw floating around was 3 years to production useful. regardless, C’s end days as the go-to, large systems level language are drawing nigh.
I think this number is overblown. Production useful doesn’t have to mean 1:1.
Running it without all graphics drivers would be fine for server use. Also, not all filesystems need to be ported: basic ones should be enough for start. But not only servers, home routers run Linux kernel…
If every OEM starts contributing their drivers in rust, this could move quickly…
I agree. C isn’t going anywhere anytime soon, but if we don’t start modernizing the kernel now we could end up with a future like the US government is in where all critical systems run on COBOL code and no one wants to touch it for the fear of breaking everything.
I’m not sure if it was in my above post or not, but the article said we should start modernizing the kernel now before someone does to Linux what Linux did to Unix.
Redox OS already exists and is functional (meaning it boots and has a GUI, but it’s lacking in various aspects), from what I understand it’s pretty much Linux/Unix rewritten entirely in Rust and looks pretty promising. In 5 or so years it could be a competitor with BSD and then overtake Linux once it has a proven track record.
As one of the other quotes suggested: fork the kernel project and rewrite it entirely in Rust
That’s not practically possible given the scale of the kernel. And doing a total rewrite is almost always a recipe for getting stuck and, if you ever create anything, creating something worse.
Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it’s running or being used every day.
Almost all real-world software development is like this. That’s what we do.
Yeah it is a monumental task, but it’s also the one with the least push back. I don’t mean start from scratch, but convert the C code to Rust in a dev branch or something and release a Linux-Rust kernel image.
Almost all real-world software development is like this. That’s what we do.
I’m aware, I’ve written my own software even though I’m a SysEng, all I’m saying is that it’s not an easy process with a potential for disaster. Just look at CrowdStrike (not saying that they were attempting to switch languages but just the scale of the fuck up and the fallout that it caused), we don’t want that to happen with Linux.
I’m not rejecting it, I’m just saying that it’s very difficult to completely change the code of a critical piece of software. The long-term goal is for Rust to overtake C in the kernel (from what I understand, I’m a System Engineer, not a software dev. I know Go, not Rust) due it being memory-safe and about 30 years newer. Critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit (and get bitched out by Linus 😂) so I’m sure there is tons of code from the early 90s that could be made better with a newer language like Rust, but it’s not as mature as C right now so that’s not going to happen for a while, if at all.
The long-term goal is for Rust to overtake C in the kernel (from what I understand
Your understanding wrong. Rust is limited to some very specific niches within the kernel and will likely not spread out anytime soon.
critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit
The entire kernel is “critical”. The entire kernel runs - kind of by definition - in kernel space. Every bug there has the potential for privilege escalation or faults - theoretically even hardware damage. So following your advice, nobody should every touch the kernel at all.
I’m a C/C++ dude but I heard it being called the “Karen compiler”. It doesn’t look that scary based on samples I’ve seen, but there’s way more to it I am assuming.
I’m no Rust expert, but in my experience the borrow checker is a pain for a bit, then you start to get a sense of what works and what doesn’t, and after a while it has taught you to write cleaner code.
“Karen compiler” is almost perfect, except unlike Karens, the compiler is delightfully helpful with the error messages it gives you (usually). It usually gives a straightforward error, an error code, and sometimes, an easy fix.
As someone that started with Rust, but just yesterday had to fix some C++ code, working with any other compiled language makes me shudder. I have nothing but respect for devs that have to wade through stuff like that.
I’m not a software dev (I’m a SysEng), and have never touched Rust (I’ve looked at the Rust source code and it scares me haha), but I know a fair amount of Go, and even the Go compiler is a pain in the ass occasionally. I’ve “mother fucked” it so many times.
I’m not a software dev, but I’d imagine that the codebase could definitely be reduced once most things are converted to Rust. From what I’ve heard, the kernel is a huge mess of spaghetti code that most people don’t want to touch, for the fear of going insane in the process 😂
Linus hit the nail on the head. If you’ve been a Kernel dev for a decade or more, and have spent decades learning the ins and outs of C, why would you want to switch to something that is similar, but different in a lot of ways, just because a small subset of devs think it’s the best way forward? Let them handle Rust and the majority of devs will keep using C, even though Rust is objectively better.
As one of the other quotes suggested: fork the kernel project and rewrite it entirely in Rust, that way there isn’t any push back from the C devs. Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it’s running or being used every day.
This specific talk was about defining shared common interfaces so these different groups could work together and the guy who actually talked him into stepping down essentially said “I’m gonna keep writing C and if that breaks your rust stuff that’s not my problem”. This isn’t about convincing the c devs to write rust it’s about convincing them to work together when some of them seem to have made up their mind to sabotage rust support (either through indifference or willful interface regressions). Personally I’m more ashamed what this points to for someone new wanting to come in contribute to Linux.
Ah, but I still agree with the C devs, it creates unnecessary headaches for them. Also, old habits die hard.
I view it as the same way ZFS is supported: Linus and Greg KH are like “you can maintain it, but we don’t give a shit about it, and if what we do breaks ZFS support, well too bad.”
The reverse is also true. Any dev wanting to contribute to Linux in rust which linus himself allowed (despite his silence on this matter) are just going to have to deal with constant headache trying to maintain compatibility with the C interfaces which the devs keep breaking. Either they should’ve never allowed rust in the kernel or they should force devs to at least act in good faith and collaborate (and any that refuse to, well they should be ousted because they can’t behave responsibly). This entire situation is so toxic and I see that as a failure in leadership. That zfs comment is also a little toxic but I don’t think it’s a direct quote. It also doesn’t seem like a fair comparison because from what I can tell zfs isn’t even part of the kernel code base and due to legal reasons cannot be. While it would be great for the kernel not to break it, it is, for all intents and purposes an external project. This rust debacle is different because it’s rust kernel devs and c kernel devs both operating in the same project and trying to find some kind of alignment. To me it seems like there’s enough of an acknowledgment of the value of memory safety that rust support was considered but there’s no authority figure actually supporting it or defending the devs that were invited to actually contribute in it. What a mess.
I think all the Rust devs should remove their code and leave. And when in the future the Linux devs change their tune and ask for their help, they should refuse.
Just because some deva are assholes you gonna sabotage the work of the others 10 thousands?
I get the sentiment but that is in no fashion a way to move forward.
Well, when I’m not wanted I tend to burn bridges.
The kernel is probably too large to rewrite the whole thing at once. This could lead to a future without any new C kernel devs, leading to stagnation, while the Rust kernel could be many years away from being finished. (Assuming we actually move away from C.)
At that point you might as well just start an entirely new kernel and hope it is good enough to eventually replace the Linux one once all devs are gone. Kinda the X11 and wayland thing.
You can very safely remove the “probably” from your first sentence.
the number I saw floating around was 3 years to production useful. regardless, C’s end days as the go-to, large systems level language are drawing nigh.
edit: tear
I think this number is overblown. Production useful doesn’t have to mean 1:1.
Running it without all graphics drivers would be fine for server use. Also, not all filesystems need to be ported: basic ones should be enough for start. But not only servers, home routers run Linux kernel…
If every OEM starts contributing their drivers in rust, this could move quickly…
I agree. C isn’t going anywhere anytime soon, but if we don’t start modernizing the kernel now we could end up with a future like the US government is in where all critical systems run on COBOL code and no one wants to touch it for the fear of breaking everything.
I’m not sure if it was in my above post or not, but the article said we should start modernizing the kernel now before someone does to Linux what Linux did to Unix.
Redox OS already exists and is functional (meaning it boots and has a GUI, but it’s lacking in various aspects), from what I understand it’s pretty much Linux/Unix rewritten entirely in Rust and looks pretty promising. In 5 or so years it could be a competitor with BSD and then overtake Linux once it has a proven track record.
That’s not practically possible given the scale of the kernel. And doing a total rewrite is almost always a recipe for getting stuck and, if you ever create anything, creating something worse.
Almost all real-world software development is like this. That’s what we do.
Yeah it is a monumental task, but it’s also the one with the least push back. I don’t mean start from scratch, but convert the C code to Rust in a dev branch or something and release a Linux-Rust kernel image.
I’m aware, I’ve written my own software even though I’m a SysEng, all I’m saying is that it’s not an easy process with a potential for disaster. Just look at CrowdStrike (not saying that they were attempting to switch languages but just the scale of the fuck up and the fallout that it caused), we don’t want that to happen with Linux.
It blows my mind that Linus is just so darn based all the time. That guy has a good take on like every issue.
Strong opinions. Sometimes Linus’s takes are ‘bangers’ &, while probably fewer, he’s had a lot ‘woofs’ on the opposite end.
got some examples of the woofs? I’m not doubting the claim just interested :D
That’s in no way what’s been proposed. Rust is used in a very well defined niche, nobody wants to get rid of C.
But it’s just that sentiment that got us here, you’re arguing against a non-existent threat, and thus reject the whole proposal.
I’m not rejecting it, I’m just saying that it’s very difficult to completely change the code of a critical piece of software. The long-term goal is for Rust to overtake C in the kernel (from what I understand, I’m a System Engineer, not a software dev. I know Go, not Rust) due it being memory-safe and about 30 years newer. Critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit (and get bitched out by Linus 😂) so I’m sure there is tons of code from the early 90s that could be made better with a newer language like Rust, but it’s not as mature as C right now so that’s not going to happen for a while, if at all.
Your understanding wrong. Rust is limited to some very specific niches within the kernel and will likely not spread out anytime soon.
The entire kernel is “critical”. The entire kernel runs - kind of by definition - in kernel space. Every bug there has the potential for privilege escalation or faults - theoretically even hardware damage. So following your advice, nobody should every touch the kernel at all.
In some of its characteristics, Rust is certainly a good language. The borrow checker, however, still haunts my restless dreams today.
The borrow checker is exactly what the kernel needs.
I’m a C/C++ dude but I heard it being called the “Karen compiler”. It doesn’t look that scary based on samples I’ve seen, but there’s way more to it I am assuming.
I’m no Rust expert, but in my experience the borrow checker is a pain for a bit, then you start to get a sense of what works and what doesn’t, and after a while it has taught you to write cleaner code.
“Karen compiler” is almost perfect, except unlike Karens, the compiler is delightfully helpful with the error messages it gives you (usually). It usually gives a straightforward error, an error code, and sometimes, an easy fix.
As someone that started with Rust, but just yesterday had to fix some C++ code, working with any other compiled language makes me shudder. I have nothing but respect for devs that have to wade through stuff like that.
To be fair, most of them aren’t as nasty as C++. But Rust certainly gives you a sense of security you don’t get with most other languages.
At least it has something to complain about, unlike Karens.
Ha, I’ll steal that! “Karen compiler” - quite fitting, to be honest.
Oh, so the main reason why it’s so good?
I’m not a software dev (I’m a SysEng), and have never touched Rust (I’ve looked at the Rust source code and it scares me haha), but I know a fair amount of Go, and even the Go compiler is a pain in the ass occasionally. I’ve “mother fucked” it so many times.
Tl;Dr: Old farts holding us back, as always
“If it ain’t broke, don’t fix it!”
I’m not a software dev, but I’d imagine that the codebase could definitely be reduced once most things are converted to Rust. From what I’ve heard, the kernel is a huge mess of spaghetti code that most people don’t want to touch, for the fear of going insane in the process 😂
Rust is not objectively better. That’s your opinion