Heartbleed was a great demonstration of critical systems that were under appreciated.

Too few maintainers, too security researchers and too little funding.

When writing systems as complicated and as sensitive as the leading encryption suite used globally, no language choice will save you from under resourcing.

Right, but I believe nobody can claim that Human error bugs go to zero for Rust code.

Agreed. I rather dislike the idea of "safe" coding languages. Fighting with a memory leak in an elixir app, for the past week. I never viewed c or c++ as unsafe. Writing code is hard, always has been, always will be. It is never safe.

This is a bit of a misunderstanding.

Safe code is just code that cannot have Undefined Behavior. C and C++ have the concept of "soundness" just like Rust, just no way to statically guard against it.

Modern compilers like clang and GCC both have static analysis for some of this. Check out the undefined behavior sanitizer.

Sanitizers are technically dynamic analysis. They instrument built programs and analyze them as they run.

As the other person pointed out, these are two different things. Sanitizers add runtime checks (with zero consideration for performance - don’t use these in productions). Static analysis runs at compile time, and while both GCC and Clang are doing amazing jobs of it, it’s still very easy to run into trouble. The mostly catch the low-hanging fruit.

The technical reason is that Rust-the-language gives the compiler much more information to work with, and it doesn’t look like it is possible to add this information to the C or C++ languages.

There is more than undefined behavior, if I was to define using an uninitialized variable as yielding whatever data was previously in that location, it is well defined but unsafe.

That could be well defined for POD types like arrays of bytes (I think in that case they call it "freezing"), but you'd still have undefined behavior if the type in question contained pointers. Also at least in Rust it's UB to create illegal values of certain types, like a bool that's anything other than 0 or 1.

Which is all kind of to say, all of Rust's different safety rules end up being surprisingly densely interconnected. It's really hard to guarantee one of them (say "no use-after-free") without ultimately requiring all of them ("no uninitialized variables", "no mutable aliasing", etc).

A memory leak is not a memory safety issue.

No, but it can be dangerous when you run out of memory for critical systems.

yes, but that is neither here nor there. You can create a memory leak perfectly cromulently in rust too