He actually did mention it if you look at the blog post his quote comes from. He's specifically calling for a Linux-ABI-compatible rust kernel that just re-implements things as they were rather than trying to delve into new researchy OS concepts like what Redox does.

Writing a Linux-ABI-compatible kernel in Rust will lead to a kernel no one uses. What would be the advantage of such a kernel? It would be much, much slower for many workloads and only be interesting to Rust hackers. In "Linux the OS", we are stuck with the "Linux the kernel", and Drew knows this very well. You will never catch up with the years of development that went into it. So if you want Rust in the kernel of "Linux the OS", you need to get Rust into "Linux the kernel" proper. This approach can work, see for instance the history of PREEMPT-RT.

> This approach can work, see for instance the history of PREEMPT-RT.

Good point, I note that realtime preemption has been in the works for more than twenty years, but (surprisingly) still isn't in mainline. On the other hand it's widely used and available and has caused lots of changes upstream already.

https://lwn.net/Articles/951337/

PREEMPT-RT is almost completely in mainline. As your linked article says, pretty much the last issue is printk. You can download the last patch here, it's not much anymore:

https://cdn.kernel.org/pub/linux/kernel/projects/rt/6.11/

And this is the only way you'll get large changes like these into the kernel: slow and steady.

> It would be much, much slower for many workloads and only be interesting to Rust hackers.

Why exactly?

Because if you write a kernel from scratch, things like the scheduler or the networking stack will be much, much less performant than the one from the Linux kernel. As I've written: you'll never catch up with the years and years of development that have poured into these systems.

Now, you could take these stacks from the Linux kernel and rewrite them in Rust, but that's not what Drew has suggested. Besides, that would also take ages: it's a lot of very complicated code, and a lot of it cannot just be transferred to Rust without it becoming unsafe, making the whole point of having a kernel in Rust moot.

> Because if you write a kernel from scratch, things like the scheduler or the networking stack will be much, much less performant than the one from the Linux kernel.

Yeah, I don't think you know this.

As I understand it, there have been schedulers written in Rust for Linux already which are faster in specific use cases.

> Now, you could take these stacks from the Linux kernel and rewrite them in Rust, but that's not what Drew has suggested.

As I understand it, Drew that's exactly what he suggested? He didn't say go write a new system. He said go write an ABI compatible system. It's hard for me to imagine he meant "Write an ABI compatible system with wildly different semantics."

> Besides, that would also take ages:

Agreed, and that's what makes his suggestion mostly ridiculous.

> it's a lot of very complicated code, and a lot of it cannot just be transferred to Rust without it becoming unsafe, making the whole point of having a kernel in Rust moot.

I think this passage confuses a few key concepts. First, I'm not really certain how much unsafe a scheduler or a networking stack would have to use. My guess is not that much. Do you have some reason to believe it would have to use an inordinate amount of unsafe? Next, simply using unsafe does not moot the safety argument for using Rust. I've said this about a billion times, but once more: unsafe constrain memory safety to a small enough area that one can reason about it.

To me Drew's article is a "bless your heart" answer that tells Rust users to go away, and keep themselves busy with something that nobody else will care about.

Maestro may be closer to what was suggested by the article.

https://news.ycombinator.com/item?id=38852360