Here's the thing: you're not going to force all of us to learn Rust.
That's precious coming from Linux developers.
I am a heavy Linux user. I run multiple microservices on multiple headless devices all Linux.
This sounds like every fucking Windows user you'll ever encounter.
"Here's the thing: you're not going to force all of us to learn to use Linux."
So, yeah...
It's just their ego showing through.
It basically now comes down to the current devs depending on new Rust devs for anything that interacts with Rust code.
They could just work together with Rust devs to solve any issues (API for example).
But their ego doesn't allow for it. They want to do everything by themselves because that's how it always was (up until now).
Sure, you could say it's more efficient to work on things alone for some people, and I'd agree here, but realistically that's not going to matter because the most interactivity that exists (at the moment) between Rust and C in Linux is... the API. Something that they touch up on once in a while. Once it's solid enough, they don't have to touch it anymore at all.
This is a completely new challenge that the Linux devs are facing now after a new language has been introduced. It was tried before, but now it's been approved. The only person they should be mad at is Linus, not the Rust devs.
Switching everything from C to Rust because it has better memory safety is more akin to changing languages from English to Esperanto because it has gender neutral pronouns and other cool features. Maybe it's a good idea, but it's understandable that some people are reluctant.
Maybe it’s a good idea, but it’s understandable that some people are reluctant.
I understand that position. I also understand how the words and phrases that the C community has used to communicate with the Rust community seems to be completely dismissive, not just reluctant.
I quoted what I did explicitly because of how a statement like that comes off to the person it's aimed at. It doesn't make them feel like they're on an even footing working on the same project with the overall goal of it becoming better.
memory safety is more akin to changing languages from English to Esperanto because it has gender neutral pronouns.
I mean... not at all? Memory safety is huge for cybersecurity, buffer overflows and the like are common attack surfaces. C requires you to have deep knowledge of safe memory management practices and even then you can end up with memory issues. Rust was developed to avoid such issues entirely. I understand the reluctance but it feels to me like arguing "we should just stick with COBOL because it works."
Gender neutral pronouns are pretty huge too. Sure you can do them in English without too many problems usually, just as it's also possible to code safely in C. It requires everyone to change their old habits, but it's much less of a change than is involved in adopting a whole new language.
Anyway, I do like Rust better personally.
I would still say that getting people to the point where they can write safe C code every time is harder than learning Rust, as it’s equivalent to being able to write rust code that compiles without any safety issues (compiler errors) every single time, which is very difficult to do.
Vast majority of the cybersecurity community: "an absolute ton of exploits come from memory safety issues with C/C++, we should move to memory safe languages like Rust to greatly reduce security risk and make everyone safer"
You: "Ehh Rust has a couple features, but it's totally not worth switching from my precious precious C"
I finally watched the talk today and that wasn't what I thought he meant. What I thought he was getting at was that the rust parts of the kernel interact with lots of other modules written by people who don't know rust. When those C modules change their semantics in ways that break the rust code, they can't go fix it because they don't know rust. In fact, whenever they make a change, they don't even know if they broke some rust module, because they don't understand the rust code well enough. And this is something that everyone is going to have to live with for the foreseeable future, because you can't force all those other kernel hackers to learn rust.
"It’s herding cats: introducing Rust effectively is one part coding work and ninety-nine parts political work..."
All software development in a team is. More like 20/80 or 40/60 if you're lucky.
Except in this case, it was a bunch of old C devs who aren't just resistant but openly hostile to change, and they'd rather bully people into silence than try to progress.
Several downvotes with zero comments to refute or discuss your point. Some devs don’t like you calling them out
In a twist of delicious fate, my instance doesn't have downvotes. They get dropped before they even hit the database. So I'll never know or "feel ashamed" if they don't bother to take time to refute it. 🤣
If I go to any of the teams I interact with who program their components in C++ and proposed Rust or anything else, I'd get a similar reaction. They're very good at C++ and they very rarely have memory and threading issues. 😂
They very rarely have memory and threading issues
It's always the "rarely" that gets you. A program that doesn't crash is awesome, a program that crashes consistently is easy to debug (and most likely would be caught during development anyway), but a program that crashes only once a week? Wooo boy.
People vastly underestimate the value Rust brings by ensuring the same class of bugs will never happen.
They don’t get, that without memory issue resistant language, not a lot of new blood will be as good as them dealing with that stuff since they already have that solved in the language itself.
It is about making kernel development future proof, so that new devs keep on coming and don’t create massive security holes on the way.
Well this is how I understand it.
And it's a bad argument anyway. You're only good at memory management until the first bug takes down production.
Rust isn't a panacea and certainly has problems, but eliminating an entire class of potentially very dangerous bugs is a very good argument.
Note that Rust does not "solve" memory management for you, it just checks whether yours is memory safe. Initially you might rely on the borrow checker for those checks, but as you become more and more used to Rust you'll start to anticipate it and write code that already safisfies it. So ultimately you'll still learn how to safely deal with memory management, just in a different way.
Here's what I think. Both opinions are correct.
Rust is sufficiently different that you cannot expect C developers to learn rust to the level they have mastered C in order to be working at the kernel level. It's not going to happen.
I don't really know too much about rust. Maybe one day I'll actually mess around with it. But the one time I looked at a rust git repo I couldn't even find where the code to do a thing was. It's just different enough to be problematic that way.
So I think probably, the best way IS to go the way linus did. Just go ahead and write a very basic working kernel in rust. If the project is popular it will gain momentum.
Trying to slowly adapt parts of the kernel to rust and then complain when long term C developers don't want to learn a new language in order to help isn't going to make many friends on that team.
But that's the thing where you are wrong. They clearly state they don't want C developers to learn Rust. In the particular video posted he was saying "I want you to explain to me how this particular API works so that I can do it"
The concerns about who fixes what on a merge when the C code breaks Rust code are valid, but that's easily fixed by gathering with the Rust developers, explaining the changes and letting them fix it.
You could alternatively phrase "But that's the thing where you are wrong" as "But here's the crux of why I disagree", it's a bit more personable
This isn't a disagreement. One person is stating something incorrect. You can disagree on opinion, but facts are facts. The person being referred to here isn't asking others to learn Rust, they are just asking for more information about the already existing C code so that they can write their Rust code to interoperate with it. This misunderstanding is exactly why that developer was getting heckled on stage, and is the reason why now one has left the project. I would appreciate it if you didn't make a misunderstanding sound like a valid opinion. Enough damage has already been done.
But the one time I looked at a rust git repo I couldn't even find where the code to do a thing was.
IMO that tells more about how the project was organized and names things than the language used.
So I think probably, the best way IS to go the way linus did. Just go ahead and write a very basic working kernel in rust. If the project is popular it will gain momentum.
As the other commenter pointed out, there's Redox. The issue is that this completly disregards an incremental approach: you have to rewrite everything before it comes usable, you can't do it piece by piece. Currently the approach of Rust for Linux is not even to rewrite things, but to allow writing new drivers in Rust.
Trying to slowly adapt parts of the kernel to rust and then complain when long term C developers don't want to learn a new language in order to help isn't going to make many friends on that team.
Have you seen the conference video? That's not just refusal to learn a new language, it's open hostility. And it's not the only instance, for example Asahi Lina also reported unreasonable behaviour by some maintainers just because she wrote Rust code, even when Rust was not involved.
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.
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.
It blows my mind that Linus is just so darn based all the time. That guy has a good take on like every issue.
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.
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.
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.
even though Rust is objectively better.
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.
One detail about Rust in the kernel that often gets overlooked: the Linux kernel supports arches to which Rust has never been ported. Most of these are marginal (hppa, alpha, m68k—itanium was also on this list), but there are people out there who still use them and may be concerned about their future. As long as Rust remains in device drivers only this isn't a major issue, but if it penetrates further into the kernel, these arches will have to be desupported.
(Gentoo has a special profile "feature" called "wd40" for these arches, which is how I was aware of their lack of Rust support. It's interesting to look at the number and types of packages it masks. Lotta python there, and it looks like gnome is effectively a no-go.)
It seems like gcc rust would pretty much fix that issue, since soon gcc will be able to compile rust for any architecture gcc supports.
i wonder if theres a goose farm in his future
Ted is the maintainer of ext4 and there are not many people in the world who understand this code.
For Rust to succeed, it has to get the subsystem maintainers to agree. It is going to be many years of petting very angry bobcats...
And that is not even the worst I've heard, makes you a bit numb if you follow LKML.
not many people in the world who understand this code.
Kinda sounds like maybe he writes some freaky garbo C that nobody can figure out 😅
Developers who are not willing to learn something new and not adapt are the worst. Besides that, nobody is forced to learn Rust, only those who want to work on Rust parts.
Developers who are not willing to learn something new and not adapt are the worst.
And this is why COBOL developers are desperately needed these days: because too many people think that "old" was the same thing as "needs a replacement".
"Learning something new" does not mean the thing you are learning is new. It just means it's new to you. One of the best things you can do for yourself as a dev is to learn to be fluid and be able to adapt to new languages, protocols, and technologies.
The situation of COBOL has nothing to do with Rust in Linux. C is not replaced by Rust, first. Secondly, there are legitimate reasons why Rust was introduced, as a secondary language. You are conflicting two different cases that are two different problems. It's not replacing a language.
Not an expert in both the languages but I heard that C developers are trained to use memory smartly, sometimes even reuse a range of allocated memory for completely different purpose to save cycles freeing and reallocating. But for Rust developers, everything is about making sure when one should get the hand away from the memory, and whose memory is allowed to be touched.
Sounds to me like sharing rides that maximise economically but we may have some oops moments sitting on someone's laps vs absolute private rides to make sure no one in your family will be harmed but we have to make sure everyone gets a car only when needed.
It is quite interesting to see how it will work out eventually...
IMO this has been very publicized in certain circles, and will have the effect of martyrdom. More people are going to be interested in doing this.
Adding rust to a massive mature C project that targets lots of architectures and has many contributors is a difficult process. If it succeeds it is going to take a lot more time and patience.
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
