crazy blogpost by andrew kelley just dropped

Rust Coreutil replacement is “so subpar I don't even have words”, according to… developer of Rust Coreutil replacement. And this is shipping in Ubuntu? Woof. It appears that the developers of UUtils (the Rust Re-writes of the GNU Coreutils) are beginning to realize that replacing code dealing with “absurd” numbers of “edge cases”, developed and tested over decades… is not as easy as they thought it might be. Even with the magical, unicorn fart powered Rust programming language. One (of many) such cases: The Rust replacement for the GNU Timeout command is utterly broken. And the Rust devs appear to be at a loss for how code could ever possibly cover so many “edge cases”. From the Rust devs: “Timeout requires a rewrite I've attempted 10 times since last October or November.” “GNU timeout is just absurdly full of undocumented edge cases … and we don't even cover half.” “Our actual implementation is so subpar I don't even have words.” “I'm just frustrated with uu timeout to the point of absolute exhaustion.” github.com/uutils/coreutils/…

For starters, kernel32 performs various path transformations as it passes filenames from user programs to ntdll and the kernel. A program using ntdll directly, especially if it isn't careful to emulate win32 semantics (which I doubt Zig takes care to do) will behave unlike other Windows programs, e.g. when figuring out what actual disk file a string path names. Is the direct ntdll way better? Yes, it is, viewed in isolation. I quite like NT. Win32 is aesthetically suboptimal. But a direct ntdll program is *different*, and it's the difference that will cause subtle headaches for all sorts of users and integrators. Maturity in software is understanding that you sometimes have a duty to put up with an ugly interface for the greater good of a consistent interface. Our decisions ramify in time, and it's better for everyone to be consistently warty than for every program to be selfishly special. Plus, it's just rude to do this stuff, because 1) Zig is making a lot of work for the Windows team by making them support a second API surface they never signed up to support, and 2) Zig is constraining the evolution of the Windows platform by forcing Microsoft to freeze internal APIs in amber when they should be able to improve them. The Zig people do the same thing on Linux, by the way. They bypass libc and go straight to the kernel, breaking LD_PRELOAD shims Linux users rely on. And for what? Nothing! It's infuriating. The interface layers Zig bypasses on Linux and Windows are thin and add practically no overhead. Zig programs are not faster or better for having bypassed these layers that everyone else has relied on for decades. So what's the root cause of Zig-ism? Vibes about being closer to the metal? A feeling of power stemming from wielding esoteric knowledge? A kind of glee in annoying people like me, with my silly appcompat war stories and spiritually boomer worries about long term ecosystem evolution? Is it some kind of innumerate gutfeel that load bearing elements of the system are "bloat"? Do they understand how shared libraries work? A decade ago, the Zig people would be posting on forums about how they optimized (but in actuality pessimizd) their Gentoo systems by compiling with -O99 -funroll-all-loops -DMOAR_SPEED, saying a numerically "for sure felt smoother". A decade before that, the Zig people would have been attaching enormous spoilers and illegally loud mufflers to their Honda Civics. Probably painting them red too, because as everyone knows, the red ones go faster. There's just a sort of timeless personality type prone to this sort of thing. And that's fine. People are allowed to be ridiculous. Except this generation, this personality type comes armed with a trendy programming language. The Gentoo system gets reimaged with Debian stable. The Honda Civic eventually gets compressed into a cube in some landfill. We cannot serve similar justice unto Zig programs doing flagrantly stupid things forever.