Since then, I’ve discovered (thanks to Hacker News) Decoded: GNU coreutils¹, a “resource for novice programmers exploring the design of command-line utilities” but unfortunately, I no longer have the capacity or free time to spend on coding.
¹ https://www.maizure.org/projects/decoded-gnu-coreutils/index...
These OSs distribute their own coreutils.
> yes(1) turns out to be really slow without that weirdness[0]
I'm not sure there is a workflow where yes writing slower than 10.2GB/s is the bottleneck. Being able to go so fast is a nifty engineering feat, but hardly a necessity IMHO.
No reason except the complexity of maintaining huge amounts of code to support dead processors and operating systems, or ones that are so rare that they might as well be dead.
brew install coreutils
etc., which I suspect is sort of what Spivak was referring to, and not that MacOS ships with them.I think the GP was getting at the fact that Rust/rustc handles many of these edge cases at the language/compiler/standard-library level, instead of at the application level. Which would mean, at least in theory, the new code would actually not have to be as ugly as the original in many cases.
[0] https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...
[1] https://github.com/coreutils/coreutils/blob/master/src/yes.c
[2] https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c
On my system it manages 20GB/s vs 6 GB/s (piping through pv into /dev/null).