Fair enough. I just worry that this momentum is a little premature and we'll end up creating as many problems as we solve. Rust is still quite a young language and while it has already proven itself it has also already taken on a lot of complexity despite its age and gone through several iterations of breaking changes too. I'm not entirely convinced that in 10 years time Rust wont end up as painful to audit as C++ is now. While Rust does offer some memory safety guarantees out of the box, that still depends upon the abstractions not needing to fallback to `unsafe` -- which isn't going to be avoidable with kernel development. And as the complexity of the code base and language semantics grow, the developers ability to audit `unsafe` is going to be will diminish in competency. And that's without even addressing the risk of introducing new bugs as part of the rewrite. Taking those points into account, I can't help feeling there's a little bit of "the emperors new clothes" going on here were the promises being made are greater than the reality.

I'm all in favour of a "rewrite it in $SAFE" but the risk adverse part of me feels like Rust is a combination of too young and lacking in formal guarantees to consider the massive undertaking we're asking here. Particularly when you consider this is going to be a multi-decade project and one that we can't trivially switch to another language if we regret that decision part way. To give context to that point: it's already been 30 years of C with Linux, longer if you count BSD or Unix. So the commitment we're asking from Rust is massive.

Maybe I'm being overly cautious. Unfortunately I've found the discussions on the topic are usually underwhelming in terms of people being prepared to honestly answer the hard questions about Rust's readiness for such a critical role. And that has left me feeling more nervous than reassured that the whole thing isn't just a fad.