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.
"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.
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.
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?
> 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?
This is very exciting for zig projects linking C libraries. Though I'm curious about the following case:
Let's say I'm building a C program targeting Windows with MinGW & only using Zig as a cross compiler. Is there a way to still statically link MinGW's libc implementation or does this mean that's going away and I can only statically link ziglibc even if it looks like MinGW from the outside?
That just reminds me anyone know whether rust has something similar? Not wanting to start any Rust v. Zig debate. I am just wanting to be even more independant when it comes to some of my Rust projects.
Does anyone know if there is a timeline on when Zig might achieve 1.0? I've been interested in the language for a while, but I'm a bit concerned about writing anything important in it when it seems to be evolving so much at the moment
Nobody knows, but for what it's worth, existing large projects that are used in production environments have been fairly good at keeping up with Zig releases. See: Bun, Ghostty, and Tigerbeetle for good examples of this. Because the semantics of Zig are relatively simple, porting to the latest version is usually as simple as bumping your compiler version, trying to build, making a fairly mindless, mechanical change, and repeating until it builds.
The biggest thing holding me back from using Zig for important projects is the willingness of my peers to adopt it, but I'm just building projects that I can build myself until they are convinced :)
20 comments
[ 2.7 ms ] story [ 35.5 ms ] threadI 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 is exciting! I particularly care more about kqueue but I guess the quote applies to it too.
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?
Let's say I'm building a C program targeting Windows with MinGW & only using Zig as a cross compiler. Is there a way to still statically link MinGW's libc implementation or does this mean that's going away and I can only statically link ziglibc even if it looks like MinGW from the outside?
Because doesn’t OpenBSD block direct syscalls & force everything to go through libc.
https://news.ycombinator.com/item?id=38039689
I think we either need to make operating systems not in C, or just accept that at some level we rely on C.
The biggest thing holding me back from using Zig for important projects is the willingness of my peers to adopt it, but I'm just building projects that I can build myself until they are convinced :)
You might find this interesting: https://www.youtube.com/watch?v=x3hOiOcbgeA