Yet another Hacker News

79 points torutofu 1 hour ago 19 comments

llm_nerd 1 hour ago | parent

I wrote recently about a weird issue I encountered with Zig, though to be fair it was related to using Zig to compile C code, humorously in a Rust project (which touches on all of the languages mentioned in this post).

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.

dnautics 47 minutes ago | parent

> Which gives me pause about the whole zig project

The whole zig project is like six people in a trenchcoat. You can't expect them to prioritize your one thing after 3 weeks

Did you make a PR?

llm_nerd 43 minutes ago | parent

It isn't my thing though. It's quite literally, by choice, their thing. They are the ones who decided that rewriting musl in zig was something they need to do and was such a priority. Only it's a serious regression.

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.

nvme0n1p1 35 minutes ago | parent

It's a 0.x project, let them cook. Building things takes time.

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.

simonask 5 minutes ago | parent

Isn't that exactly what they're saying?

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.

MonstraG 40 minutes ago | parent

I'm not the poster, but I found the related issue:

https://codeberg.org/ziglang/zig/issues/37402

stateoff 35 minutes ago | parent

Why not adding the link to the issue in the blog post?

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?

dleslie 32 minutes ago | parent

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.

nvme0n1p1 27 minutes ago | parent

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.

stateoff 24 minutes ago | parent

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

Joker_vD 23 minutes ago | parent

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

drdexebtjl 19 minutes ago | parent

strchr has no time complexity guarantees, by the way. This behavior is strictly correct.

nvme0n1p1 30 minutes ago | parent

AI slop. Every article on this site has "The honest tradeoff" as a header. Looks like it was generated to promote a book which is no doubt also just slop.

AlexeyBrin 14 minutes ago | parent

Let's not exaggerate, it took me 2 seconds to find another recent article from the same website without the "The honest tradeoff".

ibn_khaldun 4 minutes ago | parent

> Every article on this site has "The honest tradeoff" as a header.

This is a hallucination. I'm sorry. This is what we call these kind of statements these days. Unless you can prove your humanhood, that's how it is now.

raverbashing 20 minutes ago | parent

Yeah

The lack of a native slice is the most glaring C fault I think exists

(And of course the committees won't implement it, and of course C is going to remain broken)

pron 15 minutes ago | parent

Also, Zig is as at least as expressive as C++ (but without the implicitness and general language complexity that makes reviewing some sensitive code, where you need to see exactly what operations are performed, hard), and it supports arenas better than C/C++/Rust.