Keep using that software? I mean, as an example, I don't really think anyone is rushing to re-implement sel4 in Rust because of security, or to re-implement sqlite, which has an obscene level of testing that is likely ~on-par with Rust's own memory safety guarantees.
So the answer is "don't do anything".
Of course, deciding that something is safe is really hard. I used two examples where the work is or borders on formal verification.
> How you write code, how you design code, what environment you are in, what your domain is, what the complexity of your problem is. None of that matters.
This just isn't true, and it's kind of a confusing argument. First off, Rust is designed with C-interop in mind exactly so that you can partially replace some components in pieces. That's how Firefox has adopted Rust - in places where you can't afford to thinking "well maybe it's secure already".
> How much program wisdom, when it comes to how to design a memory safe program, is being chucked out the window to pursue a “security by language design” approach?
Basically none, speaking as someone who has some security knowledge.
> Having a “secure by design” language SPECIFICALLY to the detriment of everything else is not going to solve your security problems.
Total straw man here, in no way is Rust to the detriment of other security processes, in no way does it obscure our ability to leverage other techniques. Ironically, it's quite the opposite - Rust has been able to leverage dynamic analysis like clang sanitizers for ages, it's pushed fuzzing from "a thing security people do sometimes" to "a library that devs actually use", and even has tools for formal analysis of code (miri). Rust has been eager to adopt new mitigation techniques like safestack or CFG. Rust is far more than language safety.
Skipping over the analogy bit because analogies are a waste of time.
> We need diversity in strategy.
We have it. Rust already does this.
> We need to actually understand what security means and how existing programs that ARE secure, are written that way.
No one disagrees with this.
> Because we could end up in a less secure future, where nobody understands why, with red tape that prevents you from finding out why.
Totally unsupported claim here tbh.
Anyway, I found this all very uncompelling and it sounds like someone who isn't super familiar with computer security opining on the matter.
Beyond that, the value proposition is far more than "Safer than C/C++".