[h4ch1]

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]

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

[sureglymop]

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]

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]

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]

Instead of being rude, consider checking Roc's website: 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.

[rkangel]

If I missed with tone, that's on me. I was going for "helpful constructive feedback".

[kprotty]

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]

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]

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.

[lerno]

> However we value explicitness and allow the developer to do anything they need to do*

* except for having unused variables. Those are so dangerous the compiler will refuse the code every time.

[rllj]

They are indeed dangerous, and I think this is a pretty good example of why.

https://andrewkelley.me/post/openzfs-bug-ported-zig.html

[dnautics]

don't know if it's still on the table, but Andrew has hinted that the unused variables error may in the future still produce an executable artefact but return an nonzero return code for the compiler. And truly fatal errors would STILL produce an executable artefact too, just one that prints "sorry this compilation had a fatal error" to stdout.

[nulltype]

It’s hard to say that one needs unused variables.

[duped]

If I comment out sections of code while debugging or iterating I don't want a compile error for some unused variable or argument. Warning. fine, but this happens to me so frequently that the idea of unused variables being an error is insane to me.

[gabriela_c]

Same for kernel drivers

[xeonmc]

Rust is a Bugatti Veyron, Zig is a McLaren F1.

[CyberDildonics]

as few footguns as possible

There are no destructors so all the memory ownership footguns are still there.

[thezipcreator]

sure, but when I've written zig this has never been an issue for me. `defer` makes memory management really easy.

If you want to auto-generate destructors, zig has really good comptime features that can let you do that.

[CyberDildonics]

defer is still something you have to consciously put in every time so it destroys the value semantics that C++ has, which is the important part. You don't have to "just write defer after a string", you can just use a string.

The 'not a problem for me' is what people would say about manual memory in C too. Defer is better but it isn't as good as what is already in use.

[Ygg2]

That's disingenous, Rust tries to minimize errors, first at compile time then at runtime, even if it at some discomfort of to programer.

Zig goes for simplicity while removing a few footguns. It's more oriented towards programmer enjoyment. Keep in mind that programmers don't distinguish ease of writing code from ease of writing unforeseen errors.

[kprotty]

Yes, I've written a few unsafe-focused crates [0], some of which have been modified & merged into the stdlib [1] [2] exposing them to the fringe edge-cases of Rust like strict provenance.

IMO, Rust is good for modeling static constraints - ideal when there's multiple teams of varying skill trying to work on the same codebase, as the contracts for components are a lot clearer. Zig is good for expressing system-level constructs efficiently: doing stuff like self-referential/intrusive data structures, cross-platform simd, and memory transformations is a lot easier in Zig than Rust.

Personally, I like Zig more.

[0] https://crates.io/users/kprotty

[1] https://github.com/rust-lang/rust/pull/95801

[2] https://github.com/rust-lang/rust/blob/a63150b9cb14896fc22f9...

[lionkor]

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.

[mgoetzke]

As someone who never liked writing anything C++ since 2000+ (did like it before) I cannot agree with this. C++ and Rust are not comparable in this sense at all.

One can argue Rust is what C++ wanted to be maybe. But C++ as it is now is anything but clean and clear.

[lionkor]

See my other comment[1]

It replaces C++ for me, so I would say it's "a C++"

[1]: https://news.ycombinator.com/item?id=47334275

[keybored]

And in a world of only you your claim is true.

[naasking]

I think the comparison is fair, strictly in the sense that both Rust and C++ are designed around extensible programming via a sort of subtyping (C++ classes, Rust traits), and similar resource management patterns (ownership, RAII), where Zig and C do not have anything comparable.

[api]

My take, unfortunately, is that Zig might be a more modern C but that gives us little we don’t already have.

Rust gives us memory safety by default and some awesome ML-ish type system features among other things, which are things we didn’t already have. Memory safety and almost totally automatic memory management with no runtime are big things too.

Go, meanwhile, is like a cleaner more modern Java with less baggage. You might also compare it to Python, but compiled.

[kprotty]

Zig gives things we really dont have yet: C + generics + good const eval + good build system + easy cross compilation + modern niceties (optionals, errors, sum types, slices, vectors, arbitrary bit packing, expression freedom).

Are there any other languages that provide this? Would genuinely consider the switch for some stuff if so.

[vitaminCPP]

+1 The zig toolchain is the state of the art currently.

[microtonal]

It is kind of interesting that the Linux kernel is slowly adopting Rust, whereas Zig seems like it would be a more natural fit?

I know, timelines not matching up, etc.

[andrepd]

Definitely not. Rust gives you a tangible benefit in terms of correctness. It's such a valuable benefit that it outweighs the burden of incorporating a new language in the kernel, with all that comes with it.

Zig offers no such thing. It would be a like-for-like replacement of an unsafe old language with an unsafe new one. May even be a better language, but that's not enough reason to overcome the burden.

[dnautics]

actually that's not true at all. Zig offers you some more safety than C. And it also affords you a compiler architecture and stdlib that is so well designed you could probably bolt on memory safety relatively easily as a 3rd party static checker

https://github.com/ityonemo/clr

[nasretdinov]

Memory safety by default in kernel sounds like a good idea :). However I don't think that C is being _replaced_ by Rust code, it's rather that more independent parts that don't need to deeply integrate with the existing C constructs can be written in a memory safe language, and IMO that's a fine tradeoff

[smj-edison]

I believe Rust is mainly being used for driver development, which seems a great fit (there's so many people of different skill levels who write Linux drivers, so this should help avoid bad driver code being exploited). It may also end up in the core systems, but it also might not fit there as well.

[keybored]

And “if you enjoy C++/if you enjoy C” are gross oversimplifications.

[lII1lIlI11ll]

It is not about timelines. Linux Torvalds doesn't spend nights reading bunch of books with crabs on their covers rewriting random bits and pieces of the kernel in Rust. It is basically a dedicated group of people sponsored by megacorps doing the heavy lifting. If megacorps wanted Zig we could have had it in the kernel instead (Linux might have rejected it though, not sure what he thinks of it).

[lionkor]

And Zig isn't stable yet

[geon]

Comparing Rust to C++ feels strange to me.

It’s like people do it just because Zig is very comparable to C. So the more complex Rust must be like something else that is also complex, right? And C++ is complex, so…

But that is a bit nonsensical. Rust isn’t very close to C++ at all.

[lionkor]

I wrote lots of C++ before learning Rust, and I enjoyed it. Since learning Rust, I write no more C++. I found no place in which C++ is a better fit than Rust, and so it's my "new C++".

For example, high performance servers (voltlane.net), programming languages (https://github.com/HF-Foundation, https://github.com/lionkor/mcl-rs, and one private one), webservers (beampaint.com) and lots of other domains.

Rust is close to C++ in that it is a systems language that allows a reasonable level of zero-cost abstractions.

[pjmlp]

> found no place in which C++ is a better fit than Rust, and so it's my "new C++".

Writing the compiler toolchains that Rust depends on, industry standards like CUDA, SYSCL, Metal, Unreal or the VFX Reference Platform.

[geon]

> Rust is close to C++ in that it is a systems language that allows a reasonable level of zero-cost abstractions.

That's like saying php is close to haskell because they both have garbage collection.

[jodleif]

I found swift way more enjoyable than rust as a C++ alternative. It even has first class-ish interop now.

[bayindirh]

Seriously asking, where Go sits in this categorization?

[gf000]

Nowhere, or wherever C# would sit. Go is a high level managed language.

[andrewl-hn]

Go is modern Java, at least based on the main area of usage: server infrastructure and backend services.

[KronisLV]

Tbh Go is also really nice for various local tools where you don’t want something as complex as C++ but also don’t want to depend on the full C# runtime (or large bundles when self-contained), or the same with Java.

With Wails it’s also a low friction way to build desktop software (using the heretical web tech that people often reach for, even for this use case), though there are a few GUI frameworks as well.

Either way, self contained executables that are easy to make and during development give you a rich standard library and not too hard of a language to use go a long way!

[9rx]

Go is modern/faster Python.

- It was explicitly intended to "feel dynamically-typed"

- Tries to live by the zen of Python (more than Python itself!)

- Was built during the time it was fashionable to use Python for the kinds of systems it was designed for, with Google thinking at the time that they would benefit from moving their C++ systems to that model if they could avoid incurring the performance problems associated with Python. Guido Van Rossum was also employed at Google during this time. They were invested in that sort of direction.

- Often reads just like Python (when one hasn't gone deep down the rabbit hole of all the crazy Python features)

[bsaul]

i wonder what makes go more modern than java, in terms of features.

[shilgapira]

It's also a modern C.

If you enjoy C and wish it was less verbose and more modern, try Go.

[VorpalWay]

Go has a garbage collector though. This makes it unsuitable for many use cases where you could have used C or C++ in the past. Rust and Zig don't have a GC, so they are able to fill this role.

GC is a showstopper for my day job (hard realtime industrial machine control/robotics), but would also be unwanted for other use cases where worst case latency is important, such as realtime audio/video processing, games (where you don't want stutter, remember Minecraft in Java?), servers where tail latency matters a lot, etc.

[bayindirh]

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.

[Imustaskforhelp]

Go is a language which sits perfectly where using garbage collection is no problem with ya.

[7bit]

C++ added OOP to C.

Rust is not object-oriented.

That makes your statement wrong.

[pjmlp]

It certainly is according to the various CS definitions of type systems.

Plenty of OOP architectures can be implemented 1:1 in Rust type system.

[Ygg2]

> Plenty of OOP architectures can be implemented 1:1

Plenty of OOP architecture can be implemented in C. That's an extremely flawed and fuzzy definition. But we've been through this before.

[9rx]

Yes, of course you can call objc_msgSend or equivalent in Rust just as you can in C. But you are pushing the object-oriented model into a library. It is not native to the language.

[9rx]

Objective-C added OOP to C. C++ did not. C++ is neither an OO language nor a C superset.

[CyberDildonics]

If you make up your own definitions things can be anything you want and have or not have any label.

[pjmlp]

Zig is Modula-2/Object Pascal re-packaged with a C like syntax.

[benob]

Time to start zig++

[nindalf]

Zig is what you want to write, because it gets out of the way.

Rust is what you want your colleagues to write, to enforce good practices and minimise bugs. It's also what I want my past self to have written, because that guy is always doing things that make my present life harder.

[9rx]

I'd rather my colleagues (and past self) write Rocq.

Rust is what you use when you'd rather spend time doing sales and marketing for Rust than building software.

[dnautics]

zig really makes it unappealing to architecture astronaut, and rust pushes you towards it. id rather my colleagues write zig

[latch]

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]

> 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]

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.

[cwillu]

You don't use it, but you're offering unsolicited advice about it, and that advice is very generic.

It's not even an argument that you're wrong, just that it's not contributing much and people think that other replies should come first.

[jmull]

Never mind that the previous poster’s insight about caches is correct.

Zig has had caching bugs/issues/limitations that could be worked around by clearing the cache. (Has had, and more that likely still has, and will have.)

[quag]

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]

Just a slower build. From ~20 seconds to ~65 seconds the first time after I nuke it.

[h4ch1]

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]

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]

what exactly people call 'garbage collection' in Zig? build cache cleanup?

[sgt]

Does Zig have incremental builds yet? Or is it 20 secs each time for your build.

[latch]

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]

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]

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.

[wolvesechoes]

> that has resulted in mindshare death as of 2026

I could make a bet that as of 2026 still more C++ projects are being started than Rust + Zig combined.

World is much more vast than ShowHN and GitHub would indicate.

[mcherm]

Being started? I would take that bet.

[pjmlp]

It suffices to use the games industry, HFT and HPC as domains.

[Ygg2]

Pretty sure even games moved to C#.

[fouronnes3]

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]

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.

[tialaramex]

I don't agree there's a great language hiding in C++. My high level objections would be that the type system is garbage and the syntax is terrible, so you'd need a different type system and syntax and that's nothing close to C++ after the changes.

After many years of insisting that "dialects" of C++ are a terrible idea, despite the reality that most C++ users have a specific dialect they use - Bjarne Stroustrup has endorsed essentially the same thing but as "profiles" to address safety issues. So for people who think there is a "great language" in there perhaps in C++ 29 or C++ 32 you will be able to find out for yourselves that you're wrong.

[ChrisGreenHeur]

There are multiple great languages hiding within it

[pjmlp]

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]

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]

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

[the_duke]

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.

[melodyogonna]

Rust started in 2006 and reached v1 in 2015, that's 9 years.

[kibwen]

Rust existed nearly entirely on paper until 2009, when Mozilla started funding researchers to work on it full-time. It wasn't announced in any sort of official capacity until 2010, and had no official numbered release until 2012. It was less than three and a half years between 0.1 and 1.0, and in that time, hard as it is to believe, it underwent more overall change than Zig has.

[pjmlp]

There is a reason GCC, LLVM, CUDA, Metal, HPC,.. rely on C++ and will never rewrite to something else, including Zig.

[surajrmal]

Yes, inertia. If those projects started today, they would likely choose rust.

[pjmlp]

Why isn't rustc using Cranelift then?

[norman784]

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]

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.

[nindalf]

Same reason Android and Chrome and git and Linux weren't written in Rust when they started. Rust didn't exist. All of these projects integrate Rust now, after being single language projects for the longest time.

It's notable that the projects you mentioned mostly don't need to deal with adversarial user input, while the projects I mentioned do. That's one area that Rust shines in.

[pjmlp]

Rust presence in Android is minimal, and not officially supported for userspace.

Android team is quite clear that Java, Kotlin, C and C++ are the official languages for app developers.

Chrome even has less Rust than Firefox.

Linux has some baby adoption, and it isn't without drama, even with Microsoft and Google pushing for it.

[flohofwoe]

Looking at LLVM build times I seriously believe that C would have been the better choice :/ (it wouldn't be a problem if LLVM wouldn't be the base for so many other projects)

Same for the Metal shading language. C++ adds exactly nothing useful to a shading language over a C dialect that's extended with vector and matrix math types (at least they didn't pick ObjC or Swift though).

[pjmlp]

CUDA, SYSCL, HLSL evolution roadmap, and Khronos future for Vulkan beg to differ with your opinion.

[flohofwoe]

> HLSL evolution roadmap

...that's just because of the traditional-game-dev Stockholm syndrome towards C++ (but not too much C++ please!).

> Khronos future for Vulkan

As far as I'm aware Khronos is not planning to move the Vulkan API to C++ - and the 'modern C++' sample code which adds a C++ RAII wrapper on top of the Vulkan C API does more harm than good (especially since lifetime management for Vulkan object is a bit more involved than just adding a class wrapper with a destructor).

[pjmlp]

See the talks around Vulkan ecosystem, and GPU shading languages from February.

There is more than one sample using C++, now they make use of C++20, including modules if desired.

[whobre]

The forever backwards compatible promise of C++ is pretty much the main reason anyone is using C++.

[quotemstr]

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.

[ChrisGreenHeur]

those that used it were rightly punished by the removal

[scuff3d]

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.

[hansvm]

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.

[MrResearcher]

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.

[Cloudef]

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]

Using third party packages has gotten a lot easier with the changes described in this devlog https://ziglang.org/devlog/2026/#2026-02-06

[Escapade5160]

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]

0.16 is the development version. 0.15.2 is latest release.

[boomlinde]

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.

[steeve]

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

[sgt]

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

Just a degree of success?

[ptrwis]

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

[throwaway27448]

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]

Bun is a full fledged JavaScript runtime! Think node.js but fast

[throwaway27448]

> Think node.js but fast

Color me extremely sceptical. Surely if you could make javascript fast google would have tried a decade ago....

[leonflexo]

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]

> 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]

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.

[messe]

> Surely nobody would use javascript for either yea?

It's probably the most popular language for serverless.

[dtj1123]

Claude CLI is based on bun. The dependency is so complete that Bun have now joined Anthropic.

[rererereferred]

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]

they have, v8 is a pretty fast engine and an engineering marvel. bun is faster at cost of having worse jit and less correctness