If I were trying a program and saw that it disrespected me by ignoring a clear preference in my environment not to use colors, I wouldn't use that program again.
The project in question, however, does seem to link libc in the build script for no reason, as well as create a static library for no reason (it doesn't export any functions). As Loris pointed out to me today, this is likely caused by the `zig init` template highlighting static linking rather than modules, which is unfortunate since modules are the preferred way for Zig code to import other Zig code. We'll be adjusting that accordingly.
seems like i created a bit of a fuss there, my bad
Well, that makes me think a lot less of Zig. Bypassing libc makes programs less cooperative members of the broader ecosystem. There's value in libc being able to act as a userspace intermediary between programs and the kernel. (That's why Windows doesn't provide a way to make direct system calls: you're going to go through kernel32/user32/etc. -> ntdll.dll and _then_ the kernel.)
Go bypassing libc causes all sorts of annoying havoc, e.g. fakeroot stuff not working. This is not behavior to be encouraged.
And for what benefit? Being able to say you're libc-free, as if that were a feature not a bug? You don't even have split stacks. Is it just that libc has "c" in the name and you want to make sure nobody thinks you're C? libc being called lib-c is an historical artifact. It's not even about C itself. It's more like Windows ntdll.
Bypassing libc is fundamentally selfish behavior. It breaks a longstanding ecosystem coordination mechanism for zero actual benefit.
But hey, I can still use "zig cc" as a convenient cross-compiler when I'm writing in a better-behaved language -- so thanks, I guess.
