Latest posts

Zig keeps improving as a programming language. Unfortunately, its management increasingly seems determined to make it a bad choice for the people who actually want to use it.

Zig is a fascinating programming language. Its design contains genuinely good ideas, its technical ambitions are impressive, and it has attracted talented developers who have spent years building a serious systems programming toolchain. And despite all that, it's becoming increasingly hard to recommend it.

The problem is that Zig appears to be poorly managed.

Over the past year, the project has made a series of decisions that individually might seem like ordinary disagreements about open-source development, while together revealing a deeply concerning pattern.

The language continues to break compatibility without a concrete commitment to stability. Its contribution policy excludes otherwise legitimate engineering workflows. One of its most prominent users abandoned the language, only to be met with public hostility. And its move away from GitHub replaced a mature development platform with a smaller, less proven service beset with reliability issues, whose operators increasingly impose their own philosophical preferences on hosted projects.

The recurring theme is that Zig's maintainers appear more interested in enforcing their vision of how software should be developed than making Zig a practical tool for people who want to build software. And that is a serious problem for a programming language.

Zig is perpetually unfinished, and its users pay the price

Zig has been under development for more than a decade. It remains at version 0.x, without a firm date for a stable 1.0 release.

There is nothing inherently wrong with a long development cycle or a version number below 1.0. Plenty of useful software operates under so-called 0ver. esbuild is one prominent example of rock-solid, uncompromising quality and little breakage despite its major version remaining at 0.

But Zig is a programming language, not a bundler.

A programming language is infrastructure. Developers write applications and libraries against its syntax, standard library, compiler, and build tooling, and those interfaces determine how much of the surrounding ecosystem remains usable from one release to the next. In Zig, they seem to be forever changing, with the authors nigh-obsessed about breakage.

Consider the 0.15.1 release notes, with substantial changes to the I/O interfaces and standard library, including the lovingly named ‘Writergate’. It's amusing enough if you're writing the compiler, presumably less if you're the one whose code no longer compiles. Version 0.16 continued the transition, and 0.17.0, released in October 2026, brought further changes to the language and its tooling. It almost appears as though the Zig maintainers enjoy breaking compatibility; if not, they certainly seem comfortable with it.

Thus upgrading Zig is often not just a matter of installing a new compiler. It frequently means rewriting substantial parts of existing code, updating dependencies, and waiting for tools and libraries to catch up. The fact that Zig openly documents these changes doesn't lessen the burden.

Some of these changes may or may not improve the design; but that's beside the point. Every change also creates work for everyone who has already built something on top of the language. And after more than ten years, it's more than reasonable to ask when this stops and we can start getting serious about writing Zig code¹.

The maintainers have a roadmap to 1.0, but that gives developers no meaningful indication of when they can expect the interfaces they depend on to stop changing. It may well take another decade.

That leaves them with a choice: freeze their projects on old compiler versions or repeatedly spend engineering effort keeping up with upstream. When a project offers you two bad choices, you know something isn’t going well.

A programming language cannot remain a perpetual experiment without consequences. At some point experimentation stops being a benefit and starts becoming a burden on everyone using the language. At this stage, we are way past that point.

Zig's instability isn't merely an inconvenience. It is one of the central reasons the language remains difficult to depend on.

And it makes the maintainers' attitude toward contributors considerably harder to defend.

A project that wants to teach you a lesson instead of accepting your code

Zig has an exceptionally restrictive AI contribution policy.

No AI-generated code. No AI-assisted editing. No AI-assisted translation. No brainstorming with an LLM and then sharing the result. Not even using an LLM to find bugs. Really?

There's an obvious difference between dumping a thousand lines of unreviewed AI slop into a pull request and using an assistant to understand an unfamiliar part of the compiler, possibly find a bug, or help implement a fix. And Zig's policy makes remarkably little effort to distinguish between the two.

In Contributor Poker and Zig's AI Ban, the maintainers explain their philosophy. They want to invest in contributors who will develop a deep understanding of Zig and remain involved over time. Reviewing low-quality pull requests is expensive, and AI has allegedly made that problem worse.

Fair enough. Nobody wants to review garbage. But then comes the revealing part:

"You play the person, not the cards."

The article argues that investing in the right contributor matters more than the contents of their first pull request. It even acknowledges that competent AI-assisted contributors exist, but considers them an unattractive bet compared with people who don't use these tools.

Let’s consider what that means: A useful contribution can (and indeed must, in the case of Zig) be rejected not because it's incorrect, poorly tested, or unmaintainable, but because its author used the wrong tools to produce it. The project is no longer judging only the contribution. It's judging the contributor's development process. Merit alone is no longer enough.

And apparently, contributors are expected to become deeply familiar with Zig's internals to earn the privilege of fixing something. Why?

Not everyone wants to become a compiler engineer. Some people encounter a bug while trying to build their own software and would simply like to fix it. That's a perfectly legitimate contribution whether you intend to work on Zig for the next ten years or never touch it again.

The really absurd part is how this attitude clashes with Zig's permanent instability. The language, the standard library, the build system constantly change. Developers have to learn the new interfaces, migrate their projects, update their dependencies, and then repeat the exercise when the next release arrives.

And while imposing this continuous relearning exercise, Zig's maintainers have decided that certain tools which might make it easier are unacceptable.

You must understand the language. You are to keep up with its changes. You must learn the internals. And you'd better do it the approved way. At what point does maintaining your Zig code stop being software development and start becoming homework assigned by the Zig project?

And how does this live up to Zig's own promise to ‘focus on debugging your application rather than debugging your programming language knowledge’?

I originally got interested in Zig precisely because of that promise. Whenever I looked at Rust code, I felt like I needed a PhD to get it. Zig was straightforward and easy to understand. That was long before they fell in love with breaking for the sake of breaking.

Most developers don't use programming languages because they want an ongoing educational relationship with the compiler's maintainers. They just want to get stuff done, with the right tools.

It's perfectly reasonable to demand that contributors understand and stand behind their work. It's far less reasonable to dictate and prescribe how they acquire that understanding. A compiler improvement doesn't become worthless because an LLM helped produce it. Rejecting useful work on that basis is not technical rigor.

It's dogma.

Bun left Zig. And Zig's response was embarrassing.

For years, Bun was practically free advertising for Zig. A high-performance JavaScript runtime, written in Zig, attracting significant adoption and showing that the language could be used for serious production software. Bun held up the Zig banner proudly. Bun was treating Zig as major 1 even as Zig slipped further and further into the abyss of eternal breakage.

Then, in July 2026, Bun announced that it had rewritten its Zig codebase in Rust.

Bun had legitimate technical reasons. Its team described recurring memory-safety problems, particularly around the interaction between JavaScript's garbage collector and Zig's manual memory management. Rust's ownership system offered guarantees that were valuable for Bun's workload.

To this end, Bun had also been maintaining its own modifications to the Zig compiler, with upstream contribution friction adding to the maintenance burden. This should have been alarming to the Zig project, though it fell on deaf ears.

One of its most prominent users, with significant engineering resources and years of investment in the language, had concluded that continuing with Zig wasn't worth it. And well, fair: not everyone must choose Zig, nor commit to it in perpetuity. But when a major user walks away, perhaps it's worth asking why, or in this case simply read the reasoning. Instead, the project responded with a spectacularly caustic public attack.

In a lengthy response to Bun's rewrite, Zig's leadership went well beyond disagreeing with Bun's technical arguments. The post criticized Bun's engineering practices, management, development culture, and business decisions. It described the foundation as relieved that the relationship was over and treated Bun as a liability (a term the Zig project seems particularly fond of when justifying its caprices). And all this in response to a project that had spent years using Zig, publicly promoting it, contributing to its ecosystem, and donating substantial amounts of money to its development.

Bun's announcement was broadly appreciative of Zig. Zig's response was anything but. The post was later revised and acknowledged resentment in its earlier framing. That's something, but it doesn't undo the damage that reveals immaturity and a severe lack of understanding on the part of the project maintainers of the dynamics of software development.

A programming language does not own its users.

Bun was under no obligation to keep using Zig simply because the maintainers believed in its design. It wasn't obligated to develop software according to Zig's preferred engineering culture, either. If its needs were better served by Rust, that's Bun’s decision. It didn’t even need to justify itself, but the fact it did showed grace towards Zig and maturity towards its own users, two qualities the Zig project seems severely lacking in.

And if Zig's maintainers disagreed with Bun's technical reasoning, they could have made that argument without turning it into a public dispute about the people and culture behind Bun.

This sends a particularly concerning message to everyone else. If a project as prominent as Bun gets this kind of treatment on the way out, what should smaller projects expect when they criticize Zig or decide to move on? This is a far cry from how you build confidence in a programming language. In fact, it's precisely how you make people reluctant to depend on it. Nothing inspires confidence in a project's governance quite like watching it throw a public tantrum because one of its users decided to leave.

Bun's migration alone doesn't prove Zig is a bad language.

But the way Zig handled losing Bun says plenty about the project's management.

Codeberg was a terrible choice

In November 2025, Zig announced its migration from GitHub to Codeberg.

In and of itself, leaving GitHub isn't the problem. GitHub has plenty of problems of its own, and Zig's complaints about GitHub Actions were legitimate reasons to consider alternatives. The problem is where Zig went instead.

Codeberg is a small nonprofit Git hosting service. It's also, in my experience, frustratingly unreliable. I've repeatedly encountered connection issues or found it unavailable when I needed it.

And I'm far from the only one complaining.

When someone suggested moving CachyOS from GitHub to Codeberg, a participant in the CachyOS forum discussion responded:

"Codeberg frankly is notoriously unstable and tends to have connection issues often."

Other participants raised much the same concern, with one arguing that Codeberg hadn't yet matured enough to be relied on as a serious GitHub replacement.

These are merely anecdotal user reports. But they match my experience, and reliability isn't some obscure feature that only matters to unusually demanding users. It's the bare minimum for a development platform.

Zig didn't need to stay on GitHub. It could have chosen GitLab, evaluated other established hosting providers, or run its own Forgejo instance. It might have the technical knowledge to do so, but it evidently preferred not to take on that work. Self-hosting comes with work, obviously. But if controlling your own infrastructure is so important, perhaps that is the kind of work worth doing.

Instead, Zig moved critical development infrastructure to a provider with questionable reliability and tried to sell it as progress. And the reliability concerns aren't even the worst part.

In July 2026, Codeberg published "Protecting our FLOSS commons from LLMs," explaining its decision to restrict certain categories of AI-heavy projects.

Codeberg has every right to manage its resources, prevent abuse, and protect itself from automated crawlers. But the announcement doesn't stop there. It makes sweeping judgments about the legitimacy of LLM-based development itself. Its operators explicitly argue that LLMs are incompatible with responsible open-source software development, and its policies may exclude projects on the basis of how their code was produced.

That's a pretty extraordinary direction for a Git hosting provider. As another developer puts it in "I Regret Migrating to Codeberg," the concern isn't just which projects are currently restricted. It's that the hosting provider has taken it upon itself to decide which otherwise legitimate forms of software development belong on its platform.

You don't have to like AI to see the problem here. Codeberg calls itself a home for free and open-source software, yet increasingly seems interested in deciding which kinds of software development deserve to be welcome. Apparently the commons is only common so long as everyone agrees on how to use it.

A Git forge should host code, manage issues, and facilitate collaboration. It should enforce sensible limits and prevent abuse. It shouldn't need to pass judgment on whether a project's development philosophy is sufficiently virtuous.

Codeberg's announcement came after Zig's migration, so it doesn't establish what the maintainers knew at the time. But it certainly doesn't make their choice look any better in hindsight.

Zig traded GitHub's problems for a different set of problems, with worse reliability in my experience and a hosting provider increasingly concerned with policing how software ought to be written.

And because the project's own policies align with that philosophy, I find it hard to believe practical considerations were the only reason for the choice.

Apparently even donations can be the wrong kind

The GitHub migration announcement also contained a particularly strange passage about GitHub Sponsors.

After acknowledging how important the platform had been to Zig's fundraising, the maintainers wrote:

"Although GitHub Sponsors is a large fraction of Zig Software Foundation’s donation income, we consider it a liability."

They then asked supporters to move their recurring donations to Every.org and announced the retirement of GitHub Sponsors perks. Again I must ask, why?

Zig is funded substantially through donations. People voluntarily give the project money so that its developers can keep working on the language. And now one of the platforms through which people have been supporting it is apparently a liability? Yesterday an asset, today a liability?

Granted, relying on a third-party platform carries risks. GitHub Sponsors could change its terms tomorrow. But that's a reason to diversify your fundraising, not discard an existing channel. Why not leave the repository on GitHub as a read-only mirror and keep accepting donations there?

Why should people who are already supporting Zig have to change their payment arrangements just because the maintainers no longer like GitHub? The actual development could happen entirely on Codeberg. Nobody would have to use GitHub for issues, pull requests, or CI. And the people who prefer GitHub Sponsors could continue donating through it.

Perhaps there were administrative reasons for wanting to consolidate fundraising elsewhere. But the announcement doesn't establish why keeping both channels was unacceptable. The maintainers did thank their existing supporters, and they weren't literally refusing donations. But I still find the message remarkably tone-deaf.

When your project relies on voluntary contributions, making it less convenient for people to support you should require a better explanation than disliking the platform they happen to use.

It's one thing to refuse to depend on GitHub for development. It's another to turn that preference into unnecessary friction for people who are trying to give you money.

Once again, everyone else is expected to accommodate Zig's principles.

Going nowhere

Zig isn't dead. Development continues, and the compiler keeps getting better.

But technical progress isn't the same thing as maturity. What good is an increasingly sophisticated programming language if using it remains an exercise in keeping up with breaking changes and the whims of project management?

Look at the pattern. Users are expected to keep up with an unstable language. Contributors are expected to work the approved way. A prominent downstream user decides Rust fits better, and the project publicly lashes out. The hosting platform changes, and donors are asked to move along with it.

Zig's maintainers expect everyone else to adapt to the project while showing surprisingly little willingness to adapt the project to everyone else.

Undoubtedly they have the right to run Zig however they want. Open source doesn't mean maintainers owe everyone unlimited support, free code review, or eternal backward compatibility. But the reverse is equally true: users don't owe maintainers their time, loyalty, or agreement with their philosophy.

A developer wants to write software, not spend countless hours migrating standard-library APIs. A contributor might want to fix a bug, not prove allegiance to a sanctioned school of engineering. A company wants a language that solves its problems, not a lecture about how to run its business. And a donor wants to support a project, not get embroiled in its dispute with GitHub.

Good project management means making compromises. Sometimes that means putting stability ahead of another elegant redesign. Sometimes it means accepting a useful patch from someone who doesn't share your preferred development ideology. Sometimes it means swallowing your pride when a major user moves on. And sometimes it means choosing boring, reliable infrastructure instead of making a philosophical statement.

Zig seems determined to do anything but that.

None of this is inevitable. Zig could keep its technical ambitions while becoming a much more dependable language and a much easier project to work with. But that would require its maintainers to start treating users' needs as something more than an inconvenience to be managed.

The project can keep refining its language design forever. It can keep insisting on its own idea of good engineering, rejecting the wrong kinds of contributions, and choosing platforms that align with its worldview.

But at some point, it needs to decide whether it wants to build a programming language people can use or an ongoing experiment in how its maintainers think software should be developed.

Zig has spent more than a decade figuring out what its maintainers want the language to be. Perhaps it's time they started caring a little more about what its users need it to be.

Until then, the Zig project is going nowhere.

---