Zig 项目被指进展停滞

Text to shareFrom BCN:

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.

https://bytecode.news/posts/2026/10/the-zig-project-is-going-nowhereEach button copies the text and opens the network's own page, where you paste it.

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

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.

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:

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

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 appreciative. 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 plent