This use case is unchanged.

If you specify -target x86_64-windows-gnu -lc then some libc functions are provided by Zig, some are provided by vendored mingw-w64 C files, and you don't need mingw-w64 installed separately; Zig provides everything.

You can still pass --libc libc.txt to link against an externally provided libc, such as a mingw-w64 installation you have lying around.

Both situations unchanged.

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.

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.

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.

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.

As someone who has been primarily writing Rust for the past 8+ years, I am actually unaware of any political drama surrounding Rust. It's just a programming language.

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."

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.