The advantages of memory safe languages have been discussed to death in programming circles for many decades.
This is absolutely nothing new, and it should surprise absolutely no one that both industry and government are behind the curve, as usual.
5 years ago, there was not broad consensus by technical leaders that C/C++ was even a problem. You just needed the best programmers, throw in some *SAN to rinse all the bugs away and poof!, fast enterprise grade code!
Who delivers a message is often times more important than the message itself. The entire message is (person, says, x), I said we should stop using C/C++ 20+ years ago, doesn't make me CTO of Azure or the NSA.
Those of us using modern C++ do not ship memory usage faults, and have not done for years. So, experience with C and pre-modern C++ does not generalize.
If not, then "modern C++" is still not memory-safe.
The same applies to, e.g., Rust: any Rust program may use unsafe blocks. That Rust programs may contain unsafe blocks does not make Rust implicitly unsafe. Even using unsafe blocks does not, by itself, make the program unsafe.
> Even using unsafe blocks does not, by itself, make the program unsafe.
This is false. "Unsafe" means that there is the potential to cause memory safety bugs. Unsafe blocks and C++ cause this, by definition. "Unsafe" does not mean that a memory safety bug actually exists.
Moreover, I didn't mention anything about Rust in my comment.
If you are coding C or pre-modern C++, then you are not coding modern C++, regardless of the compiler you happen to build with.
Your claim that modern C++ doesn't ship memory safety issues is a fallacy not worth my time for a rebuttal.
Instead, mid-90s C++, with all the leaks, is valid C++, 20 or otherwise.
No true C++20 program is memory unsafe... unless you use a normal pointer, which is always available and will bork you just as hard as in C.
Your argument applies equally well to Rust: any Rust program may include unsafe blocks. That any program may contain unsafe blocks does not make Rust implicitly unsafe. That a Rust program does (transitively) contain unsafe blocks does not make it an unsafe program. All substantial Rust programs at least transitively contain unsafe blocks.
Thus, your argument is invalid.
In some ways Rust is (or will be) particularly well suited to these environments. They're hard to debug so the compile-time constraints are particularly helpful. Features like async/await are perfect for modelling interactions with hardware peripherals, etc. But there are still a lot of rough edges. Most embedded development with Rust is still relying on unstable nightly features (particularly more advanced const evaluation). Although the recent stabilisation of GATs helps a lot.
Basically every single piece of software that matters is a C library or is exposed through a C API, because that's what other languages hook into, including Rust.
Heck, right this second I'm working on a piece of software that needs to talk to Java and Python simultaneously, so C++ with extern C it is.
Using memory safe languages when you can is good advice, but it's kind of complicated to get to a point where everything is guaranteed safe.
I don't disagree, and for that reason the transition will be slow, but I still think it will happen. The benefits are too great to ignore, or they eventually will be. Nobody's going to want to use insecure foundational libraries once secure ones are available. And they're already being written.
> Heck, right this second I'm working on a piece of software that needs to talk to Java and Python simultaneously, so C++ with extern C it is.
For what it's worth, Rust is entirely viable (and arguably easier than C++) in this space right now. It's also using extern C under the hood, but there are libraries like "pyo3" and "jni" which will deal with the unsafety for you and provide you with higher-level bindings. In practice you don't lost much safety using this approach.
Or even GraalVM which is polyglot between the two languages and can even optimize across language boundaries.
The right tools mater. The memory safe stuff above was autosar, so not something often discussed here. Rust is getting interest from the above team but after the above burn they are slow to try new things.
Building everything performance-critical with immature languages is not a viable alternative. But building with modern C++ is one.