With C you can take proven algorithms from CLRS and translate them directly without boilerplate.
The same algorithms already become ugly/obfuscated in idiomatic C++.
Looking at the macro in the LWN article, the approach of Rust of using wrappers and boxes and complex macros to emulate features appears to go into the same direction as C++.
Still in 2024, gdb is far less useful for C++ than for C. C++ error messages are far less useful.
All of that matters for reliable software, crashes (which can occur anyway with unsafe) are just a tiny part of the equation.
It may be that a typical well-written C program for an algorithm is more concise and/or elegant, but how exactly do we scale developers writing C programs well? For that matter, forget algorithms, what about C string handling? Yes, Rust has a gazillion string types (offtopic: I don't really understand those complaints, as usually you only need a few), but whether in the standard library or a third-party library, I don't get the sense that I need to be very diligent. And I don't think people should need high diligence for using strings.
As an OS nerd, this is what I like to use as an example: yes, the seL4 verified microkernel is impressive and if it was written in a language other than C, it wouldn't have both the practicality and the assurance. It was specified in Haskell but ultimately the C is what is deployed, so C it is. A Rust version might not be verifiable even in the next ten years. But the people who can't use seL4 and need an 80% "reasonably secure" or whatever OS have a strong case to use Rust over C. The formal verification for the C code of seL4 is partly a crutch for C's lack of safety and correctness by default.
With C, you are not 100% sure that ur code will work. You have to verify and extensively test it.
With C++ you have some very vague guarantees about ur code but you can easily transition from C and even have some interesting type safety like mp-units.
with Rust, you have some good guarantees that ur code wont have UAF, will be threadsafe, etc etc and you can probably invent some interesting typesafety like mp-units.
In all 3, you gotta verify [frama-C, astree,bedrock, the many projects working on rust, esp the coq one] and extensively test it.
But by default, all 3 provide a different level of gurantees
The same algorithms already become ugly/obfuscated in idiomatic C++.
Looking at the macro in the LWN article, the approach of Rust of using wrappers and boxes and complex macros to emulate features appears to go into the same direction as C++.
Still in 2024, gdb is far less useful for C++ than for C. C++ error messages are far less useful.
All of that matters for reliable software, crashes (which can occur anyway with unsafe) are just a tiny part of the equation.