Eh. People have written replacements for glibc because they didn't like something or another about it, and that seems to me to be way more fraught with risk than coreutils.

Folks also run into compatibility issues with musl as well. The biggest I recall was an issue with DNS breaking because musl didn’t implement some piece.

TBF DNS handling of glibc is crazy.

Fair enough. My gut sense is that C functions are simpler than shell commands, with a handful of parameters rather than a dozen or more flags, and this bug supports that -- they forgot to implement a flag in "date." But I haven't tried to do either, so I could be wrong.

FWIW, GNU coreutils is itself a rewrite of stuff that existed before, and which has been rewritten multiple other times.

> The thought of rewriting anything as intricate, foundational, and battle-tested as GNU coreutils from scratch scares me. Maybe I'd try it with a mature automatic C-to-Rust translator, but I would still expect years of incompatibilities and reintroduced bugs.

It is extremely bad that it's not a relatively straightforward process for any random programmer to rewrite coreutils from scratch as a several week project. That means that the correct behavior of coreutils is not specified well enough and and it's not easy enough to understand it by reading the source code.

Not to be too harsh, but if that’s your (fundamentalist) attitude to software, remind me to argue strenuously to never have you hired where I work. Fact is you can’t rewrite everything all the time, especially the bits that power the core of a business, and has for a decade or more. See banking and pension systems, for instance.

I think you're completely missing the point. The problem being solved is not that coreutils is bad and thus they should be rewritten, the problem is that coreutils is not specified well enough to make new implementations straight-forward. Thus a new implementation written from scratch is tremendously valuable for discovering bugs and poorly documented / unspecified behavior.

For a business it's often fine to stop at a local maximum, they can keep using old versions of coreutils however long they want, and they can still make lots of money there! However we are not talking about a business but a fundamental open source building block that will be around for a very long time. In this setting continuous long term improvement is much more valuable than short term stability. Obviously you don't want to knowingly break stability either, and in this regard I do think Ubuntu's timeline for actually replacing the default coreutils implementation is too ambitious, but that's beside the point—the rewrite itself is valuable regardless of what Ubuntu is doing!