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.
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.
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’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.
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.
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.
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…
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.
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
Rust is not objectively better. That’s your opinion