The very same day I sat at home writing this devlog like a coward, less than five miles away, armed forces who are in my city against the will of our elected officials shot tear gas, unprovoked, at peaceful protestors, including my wife.
This isn't some hypothetical political agenda I'm using my platform to push. There's a nonzero chance I go out there next weekend to peacefully protest, and get shot like Alex Pretti.
Needless to say, if I get shot by ICE, it's not good for the Zig project. And they've brought the battle to my doorstep, almost literally.
My 85 year old mom lives in Portland and she attends rallies frequently. If you know of any way to support you or other local people doing this work, I'm very interested. My email is on my profile page.
I have a friend who is in Minneapolis. He's involved in caravans which are tracking ICE. He wasn't the driver in the last one. But, the ICE vehicle they tailed suddenly started going in a very direct path, instead of randomly driving. The driver figured it out first. They drove to the driver's house and then stood outside of their car for ten minutes staring at his house. Cars in Minnesota have their license plates on both the front and the back.
Is there any justification for that kind of intimidation? Did any of the Trump supporters vote for that? I hear about paid agitators on the left but not that kind of compensated actors. Is his name in a database now once they did the lookup?
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?
"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.
> 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?
Seems like it ought to be able to do inlining and dead code stripping which, I think, wouldn't be viable at link time against optimized static libraries.
Right, but I think that's what the question of "Why is the linker too late?" is getting at. With zig libc, the compiler can do it, so you don't need fat objects and all that.
---
expanding: so, this means that you can do cross-boundary optimizations without LTO and with pre-built artifacts. I think.
I considered Zig because I was tired of all the political correctness surrounding Rust. If Zig is also involved in all sorts of political issues, then it's no different from Rust; it's just a case of the pot calling the kettle black.
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.
There's solid reason for the translation here; the Zig core team is aiming to eliminate duplicated code and C functions, and avoid the need to track libc from multiple sources. In the future, LLMs could serve as part of this, but they are currently quite terrible at Zig (as far as I understand it, it's not a lack of Zig code samples, it's an imbalance of OLD Zig to NEW Zig, as Zig changes quite frequently).
You would need to consider if it is even worth it translating your C code. If the paradigm is identical and the entire purpose would be "haha it is now one language," surely you could just compile and link the C code with libzigc... In my opinion, it's not worth translating code if the benefit of "hey look one language" requires the cost of "let's pray the LLM didn't hallucinate or make a mistake while translating the code."
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.
Have you ever used an LLM with Zig? It will generate syntactically invalid code. Zig breaks so often and LLMs have such an eternally old knowledge cutoff that they only know old ass broken versions.
The same goes for TLA+ and all the other obscure things people think would be great to use with LLMs, and they would, if there was as much training data as there was for JavaScript and Python.
To be fair, this was true of early public LLMs with rust code too. As more public zig repositories (and blogs / docs / videos) come online, they will improve. I agree it's a mess currently.
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.
The very same day I sat at home writing this devlog like a coward, less than five miles away, armed forces who are in my city against the will of our elected officials shot tear gas, unprovoked, at peaceful protestors, including my wife.
https://www.kptv.com/2026/01/31/live-labor-unions-rally-marc...
This isn't some hypothetical political agenda I'm using my platform to push. There's a nonzero chance I go out there next weekend to peacefully protest, and get shot like Alex Pretti.
Needless to say, if I get shot by ICE, it's not good for the Zig project. And they've brought the battle to my doorstep, almost literally.
Abolish ICE.
My 85 year old mom lives in Portland and she attends rallies frequently. If you know of any way to support you or other local people doing this work, I'm very interested. My email is on my profile page.
I have a friend who is in Minneapolis. He's involved in caravans which are tracking ICE. He wasn't the driver in the last one. But, the ICE vehicle they tailed suddenly started going in a very direct path, instead of randomly driving. The driver figured it out first. They drove to the driver's house and then stood outside of their car for ten minutes staring at his house. Cars in Minnesota have their license plates on both the front and the back.
Is there any justification for that kind of intimidation? Did any of the Trump supporters vote for that? I hear about paid agitators on the left but not that kind of compensated actors. Is his name in a database now once they did the lookup?
> against the will of our elected officials
Did you mean your local officials?
I too am sick of internal compiler errors
I too am sick of intrusion countermeasures electronics. Think of all the poor netrunners out there.
I too am sick of internal combustion engines, a product of the last century.
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?
Yes but we already have to do that for our own standard library. For shared codepaths (e.g. math) it's strictly fewer potential bugs.
"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.
> 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?
Seems like it ought to be able to do inlining and dead code stripping which, I think, wouldn't be viable at link time against optimized static libraries.
It is viable against the IR that static libraries contain when LTO is enabled.
LTO essentially means “load the entire compiler backend into the linker and do half of the compilation work at link time”.
It’s a great big hack, but it does work.
Right, but I think that's what the question of "Why is the linker too late?" is getting at. With zig libc, the compiler can do it, so you don't need fat objects and all that.
---
expanding: so, this means that you can do cross-boundary optimizations without LTO and with pre-built artifacts. I think.
I considered Zig because I was tired of all the political correctness surrounding Rust. If Zig is also involved in all sorts of political issues, then it's no different from Rust; it's just a case of the pot calling the kettle black.
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.
There's solid reason for the translation here; the Zig core team is aiming to eliminate duplicated code and C functions, and avoid the need to track libc from multiple sources. In the future, LLMs could serve as part of this, but they are currently quite terrible at Zig (as far as I understand it, it's not a lack of Zig code samples, it's an imbalance of OLD Zig to NEW Zig, as Zig changes quite frequently).
You would need to consider if it is even worth it translating your C code. If the paradigm is identical and the entire purpose would be "haha it is now one language," surely you could just compile and link the C code with libzigc... In my opinion, it's not worth translating code if the benefit of "hey look one language" requires the cost of "let's pray the LLM didn't hallucinate or make a mistake while translating the code."
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.
hallucinations in a libc implementation would be especially bad
Have you ever used an LLM with Zig? It will generate syntactically invalid code. Zig breaks so often and LLMs have such an eternally old knowledge cutoff that they only know old ass broken versions.
The same goes for TLA+ and all the other obscure things people think would be great to use with LLMs, and they would, if there was as much training data as there was for JavaScript and Python.
To be fair, this was true of early public LLMs with rust code too. As more public zig repositories (and blogs / docs / videos) come online, they will improve. I agree it's a mess currently.
You must have not tried this with an LLM agent in the past few months.
i tested sonnet 4.5 just last week on a zig codebase and it has to be instructed the std.ArrayList syntax every time.