There are obviously different people doing this stuff than original GNU coreutils people.

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.

The contributions of those assholes has been a massive factor in the success of the Linux/GNU ecosystem. I'd strongly urge potential contributors to speak with the real people behind the project rather than blindly trust the advice of somebody on the internet whose affiliations and interests can never be reliably ascertained.

> they attract the biggest assholes

Are they assholes? Maybe millions of people using their tools and external expectation forms character?

I think such quick judgements are often very special.

> You will get 98% of the way there.

"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.)

I hear you. But, to take my example of the GNU coreutils rewrite, even after more than 8 years it only passes 32% of the test cases that the C GNU Coreutils pass. That's not 98%, that's not even 90%. It's hard to rewrite good software.

And something like SQLite shows that you can get 100% coverage (as in, every single statement is hit in the tests). That's 100%.

The coreutils rewrite is essentially a hobby project, which nobody is going to switch to until it can boast 100% compatibility. So of course it's slow coming, it's not a fair comparison. There's also the issue that writing a drop-in replacement is harder and less attractive than making something better (see ripgrep and other coreutils alternatives).

offtopic:

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.

Rust doesn't kill 100% of the bugs either (remember, memory/thread safety are only a small subset of all the possible bugs).

Then again, I don't think that the sanitizers, while great, prevent anywhere close to 98% of the issues either.

> Rewrites in general are usually a terrible idea, unless the original is horribly broken (and beyond fixable).

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.