| ▲ | h4ch1 8 hours 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. |
|
| ▲ | rtfeldman 6 hours ago | parent | next [-] |
| 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 |
|
| ▲ | kprotty 3 hours ago | parent | prev | next [-] |
| 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+a... [1]: https://github.com/Syndica/sig/pulls?q=is%3Apr+author%3Akpro... |
| |
| ▲ | ryanxsim 3 hours ago | parent [-] | | 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 | | |
| ▲ | weebull 29 minutes ago | parent | next [-] | | Two different philosophical approaches with Zig and Rust. - Zig: Let's have a simple language with as few footguns as possible and make good code easy to write. However we value explicitness and allow the developer to do anything they need to do. C interoperability is a primary feature that is always available. We have run time checks for as many areas of undetermined behaviour as we can. - Rust: let's make the compiler the guardian of what is safe to do. Unless the developer hits the escape hatch, we will disallow behaviour to keep the developer safe. To allow the compiler to reason about safety we will have an intricate type system which will contain concepts like lifetimes and data mobility. This will get complex sometimes so we will have a macro system to hide that complexity. Zig is a lot simpler than Rust, but I think it asks more of it's developer. | |
| ▲ | lionkor an hour ago | parent | prev [-] | | 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 an hour ago | parent | next [-] | | Seriously asking, where Go sits in this categorization? | | |
| ▲ | andrewl-hn 34 minutes ago | parent | next [-] | | Go is modern Java, at least based on the main area of usage: server infrastructure and backend services. | | |
| ▲ | bsaul 13 minutes ago | parent [-] | | i wonder what makes go more modern than java, in terms of features. |
| |
| ▲ | shilgapira 41 minutes ago | parent | prev [-] | | It's also a modern C. If you enjoy C and wish it was less verbose and more modern, try Go. | | |
| ▲ | bayindirh 35 minutes ago | parent [-] | | 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. |
|
| |
| ▲ | benob an hour ago | parent | prev [-] | | Time to start zig++ |
|
|
|
|
| ▲ | latch 7 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | sidkshatriya 4 hours ago | parent | next [-] | | > The biggest issue I face daily are silent compiler errors (SIGBUS) for trivial things, e.g. a typo in an import path. I don't use zig. My experience has been that caches themselves are sources of bugs (not talking about zig only, but in general). Clearing all relevant caches occasionally is useful when you're experiencing weird bugs. | | |
| ▲ | sidkshatriya 3 hours ago | parent [-] | | I don't know why I was downvoted here. One day, I was experiencing weird compilation errors. Clearing the `ccache` C/C++ compiler cache helped get past the problem. Yes, I could have investigated in detail what was the issue and if ccache had a bug but sometimes you don't have the luxury of investigating everything your toolchain throws at you. |
| |
| ▲ | quag 7 hours ago | parent | prev [-] | | 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 7 hours ago | parent [-] | | Just a slower build. From ~20 seconds to ~65 seconds the first time after I nuke it. | | |
| ▲ | h4ch1 5 hours ago | parent | next [-] | | 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 which was moved to 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? | | |
| ▲ | Cloudef 5 hours ago | parent [-] | | AFAIK garbage collection is basically not implemented yet. I myself do `ZIG_LOCAL_CACHE_DIR=~/.cache/zig` so I only have to nuke single directory whenever I feel like it. | | |
| ▲ | divan an hour ago | parent [-] | | what exactly people call 'garbage collection' in Zig? build cache cleanup? | | |
|
| |
| ▲ | sgt 5 hours ago | parent | prev [-] | | Does Zig have incremental builds yet? Or is it 20 secs each time for your build. | | |
| ▲ | latch 5 hours ago | parent [-] | | 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 4 hours ago | parent [-] | | 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. |
|
|
|
|
|
|
| ▲ | nickysielicki 4 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | the_duke 3 hours ago | parent | next [-] | | Rust has managed just fine to remain mostly backwards compatible since 1.0 , while still allowing for evolution of the language through editions. This puts much more work on the compiler development side, but it's a great boon for the ecosystem. To be fair, zig is pre 1.0, but Zig is also already 8 years old. Rust turned 1.0 at ~ 5 years, I think. | | | |
| ▲ | fouronnes3 4 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | munificent 4 hours ago | parent | next [-] | | 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. | | | |
| ▲ | pjmlp 4 hours ago | parent | prev [-] | | 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. |
| |
| ▲ | pjmlp 4 hours ago | parent | prev | next [-] | | There is a reason GCC, LLVM, CUDA, Metal, HPC,.. rely on C++ and will never rewrite to something else, including Zig. | | |
| ▲ | surajrmal 3 hours ago | parent [-] | | Yes, inertia. If those projects started today, they would likely choose rust. | | |
| ▲ | pjmlp 2 hours ago | parent [-] | | Why isn't rustc using Cranelift then? | | |
| ▲ | norman784 an hour ago | parent [-] | | I can think a few reasons: - Cranelift applies less optimizations in exchange for faster compilation times, because it was developed to compile WASM (wasmtime), but turns out that is good enough for Rust debug builds. - Cranelift does not support the wide range of platforms (AFAIK just X86_64 and some ARM targets) | | |
| ▲ | pjmlp 26 minutes ago | parent [-] | | So it isn't just a matter of "they would use Rust instead". There is a whole ecosystem of contributions across the globe and the lingua franca used by those contributors. |
|
|
|
| |
| ▲ | quotemstr 4 hours ago | parent | prev [-] | | Hilariously, they broke this compatibility. std::auto_ptr was an abomination, but removing it from the language was needless and undermined the long term stability that differentiates C++ from upstarts. | | |
|
|
| ▲ | Cloudef 7 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | hrmtst93837 3 hours ago | parent | next [-] | | Pinning your build chain and tooling to specific commits helps with stability but also traps you with old bugs or missing features. Chasing upstream fixes is a chore if you miss a release window and suddenly some depended package won't even compiile anymore. | |
| ▲ | Zambyte 7 hours ago | parent | prev [-] | | Using third party packages has gotten a lot easier with the changes described in this devlog https://ziglang.org/devlog/2026/#2026-02-06 |
|
|
| ▲ | sgt an hour ago | parent | prev | next [-] |
| > I know Bun's using zig to a degree of success, was wondering how the rest were doing. Just a degree of success? |
|
| ▲ | Escapade5160 7 hours ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | boomlinde 6 hours ago | parent | prev | next [-] |
| 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 4 hours ago | parent | prev | next [-] |
| 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 The makers of TigerBeatle also rave about how good Zig is. |
|
| ▲ | throwaway27448 6 hours ago | parent | prev [-] |
| 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) |
| |
| ▲ | beoberha 6 hours ago | parent [-] | | Bun is a full fledged JavaScript runtime! Think node.js but fast | | |
| ▲ | throwaway27448 5 hours ago | parent [-] | | > Think node.js but fast Color me extremely sceptical. Surely if you could make javascript fast google would have tried a decade ago.... | | |
| ▲ | leonflexo 5 hours ago | parent | next [-] | | 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 4 hours ago | parent [-] | | > 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. | | |
| ▲ | leonflexo 4 hours ago | parent | next [-] | | I think Bun helps with the memory pressure, granted this is relative to V8. I'd pushback on the certainty with the reality that TS provides a significant drop in entropy while benefiting from what is a sweet spot between massive corpus size and low barrier for typical problem/use-case complexity. You'll never have the fastest product with JS, but you will always have good speed to market and be able to move quickly. | |
| ▲ | dtj1123 4 hours ago | parent | prev | next [-] | | Claude CLI is based on bun. The dependency is so complete that Bun have now joined Anthropic. | | | |
| ▲ | messe 4 hours ago | parent | prev [-] | | > Surely nobody would use javascript for either yea? It's probably the most popular language for serverless. | | |
| ▲ | throwaway27448 4 hours ago | parent | next [-] | | I can't vouch for this behavior but obviously you can have a better serverless experience than writing lisp with the shittiest syntax invented by man | |
| ▲ | pjmlp 4 hours ago | parent | prev [-] | | Only because the likes of Vercel and Netlify barely offer anything else on their free tiers. When people go AWS, Azure, GCP,... other languages take the reigns. |
|
|
| |
| ▲ | rererereferred 3 hours ago | parent | prev | next [-] | | The actual JS code is in the same ballpark as nodejs. They get fast by specializing to each platform's fastest APIs instead of using generic ones, reimplementing JS libraries in Zig (for example npm or jest) and using faster libraries (for example they use the oniguruma regex engine). Also you don't need an extra transpiling step when using TypeScript. | |
| ▲ | undeveloper 4 hours ago | parent | prev [-] | | they have, v8 is a pretty fast engine and an engineering marvel. bun is faster at cost of having worse jit and less correctness |
|
|
|