Rewrites in general are usually a terrible idea, unless the original is horribly broken (and beyond fixable).
If you wrote your app in C++, instead of rewriting it for the next decade in Rust just to get to the same point, slap some AddressSanitizer, ThreadSanitizer, -fanalyzer, cppcheck, etc. on it. You will get 98% of the way there.
Instead of spending 8+ years(!) rewriting[1] the GNU coreutils in Rust, you could spend half that time to ensure full coverage (branch-coverage, condition-coverage) in the existing ones. I will actually have a breakdown if someone tries to rewrite SQLite in Rust[2].
1: https://github.com/uutils/coreutils 2: https://sqlite.org/testing.html
"Kills 98% of viruses" is good enough for hand soap, but it's not good enough for the vital infrastructure that basically all software relies on.
Now that we have self-driving cars, rockets, medical devices, etc relying on this infrastructure, I don't think a push towards total provable memory safety is a bad idea.
(Though notice I said "total provable memory safety". If there's a way to get there without a rewrite in Rust, that's preferable a million times over.)
And something like SQLite shows that you can get 100% coverage (as in, every single statement is hit in the tests). That's 100%.
sqlite is bad example, for example features like the FTS tokenizer code (https://research.checkpoint.com/2019/select-code_execution-f...), which were probably paid by commercial requests or sponsors.
That is not to say sqlite does not have 100% coverage, it of course does, but you are building on top of infrastructure which is really really hard to be kept safe.
Rust somehow makes it harder to make certain kinds of bugs, which comes at its own cost.
PS: I don't like or dislike rust, just I have seen the sqlite example being brought a lot, and a lot of people didn't expect sqlite file to be an attack vector :) so nobody is even looking there.
Then again, I don't think that the sanitizers, while great, prevent anywhere close to 98% of the issues either.
I'd be very wary to try to contribute anything to old GNU project like that, since despite having right licensing ideas, they attract the biggest assholes. This might be another reason why different people are doing rewrites.
And sometimes, it turns out extremely well, like ripgrep.
Are they assholes? Maybe millions of people using their tools and external expectation forms character?
I think such quick judgements are often very special.
I would say, it depends on the ROI.
For example, my current millstone, is a 20 year c++ program written towards the c++98 spec. The physical hardware is held together with spit and best wishes with the current management stating that we need to move to a Linux based, Intel platform as that's what 99% of the org is on.
And, we're not licensing Vendor A or B's product, therefore "patch it till the major rewrite is completed".
In the intervening 20 years, C++11, 17 or even 20 is very different from 98.
Will I rewrite the whole thing, nope, as there's another project to rewrite the client/server portion (again 20 years ago) and at that time, I will eliminate that c++ piece.
Coreutils and the standards they are based on are far behind what's possible with CLI UX, and I feel like that amounts for some of the effort. That's certainly why I myself cheer this movement on. I want to see a nicer Unix.