As soon as people found a Bun branch mentioning an experiment to use an LLM to port the existing Zig code to Rust, they went mad.
It was a personal experiment, on a non-default Git branch, not announced anywhere.
That didn’t matter. Rust advocates popped champagne. Zig people were shocked. Actual Bun users got confused. Everybody fought like kids in a kindergarten playground.
Jarred Sumner has issues with Bun. Maybe the root cause is original technical decisions rather than anything inherent to Zig. Maybe moving to another language could help with some of them. Maybe not. But trying is not insane.
Rewriting software is often a good way to revisit how the code works, remove technical debt, and produce something better. Especially when the mature shape of the product is already known. You don’t have to rediscover every edge case, every awkward feature, and every hack that got added because the original design didn’t anticipate reality.
Rewriting Bun would still be a significant task.
But despite everybody talking about a Bun rewrite, that was not really the plan.
The plan looked more like this:
- Transpile the Zig code to Rust. Every file, function, and structure should remain as close as possible to the original, so that a Zig file and its Rust equivalent are functionally interchangeable.
- Incrementally tweak, rewrite, and refactor individual functions and types until the code becomes idiomatic, maintainable Rust.
- Eventually, get a Rust rewrite.
Bun completed phase 1 only.
This is transpiled code. Automatically transpiled code. Since there are no Zig-to-Rust transpilers, Jarred used an AI prompt.
And it worked.
As in: the tests passed.
And that is not very surprising. LLMs are good at translating text, and code is text with a lot of structure. If you give them a large test suite to keep them from going off the rails, this kind of mechanical translation is exactly the sort of thing they can do well.
Anthropic can use it to show off Claude, but most coding models could probably do something similar with the right instructions.
The resulting Rust code was of poor quality.
Of course it was.
An experienced Rust developer would not accept code like that in their own project. And obviously, it was mocked, including by Rust advocates who had originally rejoiced at the idea of Bun being “rewritten” in Rust.
But idiomatic Rust was not the goal at that point.
Phase 1 was meant to be a literal, direct translation of the Zig code. In that context, Rust is almost an intermediate representation. The source of truth is still Zig. The Rust output is there to see whether the translation pipeline can preserve behavior before anyone starts improving the result.
Phase 1 was not about producing beautiful Rust.
It was about answering a narrow question: can a large Zig code base be translated automatically, with enough fidelity for the test suite to pass?
Apparently, yes.
With AI, that is a simple experiment to run. It is quick. It is cheap when you don’t pay for tokens. Failure is acceptable because it doesn’t require much commitment. That is exactly why Jarred described it as an experiment.
From the outside, though, the story looked very different.
People saw a leaked intention to do something controversial. Then they saw the controversial thing materialize. Then they saw horrific-looking generated Rust. In a few days, Bun went from a tool people trusted and used in production to, in their minds, a tool being blindly rewritten by AI with minimal quality control.
So they panicked.
Here is the uncomfortable part: the root cause of the drama may be that Jarred acted transparently.
He could have kept the Rust branch private until phase 3 was complete. And if the experiment failed, he could have never mentioned it.
Then, much later, he could have announced a new Bun version, actually rewritten in Rust, with code everyone agreed was good and stability numbers better than the original implementation.
Language advocates would still have fought. Of course. But actual users would mostly have judged the result.
Does it work? Is it reliable? Is the new version better than the previous one?
If yes, cool. If no, that is a good reason to leave.
Most users do not really care how software is built. They care whether the tool they rely on keeps working.
But Jarred did not do the safe corporate thing. He worked in the open, including the earliest and ugliest part of the experiment.
And that backfired.
Unfortunately, this is a common open source problem.
Maintainers need to experiment. That is a normal part of working on a project. It is fine to write unfinished, ugly, unsafe, half-broken code while exploring an idea. It is also convenient to push these branches to GitHub.
Yes, alternatives exist. But if you work from multiple devices, or want to share the branch with one person, pushing it to the same remote as everything else is by far the easiest workflow. Anything else adds friction.
The problem is that every bit pushed to a public repository becomes material for interpretation.
People will look at it. They will judge it. They will assign intent to it. They will write the missing context themselves, usually in the least charitable way possible.
If a project is open source, maintainers are somehow expected to make every public commit look clean, coherent, and strategically final.
That is absurd.
It also changes behavior. The more popular a project becomes, the less freedom maintainers have to think in public. A random branch stops being a scratchpad and becomes a press release. A quick experiment becomes a roadmap. A bad intermediate result becomes proof that the project has lost its mind.
So maintainers learn the obvious lesson: hide the messy parts.
That is bad for everyone.
The lesson for Bun is not that AI rewrites are good. It is not that Rust would fix Bun. It is not that Zig is the problem. None of that is proven by this experiment.
The lesson is that public development and public experimentation are not the same thing.
Users want transparency, but they also punish unfinished work. Maintainers want openness, but they also need private space to try stupid ideas before deciding whether they are stupid.
For large projects, maybe the practical answer is boring: keep experiments private until they have enough context to be understood, or label them so aggressively that nobody can pretend they are production plans.
That is less romantic than developing everything in the open.
But if every ugly branch becomes drama, more maintainers will stop showing ugly branches.
And then everybody will complain that open source became less open.