The Zig project is going nowhere

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 1 . 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 start being software development and stop 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 reasonabl