8 ms·

I would really like to hear from people using Zig in production/semi-serious applications; where software stability is important. How's your experience with th

by h4ch1 7mo ago

I would really like to hear from people using Zig in production/semi-serious applications; where software stability is important. How's your experience with the constantly changing language? How're your update/rewrite cycles looking like? Are there cases where packages you may use fall behind the language? I know Bun's using zig to a degree of success, was wondering how the rest were doing.

Cloudef 7mo ago
The language itself does not change much, but the std does. It depends on individuals, but some people rely less on the std, some copy the old code that they still need. > Are there cases where packages you may use fall behind the language? Using third party packages is quite problematic yes. I don't recommend using them too much personally, unless you want to make more work for yourself.
- Zambyte 7mo ago
  Using third party packages has gotten a lot easier with the changes described in this devlog https://ziglang.org/devlog/2026/#2026-02-06 https://ziglang.org/devlog/2026/#2026-02-06
- hrmtst93837 7mo ago
  [flagged]
latch 7mo ago
Zig 0.15 is pretty stable. The biggest issue I face daily are silent compiler errors (SIGBUS) for trivial things, e.g. a typo in an import path. I've yet to find exactly why this [only sometimes] causes such a crash, but they're a real pain to figure out over a large changeset. `zig ast-check` sometimes catches the error, else Claude's pretty good at spotting where I accidentally re-used a variable name (again, 90% of the time I do that, it's an easy error, but the other 10%, I get a message-less compiler crash). It sounds like the changes in the OP might be specifically addressing these types of issues. Also, my .zig-cache is currently at 173GB, which causes some issues on the small Linux ARM VPS I test with. As for upgrades. I upgraded lightpanda to 0.14 then 0.15 and it was fine. I think for lightpanda, the 0.16 changes might not be too bad, with the only potential issue coming from our use of libcurl and our small websocket server (for CDP connections). Those layers are relatively isolated / abstracted, so I'm hopeful. As a library developer, I've given up following / tracking 0.16. For one, the change don't resonate with me, and for another, it's changing far too fast. I don't think anyone expects 0.16 support in a library right now. I've gotten PRs for my "dev" branches from a few brave souls and everyone seems happy with that arrangement.
- quag 7mo ago
  That .zig-cache seems massive to me. I keep mine on a tmpfs and remove it every time the tmpfs is full. Do you see any major problems when you remove your .zig-cache and start over?
  - latch 7mo ago
    Just a slower build. From ~20 seconds to ~65 seconds the first time after I nuke it.
    - sgt 7mo ago
      Does Zig have incremental builds yet? Or is it 20 secs each time for your build.
      - latch 7mo ago
        20 seconds each time. Last time I tried to enable incremental build, it wasn't working for us. It was a while ago, but I think it had to do with something in our v8 bridge.
        sgt 7mo ago
        I have heard that from other Zig devs too. Must get a bit annoying as the project grows. But I guess it will be supported sooner or later.
        cwillu 7mo ago
        It's discussed in the post.
    - h4ch1 7mo ago
      But why is it so big in the first place? I was searching around for causes and came across the following issues: https://github.com/ziglang/zig/issues/15358 https://github.com/ziglang/zig/issues/15358 which was moved to https://codeberg.org/ziglang/zig/issues/30193 https://codeberg.org/ziglang/zig/issues/30193 The following quotes stand out > zig's caching system is designed explicitly so that garbage collection could happen in one process simultaneously while the cache is being used by another process. > I just ran WizTree to find out why my disk was full, and the zig cache for one project alone was like 140 GB. > not only the .zig-cache directory in my projects, but the global zig cache directory which is caching various dependencies: I'm finding each week I have to clear both caches to prevent run-away disk space Like what's going on? This doesn't seem normal at all. I also read somewhere that zig stores every version of your binary as well? Can you shed some light on why it works like this in zigland?
Escapade5160 7mo ago
I recently tried to learn it and found it frustrating. A lot of docs are for 0.15 but the latest is (or was) 0.16 which changed a lot of std so none of the existing write ups were valid anymore. I plan to revisit once it gets more stable because I do like it when I get it to work.
- Cloudef 7mo ago
  0.16 is the development version. 0.15.2 is latest release.
rtfeldman 7mo ago
I maintain a ~250K LoC Zig compiler code base [0]. We've been through several breaking Zig releases (although the code base was much smaller for most of that time; Writergate is the main one we've had to deal with since the code base crossed the 100K LoC mark). The language and stdlib changing hasn't been a major pain point in at least a year or two. There was some upgrade a couple of years ago that took us awhile to land (I think it might have been 0.12 -> 0.13 but I could be misremembering the exact version) but it's been smooth sailing for a long time now. These days I'd put breaking releases in the "minor nuisance" category, and when people ask what I've liked and disliked about using Zig I rarely even remember to bring it up. [0]: https://github.com/roc-lang/roc https://github.com/roc-lang/roc
- sureglymop 7mo ago
  At this point do you believe porting the codebase to Zig was the right decision? Do you have any regrets? Also, I'm excited about trying out your language even moreso than Zig. :)
- wvlia5 7mo ago
  What's the main value proposition of roc? I found interesting tags (like symbols in mathematica) and tags with payloads (like python namedtuple or dataclasses). I haven't seen this elsewhere. Otherwise seems quite typical (Pattern matching is quite common, for example). Example programs that you couldn't easily express in other languages?
- rkangel 7mo ago
  Are you aware that your Github README doesn't actually tell us anything about Roc is or why we might be interested? This might be on purpose given the first words are "Work in progress" and "not ready for release", but linking as above does lose some value.
  - messe 7mo ago
    Instead of being rude, consider checking Roc's website: https://roc-lang.org/ https://roc-lang.org/ He wasn't pitching the language directly, but linking to the codebase as that was what was relevant to the comment he was replying to.
throwaway27448 7mo ago
For those like me who have never heard of this software: Bun, some sort of package management service for javascript. https://en.wikipedia.org/wiki/Bun_(software) https://en.wikipedia.org/wiki/Bun_(software)
- beoberha 7mo ago
  Bun is a full fledged JavaScript runtime! Think node.js but fast
  - throwaway27448 7mo ago
    > Think node.js but fast Color me extremely sceptical. Surely if you could make javascript fast google would have tried a decade ago....
    - leonflexo 7mo ago
      Bun uses JSC (JavaScriptCore) instead of V8. From what I understand, whereas Node/V8 has a higher tier 4 "top speed", JSC is more optimized for memory and is faster to tier up early/less overhead. Good for serverless. Great for agents -> Anthropic purchase.
      - throwaway27448 7mo ago
        > Good for serverless. Great for agents -> Anthropic purchase. Surely nobody would use javascript for either yea? The weaknesses of the language are amplified in constrained environments: low certainty, high memory pressure, high startup costs.
        messe 7mo ago
        > Surely nobody would use javascript for either yea? It's probably the most popular language for serverless.
        7mo ago
boomlinde 7mo ago
I stopped updating the compiler at 0.14 for three projects. Getting the correct toolchain is part of my (incremental) build process. I don't use any external Zig packages. I think one of the more PITA changes necessary to get these projects to 0.15 is removing `usingnamespace`, which I've used to implement a kind of mixin. The projects are all a few thousand LOC and it shouldn't be that much trouble, but enough trouble that none of what I gain from upgrading currently justify doing it. I think that's fine.
scuff3d 7mo ago
Mitchell Hashimoto (developer of Ghostty) talks about Zig a lot. Ghostty is written in it, and he seems to love it. The churn doesn't seem to bother him at all. I asked him about in a thread a while back: https://news.ycombinator.com/item?id=47206009#47209313 https://news.ycombinator.com/item?id=47206009#47209313 The makers of TigerBeatle also rave about how good Zig is.
nickysielicki 7mo ago
The forever backwards compatible promise of C++ was a tremendous design mistake that has resulted in mindshare death as of 2026. It might suck to have to modify your code to continue to get it to work, but it’s the right long term approach.
- fouronnes3 7mo ago
  Mindshare death is a very large overstatement given the massive amount of legacy C++ out there that will be maintained by poor souls for year to come. But you are right, there used to be a great language hiding within C++ if the committee ever dared to break backwards compat. But even if they did it now it would be too late and they'd just end up with a worse Rust or Zig.
  - pjmlp 7mo ago
    As proven a few times, it doesn't matter if committee decides to break something if compiler vendors aren't on board with what is being broken. There is still this disconnection on how languages under ISO process work in the industry.
    - jonstewart 7mo ago
      The C++ standards committee’s antiquated reliance on compiler “vendors” holds it back. They should adopt maintenance of clang and bless it as the reference compiler.
      - pjmlp 7mo ago
        And you will be the one telling the losers that their compiler, operating systems and OS doesn't count? By the way this applies to the C language so beloved on this corner as well. As it does to COBOL, Fortran, Ada and JS (ECMA is not much different from ISO).
  - munificent 7mo ago
    The biggest problem with C++ is that while everyone agrees there is a great language hiding in it, everyone also has a remarkably different idea of what that great language actually is.
kprotty 7mo ago
I've worked on two "production" zig codebases: tigerbeetle [0] and sig [1]. These larger zig projects will stick to a tagged release (which doesn't change), and upgrade to newly tagged releases, usually a few days or months after they come out. The upgrade itself takes like a week, depending on the amount of changes to be done. These projects also tend to not use other zig dependencies. [0]: https://github.com/tigerbeetle/tigerbeetle/pulls?q=is%3Apr+author%3Akprotty+is%3Aclosed https://github.com/tigerbeetle/tigerbeetle/pulls?q=is%3Apr+a... [1]: https://github.com/Syndica/sig/pulls?q=is%3Apr+author%3Akprotty+is%3Aclosed https://github.com/Syndica/sig/pulls?q=is%3Apr+author%3Akpro...
- ryanxsim 7mo ago
  I really wanted to deep dive into zig but I'm into rust now kinda late as I'm really just started like 2024. Have you tried rust? how does it compared to zig? * just asking
  - lionkor 7mo ago
    Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.
    - bayindirh 7mo ago
      Seriously asking, where Go sits in this categorization?
      - shilgapira 7mo ago
        It's also a modern C. If you enjoy C and wish it was less verbose and more modern, try Go.
        bayindirh 7mo ago
        Thanks. I write some Go, and feel the same about it. I really enjoy it actually. Maybe I'll jump to Zig as a side-gig (ha, it rhymes), but I still can't motivate myself to play with Rust. I'm happy with C++ on that regard. Maybe gccrs will change that, IDK, yet.
sgt 7mo ago
> I know Bun's using zig to a degree of success, was wondering how the rest were doing. Just a degree of success?
ptrwis 7mo ago
You can fix you code 10 times you will fix it.
hansvm 7mo ago
It's been a non-issue for us at tvScientific. Once or twice a year you settle in for a mass refactor, and when that's done you move on with your day. Packages do fall behind. We only use a couple, so it's pretty easy to point to an internal fork while we wait for upstream to update or to accept our updates. That'd probably be a pain point if you were using a lot of them.
steeve 7mo ago
hi, i'm the founder of https://github.com/zml/zml https://github.com/zml/zml, very happy with Zig
MrResearcher 7mo ago
Running a ~20Kloc 0.16 Zig in prod, compiled and deployed as DebugSafe. No issues, superstable. This was rewrite of Node.js/Typescript computation module, and we chose Zig over Rust due to better support for f128. Zig/DebugSafe is approximately twice faster than TypeScript/Node.js 25 for our purpose, with approximately 70% less memory consumption. We were not impacted by WriterGate and other recent scandals much because we primarily rely on libc, and we don't use much of Zig's I/O standard lib. Zig has a better support for sqlite/JSON serialization (everything is strongly typed and validated) than Node.js, so that was a plus as well. Zig minuses are well known: lack of syntax sugar for closures/lambdas/vtable, which makes it hard to isolate layers of code for independent development. We use Arcs (atomic reference counting) with resource scopes (bumper allocators) extensively, so memory safety is not a concern despite aggressively multithreading logic. The default allocator automatically detects memory leaks, use-after-free, etc so we are planning to continue running it in DebugSafe indefinitely. We tried switching to ReleaseFast and gained about 25%, which is not that much faster to lose memory safety guarantees.

by h4ch1 7mo ago

Cloudef 7mo ago

The language itself does not change much, but the std does. It depends on individuals, but some people rely less on the std, some copy the old code that they still need. > Are there cases where packages you may use fall behind the language? Using third party packages is quite problematic yes. I don't recommend using them too much personally, unless you want to make more work for yourself.

Zambyte 7mo ago
Using third party packages has gotten a lot easier with the changes described in this devlog https://ziglang.org/devlog/2026/#2026-02-06 https://ziglang.org/devlog/2026/#2026-02-06
hrmtst93837 7mo ago
[flagged]

latch 7mo ago

Zig 0.15 is pretty stable. The biggest issue I face daily are silent compiler errors (SIGBUS) for trivial things, e.g. a typo in an import path. I've yet to find exactly why this [only sometimes] causes such a crash, but they're a real pain to figure out over a large changeset. `zig ast-check` sometimes catches the error, else Claude's pretty good at spotting where I accidentally re-used a variable name (again, 90% of the time I do that, it's an easy error, but the other 10%, I get a message-less compiler crash). It sounds like the changes in the OP might be specifically addressing these types of issues. Also, my .zig-cache is currently at 173GB, which causes some issues on the small Linux ARM VPS I test with. As for upgrades. I upgraded lightpanda to 0.14 then 0.15 and it was fine. I think for lightpanda, the 0.16 changes might not be too bad, with the only potential issue coming from our use of libcurl and our small websocket server (for CDP connections). Those layers are relatively isolated / abstracted, so I'm hopeful. As a library developer, I've given up following / tracking 0.16. For one, the change don't resonate with me, and for another, it's changing far too fast. I don't think anyone expects 0.16 support in a library right now. I've gotten PRs for my "dev" branches from a few brave souls and everyone seems happy with that arrangement.

quag 7mo ago
That .zig-cache seems massive to me. I keep mine on a tmpfs and remove it every time the tmpfs is full. Do you see any major problems when you remove your .zig-cache and start over?
- latch 7mo ago
  Just a slower build. From ~20 seconds to ~65 seconds the first time after I nuke it.
  - sgt 7mo ago
    Does Zig have incremental builds yet? Or is it 20 secs each time for your build.
    - latch 7mo ago
      20 seconds each time. Last time I tried to enable incremental build, it wasn't working for us. It was a while ago, but I think it had to do with something in our v8 bridge.
      - sgt 7mo ago
        I have heard that from other Zig devs too. Must get a bit annoying as the project grows. But I guess it will be supported sooner or later.
        cwillu 7mo ago
        It's discussed in the post.
  - h4ch1 7mo ago
    But why is it so big in the first place? I was searching around for causes and came across the following issues: https://github.com/ziglang/zig/issues/15358 https://github.com/ziglang/zig/issues/15358 which was moved to https://codeberg.org/ziglang/zig/issues/30193 https://codeberg.org/ziglang/zig/issues/30193 The following quotes stand out > zig's caching system is designed explicitly so that garbage collection could happen in one process simultaneously while the cache is being used by another process. > I just ran WizTree to find out why my disk was full, and the zig cache for one project alone was like 140 GB. > not only the .zig-cache directory in my projects, but the global zig cache directory which is caching various dependencies: I'm finding each week I have to clear both caches to prevent run-away disk space Like what's going on? This doesn't seem normal at all. I also read somewhere that zig stores every version of your binary as well? Can you shed some light on why it works like this in zigland?

Escapade5160 7mo ago

I recently tried to learn it and found it frustrating. A lot of docs are for 0.15 but the latest is (or was) 0.16 which changed a lot of std so none of the existing write ups were valid anymore. I plan to revisit once it gets more stable because I do like it when I get it to work.

Cloudef 7mo ago
0.16 is the development version. 0.15.2 is latest release.

rtfeldman 7mo ago

I maintain a ~250K LoC Zig compiler code base [0]. We've been through several breaking Zig releases (although the code base was much smaller for most of that time; Writergate is the main one we've had to deal with since the code base crossed the 100K LoC mark). The language and stdlib changing hasn't been a major pain point in at least a year or two. There was some upgrade a couple of years ago that took us awhile to land (I think it might have been 0.12 -> 0.13 but I could be misremembering the exact version) but it's been smooth sailing for a long time now. These days I'd put breaking releases in the "minor nuisance" category, and when people ask what I've liked and disliked about using Zig I rarely even remember to bring it up. [0]: https://github.com/roc-lang/roc https://github.com/roc-lang/roc

sureglymop 7mo ago
At this point do you believe porting the codebase to Zig was the right decision? Do you have any regrets? Also, I'm excited about trying out your language even moreso than Zig. :)
wvlia5 7mo ago
What's the main value proposition of roc? I found interesting tags (like symbols in mathematica) and tags with payloads (like python namedtuple or dataclasses). I haven't seen this elsewhere. Otherwise seems quite typical (Pattern matching is quite common, for example). Example programs that you couldn't easily express in other languages?
rkangel 7mo ago
Are you aware that your Github README doesn't actually tell us anything about Roc is or why we might be interested? This might be on purpose given the first words are "Work in progress" and "not ready for release", but linking as above does lose some value.
- messe 7mo ago
  Instead of being rude, consider checking Roc's website: https://roc-lang.org/ https://roc-lang.org/ He wasn't pitching the language directly, but linking to the codebase as that was what was relevant to the comment he was replying to.

throwaway27448 7mo ago

For those like me who have never heard of this software: Bun, some sort of package management service for javascript. https://en.wikipedia.org/wiki/Bun_(software) https://en.wikipedia.org/wiki/Bun_(software)

beoberha 7mo ago
Bun is a full fledged JavaScript runtime! Think node.js but fast
- throwaway27448 7mo ago
  > Think node.js but fast Color me extremely sceptical. Surely if you could make javascript fast google would have tried a decade ago....
  - leonflexo 7mo ago
    Bun uses JSC (JavaScriptCore) instead of V8. From what I understand, whereas Node/V8 has a higher tier 4 "top speed", JSC is more optimized for memory and is faster to tier up early/less overhead. Good for serverless. Great for agents -> Anthropic purchase.
    - throwaway27448 7mo ago
      > Good for serverless. Great for agents -> Anthropic purchase. Surely nobody would use javascript for either yea? The weaknesses of the language are amplified in constrained environments: low certainty, high memory pressure, high startup costs.
      - messe 7mo ago
        > Surely nobody would use javascript for either yea? It's probably the most popular language for serverless.
        7mo ago

boomlinde 7mo ago

I stopped updating the compiler at 0.14 for three projects. Getting the correct toolchain is part of my (incremental) build process. I don't use any external Zig packages. I think one of the more PITA changes necessary to get these projects to 0.15 is removing `usingnamespace`, which I've used to implement a kind of mixin. The projects are all a few thousand LOC and it shouldn't be that much trouble, but enough trouble that none of what I gain from upgrading currently justify doing it. I think that's fine.

scuff3d 7mo ago

Mitchell Hashimoto (developer of Ghostty) talks about Zig a lot. Ghostty is written in it, and he seems to love it. The churn doesn't seem to bother him at all. I asked him about in a thread a while back: https://news.ycombinator.com/item?id=47206009#47209313 https://news.ycombinator.com/item?id=47206009#47209313 The makers of TigerBeatle also rave about how good Zig is.

nickysielicki 7mo ago

The forever backwards compatible promise of C++ was a tremendous design mistake that has resulted in mindshare death as of 2026. It might suck to have to modify your code to continue to get it to work, but it’s the right long term approach.

fouronnes3 7mo ago
Mindshare death is a very large overstatement given the massive amount of legacy C++ out there that will be maintained by poor souls for year to come. But you are right, there used to be a great language hiding within C++ if the committee ever dared to break backwards compat. But even if they did it now it would be too late and they'd just end up with a worse Rust or Zig.
- pjmlp 7mo ago
  As proven a few times, it doesn't matter if committee decides to break something if compiler vendors aren't on board with what is being broken. There is still this disconnection on how languages under ISO process work in the industry.
  - jonstewart 7mo ago
    The C++ standards committee’s antiquated reliance on compiler “vendors” holds it back. They should adopt maintenance of clang and bless it as the reference compiler.
    - pjmlp 7mo ago
      And you will be the one telling the losers that their compiler, operating systems and OS doesn't count? By the way this applies to the C language so beloved on this corner as well. As it does to COBOL, Fortran, Ada and JS (ECMA is not much different from ISO).
- munificent 7mo ago
  The biggest problem with C++ is that while everyone agrees there is a great language hiding in it, everyone also has a remarkably different idea of what that great language actually is.

kprotty 7mo ago

I've worked on two "production" zig codebases: tigerbeetle [0] and sig [1]. These larger zig projects will stick to a tagged release (which doesn't change), and upgrade to newly tagged releases, usually a few days or months after they come out. The upgrade itself takes like a week, depending on the amount of changes to be done. These projects also tend to not use other zig dependencies. [0]: https://github.com/tigerbeetle/tigerbeetle/pulls?q=is%3Apr+author%3Akprotty+is%3Aclosed https://github.com/tigerbeetle/tigerbeetle/pulls?q=is%3Apr+a... [1]: https://github.com/Syndica/sig/pulls?q=is%3Apr+author%3Akprotty+is%3Aclosed https://github.com/Syndica/sig/pulls?q=is%3Apr+author%3Akpro...

ryanxsim 7mo ago
I really wanted to deep dive into zig but I'm into rust now kinda late as I'm really just started like 2024. Have you tried rust? how does it compared to zig? * just asking
- lionkor 7mo ago
  Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.
  - bayindirh 7mo ago
    Seriously asking, where Go sits in this categorization?
    - shilgapira 7mo ago
      It's also a modern C. If you enjoy C and wish it was less verbose and more modern, try Go.
      - bayindirh 7mo ago
        Thanks. I write some Go, and feel the same about it. I really enjoy it actually. Maybe I'll jump to Zig as a side-gig (ha, it rhymes), but I still can't motivate myself to play with Rust. I'm happy with C++ on that regard. Maybe gccrs will change that, IDK, yet.

sgt 7mo ago

> I know Bun's using zig to a degree of success, was wondering how the rest were doing. Just a degree of success?

ptrwis 7mo ago

You can fix you code 10 times you will fix it.

hansvm 7mo ago

It's been a non-issue for us at tvScientific. Once or twice a year you settle in for a mass refactor, and when that's done you move on with your day. Packages do fall behind. We only use a couple, so it's pretty easy to point to an internal fork while we wait for upstream to update or to accept our updates. That'd probably be a pain point if you were using a lot of them.

steeve 7mo ago

hi, i'm the founder of https://github.com/zml/zml https://github.com/zml/zml, very happy with Zig

MrResearcher 7mo ago

Running a ~20Kloc 0.16 Zig in prod, compiled and deployed as DebugSafe. No issues, superstable. This was rewrite of Node.js/Typescript computation module, and we chose Zig over Rust due to better support for f128. Zig/DebugSafe is approximately twice faster than TypeScript/Node.js 25 for our purpose, with approximately 70% less memory consumption. We were not impacted by WriterGate and other recent scandals much because we primarily rely on libc, and we don't use much of Zig's I/O standard lib. Zig has a better support for sqlite/JSON serialization (everything is strongly typed and validated) than Node.js, so that was a plus as well. Zig minuses are well known: lack of syntax sugar for closures/lambdas/vtable, which makes it hard to isolate layers of code for independent development. We use Arcs (atomic reference counting) with resource scopes (bumper allocators) extensively, so memory safety is not a concern despite aggressively multithreading logic. The default allocator automatically detects memory leaks, use-after-free, etc so we are planning to continue running it in DebugSafe indefinitely. We tried switching to ReleaseFast and gained about 25%, which is not that much faster to lose memory safety guarantees.