| ▲ | llm_nerd 2 days ago |
| 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. |
|
| ▲ | lukaslalinsky 2 days ago | parent | next [-] |
| When working with Zig, you are a beta tester. The development process is unfortunately not great, so bugs slip in fairly easily. You need to be ready for it and test your application properly. Large Zig projects don't target the latest version. That said, if you can deal with that, you get a great language that is fun to use and very practical. I think it's worth it, even if it can be frustrating at times. |
| |
| ▲ | brabel 2 days ago | parent [-] | | I agree Zig can be fun but for real projects people should stick with Rust or even D which is just as fun! |
|
|
| ▲ | stateoff 2 days ago | parent | prev | next [-] |
| 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 2 days 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. | | |
| ▲ | Joker_vD 2 days ago | parent | next [-] | | 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 | | |
| ▲ | dleslie 2 days ago | parent [-] | | sscanf is quadratic in the worst case, and has been flagged along with the bulk of the rest of the libc string support as being hazardous or potentially harmful. Its continued existence is for compatibility, but new projects should not use it. | | |
| ▲ | Joker_vD 2 days ago | parent [-] | | First of all, sscanf doesn't need to be quadratic in the worst case; it absolutely can work without finding the NUL-terminator first. Second, I'd like to see that list of "flagged along with the bulk of the rest of the libc string support as being hazardous or potentially harmful" functions. Does this list include strchr()? Because if yes, your original argument fails to stand. | | |
| ▲ | dleslie 2 days ago | parent [-] | | strchr relies on null termination and returns a pointer. It's absolutely vulnerable to abuse. There are many CVEs related to the use of strchr. | | |
| ▲ | Joker_vD a day ago | parent [-] | | So why do you consider zig's less-than-performant implementation of strchr to be so egregious as to serve as its condemnation while you give glibc a free pass for exactly the same blunder? Why the double standards? In fact, it's even worse with glibc because it's four times as old as zig. | | |
| ▲ | dleslie a day ago | parent [-] | | It's not a problem in isolation. And like I said, the c standard string library is generally considered harmful and dangerous; it does not get a pass. And besides the stability issues, their response to Bun was enough to make it clear that it is a user hostile project. I would never trust a vendor that behaved in that manner to a long standing user, financier and advocate. |
|
|
|
|
| |
| ▲ | nvme0n1p1 2 days ago | parent | prev | next [-] | | 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 2 days ago | parent | prev | next [-] | | 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 :) | |
| ▲ | Zak 2 days ago | parent | prev [-] | | 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. |
|
|
|
| ▲ | senderista 2 days ago | parent | prev | next [-] |
| Zig can be a hobby/learning project (in which case these elementary mistakes, and the lax development process that allowed them, are totally acceptable), or it can be a project that targets critical applications (like TigerBeetle, which handles REAL MONEY), but it can't be both. |
|
| ▲ | drdexebtjl 2 days ago | parent | prev | next [-] |
| strchr has no time complexity guarantees, by the way. This behavior is strictly correct. |
| |
|
| ▲ | dnautics 2 days ago | parent | prev | next [-] |
| > 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? |
| |
| ▲ | MonstraG 2 days ago | parent | next [-] | | I'm not the poster, but I found the related issue: https://codeberg.org/ziglang/zig/issues/37402 | |
| ▲ | llm_nerd 2 days ago | parent | prev | next [-] | | 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 2 days 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 2 days ago | parent | next [-] | | 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. | | |
| ▲ | dnautics 2 days ago | parent | next [-] | | No, the framing "give pause" is the sort of framing that people create FUD create | | |
| ▲ | llm_nerd 2 days ago | parent [-] | | 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, and the response have been much more significant reasons why you should be wary. 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 barely anyone works on it, and... By the advocates for the language, it should be noted. 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. |
| |
| ▲ | nvme0n1p1 2 days ago | parent | prev [-] | | Zig team: "Zig is 0.x and has known bugs" 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. Especially since they only recently started working on the libc port (although it had been talked about for much longer) |
| |
| ▲ | diffxx 2 days ago | parent | prev | next [-] | | They have been cooking for over ten years. It is more than fair to say at this point that they are not capable of shipping a stable, reliable, fast and efficient compiler. It is fundamentally flawed and I could easily write thousands of words explaining why from the architectural design to the development process. 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. | | |
| ▲ | alexrp 2 days ago | parent | next [-] | | > It is fundamentally flawed and I could easily write thousands of words explaining why from the architectural design to the development process. Always happy to learn. | |
| ▲ | nvme0n1p1 2 days ago | parent | prev [-] | | > I could easily write thousands of words explaining why from the architectural design to the development process. Alright then go for it, hotshot. We're waiting. |
| |
| ▲ | forgotpwd16 2 days ago | parent | prev | next [-] | | It has been 0.x for 10y+. At this point won't be off if considered 0ver (https://0ver.org) and permanently beta. | |
| ▲ | acedTrex 2 days ago | parent | prev [-] | | [flagged] | | |
| ▲ | rixed 2 days ago | parent | next [-] | | How could we call that variety of ad hominem fallacy that does not even target the person but his name, or even pseudonym? Ad nominem? | |
| ▲ | a day ago | parent | prev [-] | | [deleted] |
|
|
| |
| ▲ | senderista 2 days ago | parent | prev [-] | | If their resources are so limited, why have they decided that rewriting libc from scratch is a top priority? | | |
|
|
| ▲ | rixed 2 days ago | parent | prev | next [-] |
| Interesting read. For what it's worth, coming from an era where it was trivial to cross compile, I can't help but think that the real issue here is: > sqlite is of course a C project – so to facilitate cross-platform building, (...) zig cc is used to compile sqlite when targeting Linux
|
|
| ▲ | chandlore 2 days ago | parent | prev [-] |
| Andrew Kelley had a comment re this bug over at lobste.rs: > 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_... |
