My reply was about Win32 and typical C++ development. Obviously other projects may be best written in C# or other languages and frameworks.
Anyway, Microsoft is the one providing the Rust crate(s) I linked, and according to the releases it seems they are using them internally too. I do not see what is "nonsensical" about using them, and I have used them in the past just fine, just like I used Win32 from C++ in the past.
Yeah, Win32 (Windows API) will be around for a long time one way or the other, and there is a ton of tooling and docs around it. Even for non-Windows usage it is to be considered in certain situations.
> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.
Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project. There are still some reasons to do so, of course, but Win32 isn't one of them -- one can use it from a memory safe language just fine, e.g. https://github.com/microsoft/windows-rs
> which indicates the undefined behavior actually helps rather than hurts when used with good tooling
No, one doesn't need undefined behavior for that at all (which does hurt).
What actually helps is diagnosing the issue, just like one can diagnose the unsigned case just fine (which is not UB).
Instead, for this sort of thing, C could have "Erroneous Behavior", like Rust has (C++ also added it, recently).
Of course, existing ambiguous C code will remain to be tricky. What matters, after all, is having ways to express what we are expecting in the source code, so that a reader (whether tooling, humans or LLMs) can rely on that.
Rust's 2024H2 and 2025H1 flagship goals are about getting Rust for Linux into stable Rust, implementing features we need and so on. We really appreciate being a flagship goal of theirs! We collaborate regularly, and some members are part of both projects, and so on and so forth.
But that does not mean one is driven by the other, just like GCC and Clang do not drive the Linux kernel because they introduced features to build it. They support us, which is different.
> Also, didn’t the author of this updated doc (Miguel Ojeda[1]) resign from R4L? I’m not sure what his role is here.
I wrote the document, but I never resigned since I started the project -- you are probably referring to Wedson. I have seen articles that confused both of us in the past, so that is not a surprise, though I wouldn't mind to have Wedson's mind around from time to time :)
The FOSDEM 2025 keynote has some details about the history of the project. There is an LWN article about it: https://lwn.net/Articles/1007921/
But that would not make me pick C++ over Rust. Other requirements may.