I wish they had gone more into the amount of human code review they employed. Just a ballpark idea of how much of the code has had a human look at it. I’m not a bun rewrite hater - and I suspect...
I wish they had gone more into the amount of human code review they employed. Just a ballpark idea of how much of the code has had a human look at it. I’m not a bun rewrite hater - and I suspect those people are mainly insecure and afraid of change - but I do think you should anchor the project in some of the old ways just to gain and share confidence.
The confidence is key, given the mixed sentiment about AI coding agents. The rewrite alienates a lot of developers. I have no idea exactly how many people/orgs have stopped using Bun as a result...
The confidence is key, given the mixed sentiment about AI coding agents. The rewrite alienates a lot of developers. I have no idea exactly how many people/orgs have stopped using Bun as a result (or are in the process of migrating) but it's definitely not none.
Something more than "we did vibed security review" and "we setup fuzzing" might go a long way to convincing people they can trust this massive bet on vibecoding. It's a huge rewrite and the timeline makes it clear that the initial rewrite was nearly 100% vibecoded. What have they done since to take ownership over the codebase? How much will humans be in the loop going forward? Will the project be largely maintained by agents? If so it's going to get progressively uglier under the hood unless new generations of models are much better than what we have now. Personally I'd never consider building a project on top of a runtime like that, the risk/reward is all wrong.
From the article: [...] [...] [...] [...] [...] [...] [...] [...]
From the article:
Bun started as a line-for-line port of esbuild's JavaScript & TypeScript transpiler from Go to Zig. I wrote my first line of Zig on April 16, 2021. I bet on Zig after seeing the single-page Zig Language Reference on Hacker News and getting really excited about the low-level control and care for performance.
[...]
For Bun, correctly handling the lifetimes of garbage-collected values and manually-managed values has been a major source of stability issues - most often small memory leaks and occasionally, crashes. Every memory allocation has to be meticulously reviewed. Where do these bytes get freed? How do we ensure it only gets freed once? Did we check for JavaScript exceptions properly? Is this garbage-collected pointer visible to the conservative stack scanner? Is this garbage collected memory or manually managed memory?
[...]
A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide.
Historically, rewrites are a terrible idea. Excluding comments, Bun is 535,496 lines of Zig. A rewrite in another language would take a small team of engineers a full year. It would mean freezing bugfixes, security fixes or feature development for that time. The least risky approach to getting something shippable would be a mechanical port from Zig to Rust, with the minimal number of behavioral changes, using the exact same test suite we already use for testing Bun.
Fortunately, Bun's own test suite is written in TypeScript which means it doesn't depend on the runtime's programming language.
[...]
Since merging the Rust port, we've completed 11 rounds of security review from Claude Code Security and addressed the findings.
We've also added 24/7 coverage-guided fuzzing of every parser in Bun — JavaScript, TypeScript, JSX, CSS, JSON5, JSONC, TOML, YAML, Markdown, INI, Bun Shell scripts, semver ranges, .patch files, and CSS colors. The fuzzer automatically sends the bugs it finds to Claude to submit a PR reproducing & fixing, and humans review the PRs. So far, it's executed our parsers 100 billion times which has led to around 15 PRs.
[...]
So far, Bun v1.4.0 fixes 128 bugs that reproduce in v1.3.14. These range from memory leaks to crashes to miscolored help text.
[...]
In Bun v1.3.14, every build leaks about 3 MB, forever — tools like dev servers that bundle on every request eventually run out of memory. In Bun v1.4.0, memory levels off:
[...]
The initial changes in the Rust rewrite reduced binary size by 3.8 MB on Windows, 5.5 MB on macOS, and 6.8 MB on Linux. This is largely because we used too much comptime in our Zig code.
[...]
Claude Code v2.1.181 (released June 17th) and later use the Rust port of Bun. Startup got 10% faster on Linux but otherwise, barely anyone noticed. Boring is good.
[...]
Bun v1.3.14 was the last version of Bun written in Zig. Bun v1.4.0 will be the first version of Bun written in Rust. It's available in canary now - please report any issues you find:
I wish they had gone more into the amount of human code review they employed. Just a ballpark idea of how much of the code has had a human look at it. I’m not a bun rewrite hater - and I suspect those people are mainly insecure and afraid of change - but I do think you should anchor the project in some of the old ways just to gain and share confidence.
The confidence is key, given the mixed sentiment about AI coding agents. The rewrite alienates a lot of developers. I have no idea exactly how many people/orgs have stopped using Bun as a result (or are in the process of migrating) but it's definitely not none.
Something more than "we did vibed security review" and "we setup fuzzing" might go a long way to convincing people they can trust this massive bet on vibecoding. It's a huge rewrite and the timeline makes it clear that the initial rewrite was nearly 100% vibecoded. What have they done since to take ownership over the codebase? How much will humans be in the loop going forward? Will the project be largely maintained by agents? If so it's going to get progressively uglier under the hood unless new generations of models are much better than what we have now. Personally I'd never consider building a project on top of a runtime like that, the risk/reward is all wrong.
They'll never do that, this whole thing is functionally a marketing stunt by Anthropic to sell Claude.
From the article:
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]