The slide deck comes to this conclusion, at least for now. Rather, he discusses a hybrid approach of writing certain modules / drivers of a C-based kernel in Rust so it can be done a little bit at a time.

The reason for "no" given: "why completely replace what works already" paired with "fighting second system syndrome". It's not a real "no", but reasons why it's challenging. Aren't those always the case? It shouldn't stop something new from appearing.

I was expecting to see this type of response. I don't program at low levels but it seems like this would be the responding answer. Kernel programmers would be using something else if that's what they wanted to use. Decades of experience and hard learnt lessons down the drain.

The entire point of the presentation is to discuss these issues, and recommend rust for more ancillary tasks (modules/drivers, firmware, utilities) than the kernel itself.

> Kernel programmers would be using something else if that's what they wanted to use.

The vast majority of the languages having arisen in the last 40 or so years are completely unsuitable for kernel development, so not necessarily.

On the other hand, the design of Rust is directly and deeply influenced by those very lessons.

Less “down the drain,” possibly more close to “baked directly into the tools we use.”

Also, if you can abstract away at a sufficiently low level why not just do it in C where there's already a generation of experience and familiarity?

Sure, why not just continue writing C for the rest of time?