logoalt Hacker News

dleslie • today at 3:17 PM • 4 replies • view on HN

If errors like this are acceptable because of the version number of an otherwise decade old project, then that's ample evidence of why Zig is not ready and should not be used for any software that needs surety.


Replies

Joker_vD • today at 3:27 PM

You know that GNU libc to this day essentially calls strlen() on every call to sscanf(), which is pretty much the same issue? And that this behaviour, present in many other implementations of standard C library (including Microsoft's), was responsible for e.g. slow JSON parsing in some very popular online games [0]? Does that mean glibc is still not production-ready?

[0] https://news.ycombinator.com/item?id=26296339

➕ show 1 reply
stateoff • today at 3:25 PM

https://blog.jetbrains.com/blog/2026/06/05/why-zig-isn-t-1-0...

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 :)

nvme0n1p1 • today at 3:23 PM

When you're setting expectations about a project, it's never a bad idea to listen to the creators themselves.

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.

Zak • today at 4:57 PM

A version number starting with 0 is not just evidence, but a direct statement by the maintainer that software is unstable/pre-release no matter how long it has been in development.