Quite to the contrary to what you write, many people pushing for Rust explicitly recommend to be very restrictive about touching existing, battle tested code and only rewrite it if you're substantially refactoring it anyways, or if it is a critical exposed piece of functionality - such as media codecs for example, which have a long history of being broken. The winning strategy that for example the google android team pursues is to not rewrite existing code, but write all new code in Rust, because real-world data shows that vulnerabilities in existing code follow a decay curve - most issues are detected in the early life of the code. That's the strategy that Firefox uses, too. (Though I'm curious about how LLMs change that equation because detecting errors in rarely used code path' seems to be what they're doing well)
And indeed, this is very much what Rust was designed to do with the ability to interface with existing C/C++ code in both directions. So this is the strategy that the designers of the language had in mind from the early days. It's a deliberate choice to offer this, and not an emergent property that was later discovered.
> many people pushing for Rust
You have couched this correctly, because we all know there are people out there who do go around yelling "Rewrite it in X" without thought (where X is the flavour of the month)
I also wanted to say - your description of the /right/ way to align a project with tech X is a restatement of Martin Fowler's "Strangler pattern"
Can you edit your post - "equation because deteting errors" is ambiguous - deleting, or detecting - I cannot work out which you mean
> equation because deteting errors
should be
> equation because detecting errors
Thanks for the catch, did the edit.