Bun was ported from Zig to Rust by an LLM and passed nearly all its tests - while shipping more than ten thousand unsafe blocks. Memory safety is the main reason you'd pick Rust. So what did the rewrite actually accomplish?
The irony of a post about a port primarily written by Claude having been primarily written by Claude on a website primarily designed by Claude. Come on.
> There is a small, ironic coda. The follow-up PR to delete the 600,000 or so lines of leftover Zig was titled, by Sumner, "ai slop." GitHub's automated anti-slop detection - built to flag exactly the kind of AI-generated mass change this was - caught it and auto-closed it. The author named his own cleanup slop, and the platform's tooling agreed.
That looked suspicious to me (you could almost say hallucinated...), so I checked it out. Here's the GitHub Action that adds that comment - written by Jarred back in February, so it's not accurate to classify it as "GitHub's automated anti-slop detection". https://github.com/oven-sh/bun/commit/c01a5e08be896e1d1f4529...
> The Rust rewrite passed 99.8% of the existing test suite. That number is enormous and significant, but let's be precise about what it actually says
I'm having a hard time even loading the PR, so can't look myself... But I seem to remember that there was changes to the test suite as well as the rewrite to the Rust engine, that would mean this number may or may not actually be accurate. Anyone remember or could actually load the PR and see? That'd make this article weirdly under-researched and missing something kind of vital.
How much of an architectural change does the borrow checker require? It feels to me like a pretty central part of Rust, and you can't just translate all the files one to one, then refactor out the unsafe blocks, it might need a full think through and project analysis to make it actually work with rust, instead of being forced into rust
> For scale: uv, a Rust project of broadly comparable size from the same general corner of the ecosystem, contains 73.
As a point of information: uv's use of `unsafe` largely involves interactions with OS APIs that don't have safe wrappers yet (in practice, this is mostly Win32 and similar APIs). It makes sense that Bun would have more `unsafe` than uv does, insofar as it needs to interact with JavaScriptCore's C API.
(This is without making a value judgement; only to observe that the magnitude of `unsafe` across projects doesn't necessarily communicate anything without knowing what the `unsafe` is for.)
OS boundary unsafe is easy to audit because it's at the edges. The problem here is 10k unsafe blocks scattered through the core - that's a different thing entirely.
I am idly wondering, would it have made a difference if this was done over a month or two rather than say 9 days.
If it was really a thought experiment, and the test suit was so good, and hopefully further improved after this. Could the same experiment be run translating to Go, C, C++, Pascal, Swift, Crystal or Ada?
if anything, compilers and interpreters are probably the most suited for ai codegen as they have some of the most comprehensive test suites around and are relatively easy to verify.
that said, it's a fun debate. sure, the rust compiler eliminated a whole class of memory bugs- but did the convoluted borrow checker gymnastics plus agent whoopsiedaisies leave behind a plethora of hidden and exploitable logic bugs?
it'll be interesting to see, although we may never know as anthropic will probably use the latest frontier models to audit and quietly patch over the coming years.
This feels confused. The point is surely that memory-safe code can now be written, where the article seems to focus on the fact that it hasn't been yet.
I don't understand why they ported the Zig part. Wouldn't it have made more sense to have just unleashed the tokens on Claude Code itself, and eliminated the need for the bundled runtime altogether?
I always thought if they are vibe coding all the unsafe Rust code, they might as well keep it in zig, at least someone understands what they are doing. With Rust, when there is a CVE, chances are that nobody can even understand what the issue is, let alone fixing it.
I for one am definitely going to stick to Node.js instead of taking my chances with Bun.
> This is a measurement discipline: when someone offers you a test pass rate as evidence of a safety property, check whether the test suite measures that property. Behavioral equivalence and memory soundness are different axes. A green test suite tells you the new thing acts like the old thing. If the old thing was a body of manual memory management and the new thing is a faithful translation of it, then green tells you the translation is good - and tells you nothing whatsoever about whether the thing is safe. The number that would actually answer the question is the one nobody can produce yet, because producing it is, for now, an unsolved problem.
Bottom line is we didn’t have a measurement of safety before the port, and we don’t have one now.
What we do have is a known list of unsafe blocks, and we can use that as our safety measure. (I’m neither a Zig not Rust programmer, but I’m guessing that the unsafe parts of the Zig codebase were also mostly measurable so we could have had this measure.)
I do wonder if the next step is to move bun into WASM for an additional layer of security. Those unsafe blocks might be neutered by not granting WASM the ability to run them. That would give anthropic a “sandboxed by default” opportunity.
Posted this in a thread yesterday but seems relevant, I have been working on similar open source rewrites. Starting with Lua and Nginx. Trying to target idiomatic/ performant safe Rust from the start than straight porting and adding safety/ performance later.
- Valkey/ Redis port here https://github.com/ianm199/valdr (passes ~99% of single node test suite, real prod features like replication/ clustering/ HA early or not implemented)
So who will be doing upkeep and maintenance of the project, will developers who worked on this project need to learn Rust to be able to work with the codebase and be able to have correct judgement about changes done by LLM? If yes then will junior Rust developers be able to correctly assess PR's generated by LLM? Or developers will be fired and new team with Rust expertise will be responsible for the project now?
What has not been talked about here yet, and which isn't directly about AI, is this: "The benchmarks are neutral-to-faster, and the binary shrank by a few megabytes"
This says more about Zig versus Rust, and I was surprised by it, that a "direct translation" of this kind would give a somewhat faster and smaller binary.
23 comments
[ 3.4 ms ] story [ 40.6 ms ] threadWould you trust a fully vibe-coded runtime? Not some features, not some fixes, but a full translation from one language to another.
- This is blatantly irresponsible, and killed any credibility this project has
- Comparing unsafe counts to UV makes no sense here.
- There is already a strong, safe runtime that's not vibe coded, called Deno, that more people need to check out.
- I am skeptical why Bun was even an acquisition target in the first place, other than pulling stunts like this.
That looked suspicious to me (you could almost say hallucinated...), so I checked it out. Here's the GitHub Action that adds that comment - written by Jarred back in February, so it's not accurate to classify it as "GitHub's automated anti-slop detection". https://github.com/oven-sh/bun/commit/c01a5e08be896e1d1f4529...
It was Jarred who deliberately added the slop label to that PR, which triggered the Action comment: https://github.com/oven-sh/bun/pull/30680#event-25523046939
I'm having a hard time even loading the PR, so can't look myself... But I seem to remember that there was changes to the test suite as well as the rewrite to the Rust engine, that would mean this number may or may not actually be accurate. Anyone remember or could actually load the PR and see? That'd make this article weirdly under-researched and missing something kind of vital.
As a point of information: uv's use of `unsafe` largely involves interactions with OS APIs that don't have safe wrappers yet (in practice, this is mostly Win32 and similar APIs). It makes sense that Bun would have more `unsafe` than uv does, insofar as it needs to interact with JavaScriptCore's C API.
(This is without making a value judgement; only to observe that the magnitude of `unsafe` across projects doesn't necessarily communicate anything without knowing what the `unsafe` is for.)
If it was really a thought experiment, and the test suit was so good, and hopefully further improved after this. Could the same experiment be run translating to Go, C, C++, Pascal, Swift, Crystal or Ada?
that said, it's a fun debate. sure, the rust compiler eliminated a whole class of memory bugs- but did the convoluted borrow checker gymnastics plus agent whoopsiedaisies leave behind a plethora of hidden and exploitable logic bugs?
it'll be interesting to see, although we may never know as anthropic will probably use the latest frontier models to audit and quietly patch over the coming years.
I for one am definitely going to stick to Node.js instead of taking my chances with Bun.
Bottom line is we didn’t have a measurement of safety before the port, and we don’t have one now.
What we do have is a known list of unsafe blocks, and we can use that as our safety measure. (I’m neither a Zig not Rust programmer, but I’m guessing that the unsafe parts of the Zig codebase were also mostly measurable so we could have had this measure.)
I do wonder if the next step is to move bun into WASM for an additional layer of security. Those unsafe blocks might be neutered by not granting WASM the ability to run them. That would give anthropic a “sandboxed by default” opportunity.
It’s a fun project to watch!
- Valkey/ Redis port here https://github.com/ianm199/valdr (passes ~99% of single node test suite, real prod features like replication/ clustering/ HA early or not implemented)
- Further along port of Lua 5.1-5.5 https://github.com/ianm199/lua-rs-port/tree/main
- I have a less developed nginx version that would be the North Star
- These projects are very alpha at the moment.
The thought was that we might need many “shots on net” in terms of software safety in the future so worth exploring.
Add a lambda fuction. Add list of condiments[0] such as let-us.
Forage/prove one can have a turing complete meal with bun? Easier than risking indigestion through bun/sheaf correspondence.[1][2][3][4]
------------------------------------
[0] : https://en.wikipedia.org/wiki/List_of_condiments
[1] : Applied Sheaf Theory for Multi-agent Arificial Intelligence (Reinforcement Learnig) Systems: A prospectus : https://people.cs.uchicago.edu/~ericschmid/schmid-applied-sh...
[2] : Discreate Morse theory for computing cellular sheaf cohomology : https://www2.math.upenn.edu/~ghrist/preprints/computationals...
[3] : https://medium.com/@german_mag.ai/sheaf-theory-and-applicati...
[4] : https://direct.mit.edu/books/oa-monograph/5460/Sheaf-Theory-...
The Zig implementation is literally still there.
You can make predictions of what might happen in the future, but hard to take the rest of the article seriously when it has the basic facts wrong.
This says more about Zig versus Rust, and I was surprised by it, that a "direct translation" of this kind would give a somewhat faster and smaller binary.