Linux

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.

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

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.