The question is rather how many are logic bugs and how many are memory safety bugs, Rust excludes the latter quite well, which according to the MS and Google Studies makes up about 70% of programming mistakes in their C++ codebases. However rewriting carries the risk of introducing new logic bugs. So There's a tradeoff here.
I am a big believer in Rust, I basically only use rg instead of grep and fd instead of find and never looked back, but they are slightly different in behavior, so not a drop-in replacement. I'm not sure if porting coreutils will be so useful in the end, since if you do all the workarounds for the rust version to behave like the C version, maybe you won't have the performance benefits or the clean codebase that you set out for in the end. I like the rg and fd approach much better. It's an almost drop-in with huge performance benefits.
But let's see if they succeed.
A lot of code will need to be replaced by memory safe code in the future, but a lot of code is not so easy to replace as something like this.
"Differences with GNU are treated as bugs." - https://github.com/uutils/coreutils#goals
That's promising. Wouldn't it be annoying though, to have to keep things bug-for-bug compatible on a green-field project? That priority may be the first compromise, and divergence is inevitable.
(If few report edge cases and there's no fuzzing.)
[1] https://github.com/coreutils/coreutils?tab=GPL-3.0-1-ov-file
…
> Last week, the issue of the package uutils coreutils 0.0.30 successfully passed 507 tests (in the last issue of 506, in a year old – 476) from the standard GNU Coreutils test set.
If I’m reading this right then there are on average only one to five tests per utility (like cat, dd, …) which is a shockingly low number. Particularly when you consider how many options a single command alone might accept. And of course, this alone would not even remotely cover a critical part of all the circumstances that might vary.
JonathonW•2h ago
[1] https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...