Zig keeps improving as a programming language. Unfortunately, its administration increasingly seems resolute to create it a bad choice for the group who really desire to use it.
Zig is a fascinating programming language. Its scheme contains genuinely fine ideas, its specialized ambitions are impressive, and it has attracted gifted developers who have spent years construction a grave systems programming toolchain. And notwithstanding all that, it's becoming increasingly difficult to propose it.
The issue is that Zig appears to be poorly managed.
Over the former year, the project has made a sequence of decisions that individually power appear akin average disagreements concerning open-source development, during together revealing a deeply concerning pattern.
The tongue continues to interrupt compatibility without a tangible dedication to stability. Its contribution guideline excludes alternatively lawful engineering workflows. One of its most notable users abandoned the language, lone to be met alongside community hostility. And its move distant from GitHub replaced a mature betterment phase alongside a smaller, small proven assistance beset alongside reliability issues, whose operators increasingly enforce their own philosophical preferences on hosted projects.
The recurring theme is that Zig's maintainers appear additional curious in enforcing their imagination of how application have to be developed than making Zig a applicable tool for group who desire to build software. And that is a grave issue for a programming language.
Zig is constantly unfinished, and its users pay the price
Zig has been under betterment for additional than a decade. It remains at type 0.x, without a resolute date for a stable 1.0 release.
There is nothing inherently incorrect alongside a lengthy betterment sequence or a type figure below 1.0. Plenty of helpful application operates under so-called 0ver. esbuild is one notable example of rock-solid, uncompromising norm and small breakage notwithstanding its important type remaining at 0.
But Zig is a programming language, not a bundler.
A programming tongue is infrastructure. Developers compose applications and libraries against its syntax, norm library, compiler, and build tooling, and those interfaces decide how much of the surrounding ecosystem remains usable from one publish to the next. In Zig, they appear to be everlastingly changing, alongside the authors nigh-obsessed concerning breakage.
Consider the 0.15.1 publish notes, alongside significant changes to the I/O interfaces and norm library, including the lovingly named ‘Writergate’. It's amusing adequate if you're penning the compiler, presumably small 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 additional changes to the tongue and its tooling. It nearly appears as although the Zig maintainers enjoy breaking compatibility; if not, they certainly appear comfortable alongside it.
Thus upgrading Zig is frequently not fair a matter of installing a new compiler. It frequently method rewriting significant parts of existing code, updating dependencies, and waiting for tools and libraries to capture up. The fact that Zig openly documents these changes doesn't lessen the burden.
Some of these changes may or may not enhance the design; but that's beside the point. Every alter additionally creates activity for everyone who has already built item on top of the language. And following additional than ten years, it's additional than sensible to ask whenever this stops and we can commencement getting grave concerning penning Zig code1.
The maintainers have a roadmap to 1.0, but that gives developers no meaningful sign of whenever they can anticipate the interfaces they depend on to halt changing. It may fine obtain another decade.
That leaves them alongside a choice: freeze their projects on old compiler versions or often expend engineering attempt keeping up alongside upstream. When a project offers you two bad choices, you cognize item isn’t going well.
A programming tongue cannot remain a perpetual test without consequences. At several item experimentation stops being a advantage and starts becoming a burden on everyone using the language. At this stage, we are way former that point.
Zig's instability isn't merely an inconvenience. It is among the chief reasons the tongue remains difficult to depend on.
And it makes the maintainers' outlook toward contributors considerably harder to defend.
A project that wants to instruct you a instruction alternatively 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 alongside an LLM and afterward sharing the result. Not equal using an LLM to discover bugs. Really?
There's an apparent difference between dumping a thousand lines of unreviewed AI slop into a drag petition and using an aide to comprehend an unfamiliar part of the compiler, perchance discover a bug, or assistance execute a fix. And Zig's guideline makes remarkably small attempt to differentiate between the two.
In Contributor Poker and Zig's AI Ban, the maintainers explain their philosophy. They desire to allocate in contributors who volition create a profound understanding of Zig and remain engaged complete time. Reviewing low-quality drag requests is expensive, and AI has allegedly made that issue worse.
Fair enough. Nobody wants to assessment garbage. But afterward comes the revealing part:
"You perform the person, not the cards."
The part argues that investing in the correct contributor matters additional than the contents of their archetypal drag request. It equal acknowledges that capable AI-assisted contributors exist, but considers them an unattractive bet compared alongside group who don't use these tools.
Let’s regard what that means: A helpful contribution can (and certainly must, in the case of Zig) be rejected not since it's incorrect, poorly tested, or unmaintainable, but since its author used the incorrect tools to create it. The project is no longer judging lone the contribution. It's judging the contributor's betterment process. Merit solitary is no longer enough.
And apparently, contributors are expected to rotate into deeply acquainted alongside Zig's internals to acquire the privilege of fixing something. Why?
Not everyone wants to rotate into a compiler engineer. Some group encounter a bug during trying to build their own application and would merely akin to fix it. That's a absolutely lawful contribution whether you average to activity on Zig for the next ten years or never contact it again.
The really ridiculous part is how this outlook clashes alongside Zig's imperishable instability. The language, the norm library, the build scheme continually change. Developers have to study the new interfaces, migrate their projects, update their dependencies, and afterward reiterate the exercise whenever the next publish arrives.
And during imposing this uninterrupted relearning exercise, Zig's maintainers have decided that certain tools which power create it easier are unacceptable.
You must comprehend the language. You are to keep up alongside its changes. You must study the internals. And you'd improved do it the approved way. At what item does maintaining your Zig code commencement being application betterment and halt becoming homework assigned by the Zig project?
And how does this live up to Zig's own promise to ‘focus on debugging your use fairly than debugging your programming tongue knowledge’?
I initially got curious in Zig exactly since of that promise. Whenever I looked at Rust code, I felt akin I needed a PhD to get it. Zig was straightforward and uncomplicated to understand. That was long before they cut in affection alongside breaking for the purpose of breaking.
Most developers don't use programming languages since they desire an ongoing instructional association alongside the compiler's maintainers. They fair desire to get material done, alongside the correct tools.
It's absolutely sensible to petition that contributors comprehend and remain rearward their work. It's far small sensible to dictate and prescribe how they get that understanding. A compiler betterment doesn't rotate into worthless since an LLM helped create it. Rejecting helpful activity on that basis is not specialized rigor.
It's dogma.
Bun remaining Zig. And Zig's reply was embarrassing.
For years, Bun was practically liberated promotion for Zig. A high-performance JavaScript runtime, written in Zig, attracting important acceptance and showing that the tongue could be used for grave manufacturing software. Bun held up the Zig banner proudly. Bun was treating Zig as important 1 even as Zig slipped additional and additional into the abyss of eternal breakage.
Then, in July 2026, Bun announced that it had rewritten its Zig codebase in Rust.
Bun had lawful specialized reasons. Its squad described recurring memory-safety problems, particularly about the communication between JavaScript's refuse collector and Zig's manual recollection management. Rust's ownership scheme offered guarantees that were precious for Bun's workload.
To this end, Bun had additionally been maintaining its own modifications to the Zig compiler, alongside upstream contribution conflict adding to the care burden. This should have been alarming to the Zig project, although it cut on deaf ears.
One of its most notable users, alongside important engineering resources and years of funding in the language, had concluded that continuing alongside Zig wasn't value it. And well, fair: not everyone must choose Zig, nor commit to it in perpetuity. But whenever a important person walks away, perchance it's value asking why, or in this case merely peruse the reasoning. Instead, the project responded alongside a spectacularly caustic community attack.
In a lengthy reply to Bun's rewrite, Zig's guidance went fine beyond disagreeing alongside Bun's specialized arguments. The article criticized Bun's engineering practices, management, betterment culture, and endeavor decisions. It described the basis as relieved that the association was complete and treated Bun as a liability (a term the Zig project seems particularly eager whenever justifying its caprices). And all this in reply to a project that had spent years using Zig, publically promoting it, contributing to its ecosystem, and donating significant amounts of prosperity to its development.
Bun's notice was broadly appreciative of Zig. Zig's reply was item but appreciative. The article was afterward revised and acknowledged resentment in its before framing. That's something, but it doesn't undo the damage that reveals immaturity and a serious deficiency of understanding on the part of the project maintainers of the dynamics of application development.
A programming tongue does not own its users.
Bun was under no duty to keep using Zig merely since the maintainers believed in its design. It wasn't obligated to create application according to Zig's preferred engineering culture, either. If its needs were improved served by Rust, that's Bun’s decision. It didn’t equal need to validate itself, but the fact it did showed grace towards Zig and maturity towards its own users, two qualities the Zig project seems seriously lacking in.
And if Zig's maintainers disagreed alongside Bun's specialized reasoning, they could have made that disagreement without turning it into a community disagreement concerning the group and civilization rearward Bun.
This sends a particularly concerning communication to everyone else. If a project as notable as Bun gets this benevolent of care on the way out, what should smaller projects anticipate whenever they condemn Zig or decide to move on? This is a far cry from how you build confidence in a programming language. In fact, it's exactly how you create group reluctant to depend on it. Nothing inspires confidence in a project's governance fairly akin observing it throw a community outburst since one of its users decided to leave.
Bun's immigration solitary doesn't demonstrate Zig is a bad language.
But the way Zig handled losing Bun says plentifulness concerning the project's management.
Codeberg was a awful choice
In November 2025, Zig announced its immigration from GitHub to Codeberg.
In and of itself, leaving GitHub isn't the problem. GitHub has plentifulness of problems of its own, and Zig's complaints concerning GitHub Actions were lawful reasons to regard alternatives. The issue is anywhere Zig went instead.
Codeberg is a small nonprofit Git hosting service. It's also, in my experience, frustratingly unreliable. I've often encountered association issues or established it unavailable whenever I needed it.
And I'm far from the lone one complaining.
When person suggested moving CachyOS from GitHub to Codeberg, a attendee in the CachyOS forum discussion responded:
"Codeberg frankly is notoriously unstable and tends to have association issues often."
Other participants raised much the identical concern, alongside one arguing that Codeberg hadn't yet matured adequate to be relied on as a grave GitHub replacement.
These are merely anecdotal person reports. But they equivalent my experience, and reliability isn't several obscure characteristic that lone matters to unusually demanding users. It's the naked minimum for a betterment platform.
Zig didn't need to remain on GitHub. It could have chosen GitLab, evaluated another established hosting providers, or run its own Forgejo instance. It power have the specialized cognition to do so, but it evidently preferred not to obtain on that work. Self-hosting comes alongside work, obviously. But if controlling your own infrastructure is so important, perchance that is the benevolent of activity value doing.
Instead, Zig moved crucial betterment infrastructure to a provider alongside questionable reliability and tried to market it as progress. And the reliability concerns aren't equal 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 all correct to oversee its resources, forestall abuse, and defend itself from automated crawlers. But the notice doesn't halt there. It makes sweeping judgments concerning the legitimacy of LLM-based betterment itself. Its operators explicitly contend that LLMs are incompatible alongside liable open-source application development, and its policies may exclude projects on the basis of how their code was produced.
That's a beautiful bonzer direction for a Git hosting provider. As another developer puts it in "I Regret Migrating to Codeberg," the involvement isn't fair which projects are currently restricted. It's that the hosting provider has taken it upon itself to decide which alternatively lawful forms of application betterment pertain on its platform.
You don't have to akin AI to see the issue here. Codeberg calls itself a residence for liberated and open-source software, yet increasingly seems curious in deciding which kinds of application betterment deserve to be welcome. Apparently the commons is lone average so lengthy as everyone agrees on how to use it.
A Git forge should presenter code, oversee issues, and facilitate collaboration. It should enforce sensible limits and forestall abuse. It shouldn't need to continue judgement on whether a project's betterment doctrine is sufficiently virtuous.
Codeberg's notice came following Zig's migration, so it doesn't established what the maintainers knew at the time. But it certainly doesn't create their choice appearance any improved in hindsight.
Zig traded GitHub's problems for a distinct set of problems, alongside worse reliability in my cognition and a hosting provider increasingly concerned alongside policing how application ought to be written.
And since the project's own policies align alongside that philosophy, I discover it difficult to accept applicable considerations were the lone logic for the choice.
Apparently equal donations can be the incorrect kind
The GitHub immigration announcement additionally contained a particularly different passage concerning GitHub Sponsors.
After acknowledging how crucial the phase had been to Zig's fundraising, the maintainers wrote:
"Although GitHub Sponsors is a ample fraction of Zig Software Foundation’s contribution income, we regard it a liability."
They afterward asked supporters to move their recurring donations to Every.org and announced the withdrawal of GitHub Sponsors perks. Again I must ask, why?
Zig is funded substantially through donations. People voluntarily provision the project prosperity so that its developers can keep operating on the language. And now among the platforms through which group have been supporting it is apparently a liability? Yesterday an asset, today a liability?
Granted, relying on a third-party phase carries risks. GitHub Sponsors could alter its conditions tomorrow. But that's a logic to diversify your fundraising, not discard an existing channel. Why not depart the repository on GitHub as a read-only mirror and keep accepting donations there?
Why should group who are already supporting Zig have to alter their fee arrangements fair since the maintainers no longer akin GitHub? The genuine betterment could happen entirely on Codeberg. Nobody would have to use GitHub for issues, drag requests, or CI. And the group who favor GitHub Sponsors could continue donating through it.
Perhaps there were administrative reasons for wanting to consolidate fundraising elsewhere. But the notice doesn't established why keeping the two channels was unacceptable. The maintainers did appreciate their existing supporters, and they weren't exactly refusing donations. But I motionless discover the communication remarkably tone-deaf.
When your project relies on voluntary contributions, making it small convenient for group to assistance you should necessitate a improved clarification than disliking the phase they happen to use.
It's one item to refuse to depend on GitHub for development. It's another to rotate that penchant into unnecessary conflict for group who are trying to provision you money.
Once again, everyone alternatively is expected to modify Zig's principles.
Going nowhere
Zig isn't dead. Development continues, and the compiler keeps getting better.
But specialized advancement isn't the identical item as maturity. What fine is an increasingly advanced programming tongue if using it remains an exercise in keeping up alongside breaking changes and the whims of project management?
Look at the pattern. Users are expected to keep up alongside an unstable language. Contributors are expected to activity the approved way. A notable downstream person decides Rust fits better, and the project publically lashes out. The hosting phase changes, and donors are asked to move alongside alongside it.
Zig's maintainers anticipate everyone alternatively to modify to the project during showing amazingly small willingness to modify the project to everyone else.
Undoubtedly they have the correct to run Zig nevertheless they want. Open origin doesn't average maintainers owe everyone unlimited support, liberated code review, or eternal backward compatibility. But the reverse is likewise true: users don't owe maintainers their time, loyalty, or accord alongside their philosophy.
A developer wants to compose software, not expend countless hours migrating standard-library APIs. A contributor power desire to fix a bug, not demonstrate allegiance to a sanctioned academy of engineering. A business wants a tongue that solves its problems, not a address concerning how to run its business. And a contributor wants to assistance a project, not get embroiled in its disagreement alongside GitHub.
Good project administration method making compromises. Sometimes that method putting stability onward of another elegant redesign. Sometimes it method accepting a helpful place from person who doesn't portion your preferred betterment ideology. Sometimes it method swallowing your pride whenever a important person moves on. And sometimes it method choosing boring, dependable infrastructure alternatively of making a philosophical statement.
Zig seems resolute to do item but that.
None of this is inevitable. Zig could keep its specialized ambitions during becoming a much additional dependable tongue and a much easier project to activity with. But that would necessitate its maintainers to commencement treating users' needs as item additional than an inconvenience to be managed.
The project can keep refining its tongue scheme forever. It can keep insisting on its own idea of fine engineering, rejecting the incorrect kinds of contributions, and choosing platforms that align alongside its worldview.
But at several point, it needs to decide whether it wants to build a programming tongue group can use or an ongoing test in how its maintainers think application have to be developed.
Zig has spent additional than a decade figuring out what its maintainers desire the tongue to be. Perhaps it's period they started caring a small additional concerning what its users need it to be.
Until then, the Zig project is going nowhere.
