News for hackers. Stuff that matters.
Re:Show HN: Zli – A Batteries-Included CLI Framework for Zig by quotemstr on Sunday May 25, 2025 @07:44PM (#44092388)
"[P]oisoning"? Do you have a technical objection, or do you just not like the letter "c"?
Re:Show HN: Zli – A Batteries-Included CLI Framework for Zig by throwA29B on Sunday May 25, 2025 @11:49PM (#44093815)
libc, starting with errno, continuing with fopen/printf/str* functions, locales, etc is a pile of quick hacks; set of useful abstractions at the time, no doubt! But that time is long gone, for decade(s) it is nothing but a drag.
Re:Show HN: Zli – A Batteries-Included CLI Framework for Zig by Cloudef on Monday May 26, 2025 @05:11AM (#44095486)
libc carries lots of global state and implicit ABI that complicates software stacks. While I don't like dynamic libraries in general, dynamic libraries wouldn't be such a mess as they are if libc did not exist. I dream of day we can actually do GPU rendering on linux without libc, and have actual static binaries for graphical apps that work everywhere.
Re:Show HN: Zli – A Batteries-Included CLI Framework for Zig by quotemstr on Monday May 26, 2025 @07:22AM (#44096286)
That global state is the coordination problem it's solving. Who owns the thread list? The current process wide setreuid identity? The loaded library list? Debug info registrations? Shared dynamic memory allocations? TLS slots? Someone has to, and that someone is libc. Avoiding it because it has state is to be confused about the whole concept of an OS.

Yeah, it's mixed up with the same library that provides sscanf and strcat. So what? You don't have to call them.