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.

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.

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.

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.

RedoxOS! There's been solid progress too, beyond just having a functional microkernel, they have many of the userspace tools/their version of coreutils, even a desktop environment already mostly implemented!

My understanding is that it shouldn't be too bad to port some other things over as well. The main issue I had was just the lack of drivers, especially since it's still tricky even on Linux, and the microkernel architecture (though more secure) also means there's no way to reuse any of those from Linux

Good news there's a project that aims to implement Unix in Rust called Redox and it's already a good enough project for studying microkernel design

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.

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.

It blows my mind that Linus is just so darn based all the time. That guy has a good take on like every issue.

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.

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.

wd40

We are all such dorks.

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.

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".

I heard that C developers are trained to use memory smartly

Kernel coders are an entirely different breed, and when I worked with a few of them they were just stunning. The smartest man I know on the planet so far coded on the Unix kernel -- the one that IBM forced back to Novell who'd already fired their staff after selling it, and thus shelved it and killed Unix. He is and was amazing.

So yes, I can confirm that Kernel devs know how to manage their memory -- they use very little, they allocate and free it, and they build very small, tight, optimized kernels by knowing how the optimizer will do things and how to hint it to do what they know needs to happen.

Yeah, it's a skill. Yeah, it takes skilled people. I'd like to one day find out that really big training wheels will let anyone build code that well, but I've seen the goal and I don't expect we're there yet.

Let the kernel be built by kernel devs.