The performance boost in tools like ripgrep and tokei is insane compared to the tools they replace (grep and cloc respectively).

ripgrep is an excellent tool. But it's not a grep replacement. And should not ever be.

Please forgive me my ignorance but what's wrong with bash? I'm still using it on all servers and workstations, I constantly write scripts for it, some fairly complex. It's not an obsolete project and it looks like a mainstream shell for me. Am I wrong?

Update: yeah, I realize now that this was about the original Bourne Shell, not bash.

You have a point here. I have to agree.

"X but rewritten in Z" is a terrible marketing, though. Makes me instantly want to hate the tool and its authors. (Love rust. Hate the vibe).

Compare "I have typed a setuid() wrapper in rust" vs "I'm the author of sudo-rs".

How would you even tell people you made a better rust crate without using the word “rust?”

Rust folks are claiming excellent interoperability with C binaries. Why the need for a rewrite then?

Interoperability runs both ways, everyone currently taking a dependency on the C library can swap in the rust library in its place and see the same benefits

or Korn shell.

https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#can...

Those "core standards" that you talk about didn't spring fully formed from the earth. They came about from competition and beating out and replacing the old "core standards" that lots of people argued very strongly for should not ever be replaced. When I was starting out my career I was told by experienced people that I should not learn to rely on the GNU tool features, since they're far from ubiquitous and probably won't be installed on most systems I'll be working on.

Tokei _finishes_ before cloc can print its help text. I wrote this post in less time than it took `cloc .` to count all the files in my project, probably because it doesn't know to ignore `target/`.

cloc is a Perl script, so it has the interpreter startup time.

2) I think the MIT license was a mistake. These are often cloning GNU utilities, so referencing GNU source in its original language and then re-implementing it in Rust would be the obvious thing to do. But porting GPL-licensed code to an MIT licensed project is not allowed. Instead, the utilities must be re-implemented from scratch, which seems like a waste of effort. I would be interested in doing the work of porting GNU source to Rust, but I'm not interested in re-writing them all from scratch, so I haven't contributed to this project.

1 - GNU utilities is ancient crufty #IFDEF'd C that's been in maintenance mode for decades. You want code to handle quirks of Tru64 and Ultrix? You got it.

2 - Waving your hands around 'the community will take care of it' is magical thinking. C developers don't grow on trees. C tooling is kinda weird and doesn't resemble anything modern - good luck finding enough VOLUNTEER C developers to make your goals happen.