Zig is a nice language, but those articles always compare new languages against old-style C without use of modern tools. Most of the listed advantages you can have in C as well if you are willing to adopt modern tooling and style: signed overflow checking: sanitizers, errors you can not ignore: [[nodiscard]], slice type which know their size: variably-modified types or span types.
Defer will also appear in C compilers soon, but personally I still think goto-error handling is clearer.
(Rust has an advantage for temporal memory safety, but this does apply to Zig.)
God I loved playing around with D back in the day when I was in high school. It seemed like a no-brainer that it was going to be huge. It's such a shame it never took off. Incredible language.
All these new languages are unreadable relative to C. If, like me, you like explicit stuff like for (size_t i = 0; i <= n; i++) total += a[i]; all these new languages won't do it.
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.
Seems like a long way to walk though. Retrofitting this will take time (if it'll ever complete).
Zig made it a core part of the language and library. I'll assume Rust will make it farther than C++ ever made it, but just take a look at how retrofitting custom allocators is going there.
Seems like it will be useful for use-cases like embedded where you're restricted to certain parts of the library anyway. But the battle is kind of already lost for support at the level of Zig or Odin. Even if they retrofitted support for the whole standard library, they'll never be able retrofit all crates or make people even bother adding support for all new crates.
In critical low-level code, any kind of overloading - operator or otherwise - is something you'd rather not have.
By expressivity I don't mean conrecte syntax, but the number of lines needed to express an algorithm (up to a small constant). C doesn't have C++'s expressivity because it lacks templates, and while you can sort of express that kind of thing with macros, it's not all the way there. Zig, however, gets you all the way (you might need to write matrix_plus instead of +, but the expressivity is the same).
Many people are against operator overloading, imo my only issue with C++ operator overloading is that you're allowed to overload the the assignment operator. From what I can see this is the root of many issues
It's okay for me to declare a macro with `__attribute__((warn_unused_result))` for GCC and Clang, and `[[nodiscard]]` when the C code is later compiled with C++ (or nothing).
C is far behind the sate-of-art in C and Go families. True, but not bad.
It is what it is, but can work on what it already has, while keeping its tradition.
Small changes, add common extensions, conservative additions, improve coherence and correctness of the standard while keeping easy to implement and small.
No crazy things.
Keep in mind that it is standardized and targets things others do not target.
I don’t get it, C arrays can be used as slices, no?? Given a pointer and a length, which is how C does any array, works just as well (I mean if you consider arrays without a length a fine thing) as a slice!
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.
> 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.
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).
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.
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.
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?
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.
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?
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.
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...
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.
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)
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.
The dudes name is "llm_nerd" its not worth engaging lol. These are the same people that saw the bun rewrite in rust break tls and fail open and shrugged.
Defer will also appear in C compilers soon, but personally I still think goto-error handling is clearer.
(Rust has an advantage for temporal memory safety, but this does apply to Zig.)
Study after study has shown that in coding we tend to fall back to conflate simple with familiar.
Rust just stabilized its `Allocator` API in version 1.100.0. Definitely worth checking out!
Seems like it will be useful for use-cases like embedded where you're restricted to certain parts of the library anyway. But the battle is kind of already lost for support at the level of Zig or Odin. Even if they retrofitted support for the whole standard library, they'll never be able retrofit all crates or make people even bother adding support for all new crates.
By expressivity I don't mean conrecte syntax, but the number of lines needed to express an algorithm (up to a small constant). C doesn't have C++'s expressivity because it lacks templates, and while you can sort of express that kind of thing with macros, it's not all the way there. Zig, however, gets you all the way (you might need to write matrix_plus instead of +, but the expressivity is the same).
It's okay for me to declare a macro with `__attribute__((warn_unused_result))` for GCC and Clang, and `[[nodiscard]]` when the C code is later compiled with C++ (or nothing).
It is what it is, but can work on what it already has, while keeping its tradition. Small changes, add common extensions, conservative additions, improve coherence and correctness of the standard while keeping easy to implement and small.
No crazy things.
Keep in mind that it is standardized and targets things others do not target.
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)
But I am also quite happy about how far one already gets with variably modified types and a custom span type: https://godbolt.org/z/rPen5Movd
https://www.pangram.com/history/5f3d749c-713c-447a-82cc-d3a6...
I'm not ideologically against AI, but I'd certainly not buy a book from someone who needs to use AI to write like an article like that...
[0]: https://www.mtsoukalos.eu/2026/04/why-zig-over-rust-for-syst...
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.
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.
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?
[0] https://news.ycombinator.com/item?id=26296339
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 :)
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.
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?
https://codeberg.org/ziglang/zig/issues/37402
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.
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)
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.