While memory safety is important, I do not believe it is now suddenly so important that it needs now needs to be solved quickly at all cost. There are far more pressing issues. I also do not think at all that C/C++ are dead end. In fact, I think it would be far more cost effective to continue to improve safety of C and C++ code via gradual improvement than adding another language into the mix. The reason is that complexity and the burden of long-term maintenance is the main issue we have in free software, and Rust makes this worse rather than better. Case in point, the fact that I have limited security updates because of some Rust video codec in the dependency chain hurts my security far far more than the fact that it might prevent some memory safety issue: https://www.debian.org/releases/trixie/release-notes/issues.... I think this is what people are missing. They over-exaggerate the important of memory safety over rather mundane issues which are actually far more important. I have never known anybody who was directly affected by a security issues caused by memory safety, I know plenty who were affected because their software was not up-to-date.

English link: https://www.debian.org/releases/trixie/release-notes/issues....

> The Debian infrastructure currently has problems with rebuilding packages of types that systematically use static linking. With the growth of the Go and Rust ecosystems it means that these packages will be covered by limited security support until the infrastructure is improved to deal with them maintainably.

What are realistic options for "gradual improvement" of memory safety in C and C++?

My first thought is that it is kind of like talking about gradually improving manual memory allocation in Java. C and C++ are fundamentally memory unsafe; it's part of their design, to offer complete control over memory in a straightforward, direct way.