https://twitter.com/ryan_levick/status/1225837057186000896?s...
and are doing other experiences as well,
https://www.infoq.com/news/2019/11/microsoft-exploring-rust-...
https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win...
Kenny Kerr, the original author of C++/Winrt, which replaced C++/CX, has now turned into Rust.
https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/
They are also motivated to actually make C safer, with Checked C project, something that ISO C doesn't seem to care that much.
https://www.microsoft.com/en-us/research/project/checked-c/
As per MSRC advisory, new code should be a mix of .NET, Rust or Core Guidelines compliant C++, depending on the use case.
Not really, it means that if there is a memory safety bug it must be either in an unsafe block or foreign C code (which also must be called in an unsafe block). While technically any C code could completely invalidate Rust's memory model, in practice that is almost always a C bug which you can debug more easily if much less of your codebase is in C (or equivalently, unsafe Rust).
> Having a codebase which is half C and half Rust sounds worse to read and reason about than all either.
I think that really depends how it's structured. You would probably want to avoid something like Rust calling C calling Rust calling C (calling Rust calling ... etc), but if the codebase is already separated into modules or even separate libraries you could rewrite a library or module while maintaining the same C API (and that Rust or C module can be read independently from the rest of the codebase).
Additionally, most Windows code is C++ with Windows specific language extensions (COM, Structured Exception Handling, and others).
I think most C++ code should be rewritten in Rust library by library, but most software is not properly constructed as a series of libraries. And asking a business to rewrite working code in a brand new language instead of fixing a buffer overflow is a difficult ask.