I was wrong. And I’m glad I was wrong.
When Bun announced it was rewriting from Zig to Rust, the Zig community felt a collective gut punch. If you’ve been following the drama, you probably felt it too—that knot of betrayal, the fear that this would kill Zig’s momentum. I spent months being angry about it. But Andrew Kelley’s recent post made me realize something uncomfortable: the rewrite is the best thing that could have happened to Zig.
The best thing that can happen to a programming language is losing its worst advertisement.
Here’s the uncomfortable truth nobody in the Zig community wanted to admit: Bun was a terrible showcase for Zig. It used the language in ways that contradicted its design principles. It was the most visible Zig project on the planet, and it was simultaneously the worst example of how to write Zig. The very thing that made Bun a flagship—its speed, its ambition—also made it a misleading poster child.
Andrew Kelley, Zig’s creator, put it bluntly: Bun’s codebase was not idiomatic Zig. It was a project that happened to be written in Zig, but it didn’t represent the language’s strengths. The community knew this. We whispered about it in forums and chat rooms. But we were afraid to say it out loud because Bun was all we had to point to when people asked, ‘What’s Zig good for?’
Community pride often conflicts with technical honesty. The best communities choose honesty.
Now that Bun is migrating to Rust, the emotional weight is gone. Suddenly, we can look at Zig without the distortion of a flawed flagship. The rewrite forces the community to build better exemplars—projects that actually demonstrate Zig’s true value proposition: compile-time computation, zero-cost abstractions, and a memory model that doesn’t require a garbage collector. No more coasting on a single popular but misleading reference implementation.
I saw this firsthand in the comments on Andrew’s post. Developers who were initially upset, myself included, started to shift. ‘I was wrong to be upset,’ one said. ‘This is one of those rare occasions when I’m glad I was wrong.’ That’s the relief of vindication—the moment you realize your defensive loyalty was blinding you to a better outcome.
So let’s stop pretending the rewrite is a loss. It’s a reset. Rust gets a high-profile project that will be better served by its ecosystem. Zig gets the chance to be judged on its own merits, not on someone else’s implementation mistakes. The removal of a flawed flagship is not a defeat; it’s a gift.
Thank you, Bun, for the rewrite. You gave Zig the greatest gift: a clean slate.
FAQ
Q: Doesn't the rewrite prove that Rust is better than Zig?
A: No. It proves that Bun's specific implementation choices were better suited to Rust's ecosystem. Bun was not idiomatic Zig, so the rewrite doesn't reflect on Zig's capabilities. It's about project fit, not language superiority.
Q: What's the practical takeaway for developers choosing a language?
A: Don't judge a language by its highest-profile project. Look for idiomatic examples that actually use the language's strengths. The removal of a misleading flagship forces the community to produce better, more representative projects.
Q: Is there a contrarian angle here?
A: Yes: the rewrite is a win-win. Rust gets a solid project that will be better maintained, and Zig gets to shed a flawed example. The real losers are the developers who let emotional attachment to a project blind them to technical reality. Honesty wins in the long run.