by OsamaJaber
0 subcomment
- 250 C files were deleted. 2032 to go. Watching Zig slowly eat libc from the inside is one of the more satisfying long term projects to follow
- "Abolish ICE" at the bottom. Obviously a Bad Bunny fan, as I am.
- > It’s kind of like enabling LTO (Link-Time Optimization) across the libc boundary, except it’s done properly in the frontend instead of too late, in the linker
Why is the linker too late? Is Zig able to do optimizations in the frontend that, e.g., a linker working with LLVM IR is not?
by jzelinskie
0 subcomment
- Cool idea, for sure, but I can't help but wonder: for the code that's been ported, is there a concern that you'd have to perpetually watch out for CVEs in glibc/musl and determine if they also apply to the Zig implementations?
by nesarkvechnep
0 subcomment
- "Furthermore, when this work is combined with the recent std.Io changes, there is potential for users to seamlessly control how libc performs I/O - for example forcing all calls to read and write to participate in an io_uring event loop"
This is exciting! I particularly care more about kqueue but I guess the quote applies to it too.
by self_awareness
2 subcomments
- Why does the author think that "abolish ice" is more important than "abolish iranian authoritarian regime which is killing its own people"? seems kinda nationalistic
- Super cool project.
I expect a lot of C code may be quite mechanically translated to Zig (by help of LLMs). Unlike C->Rust or C->C++, where there's more of a paradigm shift.
- This strikes me as a very agent-friendly problem. Given a harness that enforces sufficiently-rigorous tests, I'm sure you could spin up an agent loop that methodically churns through these functions one by one, finishing in a few days.