kristoff_it

In the Zig core team we have the right to decide how we want to conduct the development of our open source project, and that decision is based in good part on the same factors presented in this post, which are significantly more important than validating your FOMO.

Likewise, in your projects you can do whatever you want. That was true before LLMs and is just as true now. Thinking otherwise is a weird form of open source kleptomania induced by listening to too many techfluencers, in my opinion :^)

In my open source projects I decide which tasks I'm willing to delegate and which tasks I want to take on myself and, of those that I'm willing to delegate, I decide who gets to take on them. This includes the fact that, even if the quickest way to get something done is to delegate it to an LLM, if I want to do it myself for personal growth, I will still do it myself.

Conversely, it should go without saying that if I want to use LLMs, that's my right and whoever wants to complain can go fork (the repo) themselves.

(reposting my comment from lobsters)

For anybody reading, the project tracks new Zig to get all the new async I/O goodies but was hit by some regressions in Zig's translate-c because it recently became fully independent from LLVM.

Other contributors and I took this as an opportunity to contribute some fixes to translate-c and in my case I also switched for a bit to my other projects, mainly https://zine-ssg.io, which I had neglected for a few months while going all-in on awebo.

I plan to resume development of awebo in a month or two, I just want to leave Zine in a good spot before switching again (I have a bad time paging between different projects too often and prefer doing continuous work for a while before switching back).

Yes it was never attempted, the whole communication on social media about the AI policy was completely detached from the reality of the engineering work being done on either side.

The people who originally worked on Bun themselves would disagree with your point (but their situation was based on the premise that they did not take the steps required to leverage incremental compilation): https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...

And, unrelated to Bun, I too would disagree. You don't want to have to wait minutes for a build to complete before you can run the test suite, or even just know if there was a semantic error in your code. Build times are 100% a bottle neck for big-enough projects.

To me the most interesting fact about this fork is that it has proven that Bun could have had fast builds all along.

To be fair, there are caveats still in place today: Zig incremental compilation does not yet support aarch64 and only the linux linker supports binary patching, but it's just a matter of time before all major platforms are conquered.

That is a 100% on point analysis, there was a lot of hype around Bun since the beginning when it was an invite only project. Arguably that same interest is what got Jarred VC funding in the first place.

Note that usage and public interest are not the same quantity, people also care about the potential of a project.

> Writing memory safe code in unsafe languages requires global reasoning

If you learn how to use arena allocators and in general use modern techniques, you don't need global reasoning to write correct memory management code pretty much never.

If your code is a RAII and abstraction maze, then yes, you will probably need global reasoning, but that's not the case with Zig.

Thanks, yeah Andrew gave a pretty good interview to the JetBrains people recently https://www.youtube.com/watch?v=iqddnwKF8HQ

I think you will be surprised by how many developers do not have this same list of priorities (or in that order) when developing software.

I posted this link at the same time when I posted it to Lobsters (https://lobste.rs/s/g6lkw1/my_software_north_star) 3 days ago, but it didn't get on the front page. Seeing that the submission time has been reset, I imagine it was given a second chance by HN curators (it's a known process), but that doesn't mean free upvotes, it's just that some people resonate with the thinking.

The truth is a bit of everything, bun being a messy codebase written primarily with "move fast and break things" in mind, cultural divergence between Bun and the Zig community, and also hiring issues. People maybe forgot but Jarred at some point caused a bunch of drama when he tweeted that working at Bun is not for people that value life/work balance, which went viral and caused an uproar. Must not have been super easy to hire from the Zig community after that, and in fact once Bun got acquired by Anthropic, it was pretty much Jarred and Claude doing all the work on the codebase. Pivoting to Rust is probably at least in part a way to reset the clock on those hiring interactions.

> I imagine it's a difficult time to be a Zig developer.

In some ways it always has been, the community was 'born' in the middle of the pandemic, then for a long time there was a constant influx of Rust zealots coming into threads about Zig to remark how immoral it is to use Zig, and now LLM shovel sellers are telling everybody that the only way forward is to become efficient at consuming tokens.

But it's actually not that bad.

The Zig community is growing pretty well, useful software is being written in Zig, and the advantages that Zig brings are still valid whether you hand-code or use LLMs (e.g. cross-compilation of C/C++ code).

That is correct, this blog post is about understanding the priority of various subgoals and the ultimate goal (creating useful software). Memory-safety is important but overfitting on that subgoal, as I believe the memory-safety blog post is doing, won't make you create better software.

If Rust helps you get all the way to correctness, then great, but that blog post was insane.

trying to make good software :^)

That is the opposite of what's going on, read this https://kristoff.it/blog/contributor-poker-and-ai/

The problem statement is clear to everybody.

> For decades, code contributions have been how open source projects learned who to trust. People would show up, do the work, take responsibility for their changes, and stick around. Over time, trust emerged from the work itself.

The solution, IMO, is a strictly worse version than what we chose in the Zig project (banning LLM contributions).

> AI tools have changed the economics of this very quickly. We use them ourselves every day, but a pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds.

Things that worry me about this choice:

- open source is a tough business and you need to leverage the good things about it to make it worth doing. contributors bring in a huge amount of value that they offer you essentially for free (see contributor poker: https://kristoff.it/blog/contributor-poker-and-ai/), on top of being a hugely valuable recruitment funnel. They're rejecting all of that, which seems insane to me.

- one could argue that LLMs could fill that gap but, first of all they could have just banned LLM usage only in PRs from untrusted contributors, and second even the best LLM: 1. is a cost, not just free value, and the price of tokens is increasing 2. the code has to be reviewed anyway, unless you think that just passing tests is good enough for a browser 3. ultimately can't become a trusted core contributor able of taking ownership of a part of the codebase

- removing the influx of code that comes from PRs means that over time the whole project will have a small number of contributors that own all the code, making it easier for the project to do a license rugpull. when copyright ownership is well distributed this kind of thing is harder to pull off.

Overall, this is not good in my opinion. They're making open source a more problematic business model for them than it has to be, while at the same time making it harder to recruit more core contributors, as the code ownership coalesces to small group of people.

This is an obvious recipe for disaster (a rugpull), and I'm forced to wonder if this is just by mistake or if some of the Ladybird sponsors are playing a mean game of Secret Hitler. I guess only time will tell.

Another Zig GUI project that people might be interested in is DVUI:

https://github.com/david-vanderson/dvui

It's not Future.await that is special per se, it's that it (Future.await) will have in it somewhere either in its body or in another function that it calls in turn, a use of `suspend` (using old Zig syntax).

`suspend` is the keyword that best fits your description (you can think of it as being closely related to `yield` in other languages), and it's kind of a lower-level primitive compared to async/await.

This also means that, according to our plans, Zig will have to propagate "stackless-ness" upwards in the call chain while analyzing the code (thus making Future.await not special per-se).

None of it, we've been working on this stuff for a long time already, scroll the devlog backwards, you will find plenty of entries on that topic.

It's the opposite: people have become more receptive to communication about this work now that there's "drama" attached to it.

This post I co-authored with Andrew is from 2020. In it we announce the idea of getting rid of LLVM from the debug build pipeline and since then work has been steadily going forward, it's just not trivial to bootstrap a full compiler pipeline for all major targets, but we're finally getting there.

https://kristoff.it/blog/zig-new-relationship-llvm/

> If so, does that mean that every function in zig is a stackless coroutine?

No and yes.

If you're using Io.Threaded, then the concurrency model is multithreading and calling Future.await will block your thread on a OS futex.

If you're using Io.Evented, then the concurrency model is green threads / fibers and calling Future.await will suspend the current green thread by yielding (swapping CPU state with another fiber).

Zig currently does not support stackless coroutines so today you can't have that, but we used to have them (pre self-hosted compiler), and there's an accepted proposal to bring them back, in which case any function that calls await, or that otherwise has a suspension point, would have to be transformed into a stackless coroutine by the compiler, yes. The plan is for that to happen transparently without requiring an `async` annotation in the function signature, like we already did in the past.

This is an old post of mine that explains how that worked at a high level: https://kristoff.it/blog/zig-colorblind-async-await/

A vtable indirection is essentially free when you're going to perform a syscall. What matters is that the buffer is above the vtable (which is already the case for the current implementation) so that you don't pay for the indirection when hitting the buffer.

> You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed.

I think that's a neat idea, but in the reverse: do as much as you can in the lower level language, and only go up to the high level language when the convenience is worth the cost.

Roc allows this: every program has a platform written in a low-level language, and then the Roc program uses the API that the platform exposes.

https://www.roc-lang.org/

Then how you want to balance high vs low is of course up to you :^)

Bun has de-facto refused to use incremental compilation in Zig for ages. It got to the point where Jarred somehow seems to have forgotten that the feature exists.

In any case Bun has already committed to the Rust slop switch, so it doesn't matter anymore.

The whole reason for this blog post is because discussion about LLMs does happen already (to the point of being a bit suffocating).

see also https://news.ycombinator.com/item?id=48314145

That doesn't mean anything in the context of a Zig Day. People will come to the event full of new experiences to talk about that relate to LLMs and also with some worries about the future of their profession, wich also will relate to LLMs a lot.

Not only these are generally reasonable things for a human to want to talk about, but what is happening in the tech industry is definitely on topic for an event like Zig Days.

The problem is when this consumes nearly 100% of the communication bandwidth detracting from the main goals of the event (applying systems thinking & making software you can love).

The no-AI policy of the Zig compiler project is for the compiler, other projects can do whatever they want.

Bun's fork of Zig was just an unsound hack that at best would have produced a strictly inferior speedup compared to our current work with incremental compilation, which is already plenty usable:

- June 2025 core team starts using it with the zig compiler itself https://ziglang.org/devlog/2025/#2025-06-14

- April 2026 https://ziglang.org/devlog/2026/#2026-04-08

> Zig's AI stance is ridiculous & politically-motivated

It's literally an issue with our business model to mess with our contributor pipeline, can't get more concrete than this.

https://kristoff.it/blog/contributor-poker-and-ai/

Zig has been doing fine before Bun and will be fine also after.

I'm personally thankful to Jarred & Bun for supporting Zig Software Foundation financially before they got acquired by Anthropic, but the reality of interacting with individuals in the Zig community is that the people who actually show up to Zig events and who do have compelling open source projects are almost never people who were interested in Zig because of Bun.

Bun did give us a bunch of visibility, but most of it was superficial interest.

Understandably, Bun is a JS runtime and so the people who discovered Zig that way were likely interested in doing webdev, and Zig is just now polishing the I/O implementation, so it doesn't have yet a particularly compelling web development experience to offer.

Bun has stopped donating to the ZSF after the Anthropic acquisition.

You might be interested in learning more about `-fincremental`, that's how Zig gives you fast rebuilds.

Code origin was not even a factor https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Our announcement had plenty of examples of service degradation as well. People just become blind to all reason when somebody touches one of their political pet peeves (which sometimes might even be just referencing politics in the first place).