I read through the entire exchange. Not a kernel dev, so this might not be the full picture
tl;dr
Tl;dr from my read through Wedson wants linux kernel to use rust as well as dynamic states within contexts to avoid memory overflows (making it safer and having less memory exploits).
However, doing dynamic states would require a massive overhall of the linux kernel (as it was designed with out that).
Linus doesn’t agree that dynamic states should be used because it isn’t realistic to cover every single state and the kernel must be able to keep running despite exeptions
IMO
Overall, I’m not really impressed with the responses from wedson. Mostly because they making suggestion with considering the complexities it would introduce. I know they’ve worked on other kernels, but it comes off ignorant. I hear there’s Redox, a kernel written with rust, but it isn’t the same as linux
analogy
I’d describe this situation is going to someone’s 20 yr old house and suggesting they replace all their wood walls and frames with brick/steel material just because in theory it’s fireproof and thus safer (even though it’s expensive and people will still find ways to set their house on fire).
The better suggestion is to build a model of their house, replace a floor with the suggested material, and document the process (pros, cons, challenges).
other thoughts
I guess they are experimenting it out with drivers first before changing the entire kernel?
Though why not fork the kernel and experiment there instead of on the main branch?
I would add that in real development, no one ever starts completely from scratch. The best solution would be to develop a hybrid interface. Develop some of the new stuff in Rust or develop a C and a Rust implementation in parallel. Test them document them and see what happens. Once you see how they perform and if the Rust implementation give you the things that you are looking for with minimal issues, then you continue to develop the new things in rust while going over the old code, sections at a time and build a Rust implementation. Eventually you will have two parallel code bases and once the majority of the important bits are converted over, you switch over to Rust only and finish up the behind the scenes work on the few remaining legacy code paths.
This has been my experience in my short stint as a full on developer and even with DevOps, this has always been my approach. Yes it creates more work, yes the results are not immediate, but if you run into a fundamental issue, you still have your legacy base to go back to or you cut support for things that cannot be migrated over. either way, you have flexibility and you do not throw out the baby with the bath water.
This is exactly why the idea of micro Kernels became a thing. Let the part that is freaking out fail while the rest of the system chugs along. If the failure is absolutely critical, then halt everything that depends on that failing part and log appropriately.
It is kind of the addage of if it hurts, don’t force it. Pain is a good feedback system. If you force continue, you may do more damage than stopping all together.