Not to get too deeply into a "hey, Windows isn't terrible!" conversation - which I haven't even really seen come up in a very long time - I think I've gotten less than 5 BSODs in the last 10 years? The last time I saw enough BSODs where I even noticed them was because I had bought a bad DIMM, and no computer can work right when the RAM is corrupting itself. Ever since Windows 7, I think Microsoft has done a really good job on this.

That said - as someone who has not worked with Rust ever, and as someone who hasn't touched C/C++ in 25+ years - everything I know about Rust vs. C/C++ tells me that if Microsoft is making this move, it should definitely should increase the stability of the OS, and more than that, I think it should increase the *security* of the OS.

Many years ago (I think I wrapped up in 2012 or 2013?), I wrote for TechRepublic, and one of my beats was to summarize Microsoft's Patch Tuesday each month. It was a whirlwind of an assignment... every Patch Tuesday I'd be refreshing that page like mad, and as soon as those patches came up, I'd be typing, and in an hour or two I'd get that summary to an editor and he would get that posted fast too. So I've got a few years (2? 3? I don't remember) of really looking very closely at what the root causes of Windows security and stability issues are. And the majority of them, easily well over 50%, going from my memory, are things that just don't happen in other languages (including Rust). When you see every month a big portion of the security vulnerabilities and bugs coming from buffer overruns and string manipulation errors, you quick start to ask if using a language like C/C++ is really the right play for deep OS-level work.

So for me, I definitely applaud the move from Microsoft, though I don't love the potential risk of rewrites of core OS pieces.

J.Ja