The whole zig project is like six people in a trenchcoat. You can't expect them to prioritize your one thing.
But I mean, the six people in a trenchcoat comment is basically precisely what should give people pause. In my project I simply eliminated zig from the stack entirely because even if I worked around the problems, what comes next? What's the next showstopper that gets waved away as oh well six people in a trenchcoat...
Eh, whatever.
https://ziglang.org/documentation/master/std/#std.mem.findSe... didn't exist then, now it does.
And if i may quote from https://ziglang.org/download/0.17.0/release-notes.html:
> Zig has known bugs, miscompilations, and regressions.
> Even with Zig 0.17.x, working on a non-trivial project using Zig may require participating in the development process.
> When Zig reaches 1.0.0, Tier 1 support will gain a bug policy as an additional requirement.
If you're not willing to participate in the development process, then you should wait or use something else.
Some people (not its creators) talk about Zig as if it's anywhere near production ready. It's fine to be excited about it (there's a lot to be excited about), but we gotta be realistic.
This submission is advocating Zig over C for system programming. I pointed out a pretty significant reason why maybe you should pause that decision for a bit.
Now it's "FUD", also it's a beta and you're a beta tester, and it's 0.x, and look they disclaim that you shouldn't trust it, and...
This is a bizarre thread. These very comments are precisely why it should give pause (which isn't remotely "FUD", and what an utterly asinine claim). Zig looks neat and it might get there, but this absurd apologism and goalpost moving is not convincing to adopt the language.
Again, in a submission advocating using Zig for system programming. You couldn't script it better.
llm_nerd: "I found a bug. This gives me pause about the whole zig project"
I don't see how the latter is a fair reaction given the former. They only just started working on the libc port (although it has been talked about for a while now)
Zig hides behind its pre 1.0 status to justify poor decision making while simultaneously actively trying to attract attention through marketing. That attention translates to resources and influence that are undeserved on the technical merits.
Alright then go for it, hotshot. We're waiting.
Always happy to learn.
https://codeberg.org/ziglang/zig/issues/37402
Looks like it is being worked on.
Personally I think it's not that catastrophic for zig < 1.0. Just a performance regression, and one can always link to other libc implementations, or is their own implementation enforced now?
https://ziglang.org/download/0.17.0/release-notes.html
> Zig has known bugs, miscompilations, and regressions.
> Even with Zig 0.17.x, working on a non-trivial project using Zig may require participating in the development process.
> When Zig reaches 1.0.0, Tier 1 support will gain a bug policy as an additional requirement.
I did not say it's acceptable, just not catastrophic, especially since workarounds exist.
I've used zig in similar capacity in production in the past and personally I would take the slowdown just to avoid dealing with MSVC :)
> I made the judgement call to let this slide in the review. I'm still not sure whether it was the right or wrong call.
https://lobste.rs/s/lh1j0e/shlemiel_painter_is_back_how_zig_...
https://dennisforbes.ca/blog/microblog/2026/10/the_accidenta...
While I did just dismiss it as an edge issue, it turns out that this same rather clumsy sort of mistake has happened repeatedly in Zig's pure rewrite of MUSL. And despite being an absolutely catastrophically bad problem, by my judgment, the problem is still in main at this moment, across a wide number of musl function rewrites.
Which gives me pause about the whole zig project. If you're rewriting a critical library, making such simple but consequential mistakes shouldn't happen, and if they do happen it should be a red alert type situation.