The strongest reaction was not "AI bad" so much as "this result only exists because the setup was unusually favorable". Bun already had a huge language-agnostic test suite, a million-plus JavaScript compliance checks, and a founder with deep knowledge of both the intended behavior and the old failure modes. That made the job closer to constrained translation than open-ended software creation. Several readers said that is the real lesson. LLMs did not magically replace software engineering here. They amplified a very strong verification loop and a human who knew exactly what success looked like.
Where opinion hardened was around trust. A lot of people thought the technical case for moving away from Zig was plausible, especially for a JS runtime where memory ownership crosses awkward boundaries. But they also thought the transition was handled recklessly. Shipping such a large rewrite with little public consultation, no real off-ramp for users who wanted to stay on the Zig branch, and earlier messaging that downplayed how serious the effort was left many readers less worried about the code than about project governance. The post repaired some confidence by showing the rewrite had already been running inside Claude Code since June, but it did not erase the sense that Bun behaves like a personal project even after becoming critical infrastructure for others.
The other big fault line was whether the Rust result proves much about Rust itself. Many accepted that moving to a memory-safe language is a sensible end state for software like this. Others pushed back that the observed gains were muddied by rewrite effects, linker and build changes, and years of accumulated lessons from the Zig codebase. A few commenters went further and said the real unresolved issue is the quality of the
`unsafe` Rust. They pointed to
Miri findings, dubious
`SAFETY` comments, and the risk that an AI-assisted translation can produce code that looks disciplined while smuggling in undefined behavior. That left the final read on the post fairly sharp: impressive as a demonstration of what frontier models plus strong tests can do, far less convincing as proof that the migration was cleanly maintainable or that the process should be copied blindly.