This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to compare a viable Rust version and a Zig version side by side.
show comments
stingraycharles
Interesting to see this when the current top post on HN is someone worrying about Bun as it was acquired by Anthropic. The top comment there describes “Anthropic does experiments on their own codebase, the Bun team is not gonna do the same vibe coding experiments”.
Yet here we are, what looks like a massive undertaking for vibe coding.
Time will tell how this will turn out. Would be nice if the Bun maintainers could give some clarification about what they’re doing here, and why they’re doing this.
show comments
kgeist
Interesting how times have changed. Back in 2015, the entire Go runtime (already a mature codebase) was rewritten from C to Go semi-automatically: one of the maintainers wrote a C-to-Go conversion tool (for a subset of C they used) so that it compiled and produced identical output, and then the resulting code was manually refactored to make the Go code more idiomatic and optimized. And now you can just ask a language model.
>We had our own C compiler just to compile the runtime.
The Bun team maintain their own fork of Zig too
show comments
hsaliak
The problem with vibe coded re-writes is that you basically sign off on understanding the generated codebase at that point. Any historical knowledge of the codebase is gone.
show comments
archargelod
Linked commit is probably not the most convincing for this tagline. Here's a branch[0] of Claude mass rewriting Zig code into Rust which is currently at 773,950 additions and 151 deletions:
I wonder if a successful, albeit slower, approach would be to walk the git commit history in lockstep, applying the behavioral intent behind each commit. If they did this, I would be interested in knowing if they were able to skip certain bug fix commits because the Rust implementation sidestepped the problem.
show comments
selectnull
Why not rewrite claude-code in Rust?
So, Anthropic acquires Bun team because claude-code uses Bun. They port Bun from Zig to Rust presumably because Rust "is better" (imagine big air quotes here). Again presumably, they want to make claude-code "better". Why make it so complicated? With all the power of LLMs they have, surely they can make claude-code the best possible by writting it in Rust directly.
show comments
carpenecopinum
Given the recent gripe that Bun/Anthropic indicated regarding compile times with Zig (i.e. that their vibe-coded 4x compilation speedup PR wasn't accepted), it appears to me as an "interesting" move to switch to a language that probably delivers 4x longer compilations than even vanilla Zig.
jr-14
I want zig to succeed but given that zig is not yet 1.x I'd imagine a large code base like bun would have difficulties addressing major breaking changes. Also given the fact that bun is using a fork of zig https://x.com/bunjavascript/status/2048427636414923250?s=20
padjo
Picking a pre 1.0 language to build your product always seemed like a bad choice to me. Purely on that basis and ignoring the recent drama this seems like a reasonable idea for tech debt pay down to me. Assuming automated conversion can work without making things worse, which is not exactly a given.
show comments
Humphrey
I'll be very interested in how this AI port turns out. I am involved in a number of active projects that are being held back by the language / framework is holding back the project, but where a rewrite would be too big of a project to undertake by using only human power.
I've had more success vibe coding Rust than I have in more dynamic languages. I suspect the strictness of the Rust compiler forces the AI agent to produce better code. Not sure. It could be just that I am less familiar with Rust so it feels like it's doing a better job.
show comments
croemer
At this point, it looks just like an experiment. It's not a definitive "were going to switch".
I think people here are reading too much into it.
yladiz
Why? Are there particular reasons that the maintainers of Bun feel the need to attempt to migrate from Zig to Rust?
show comments
inkysigma
So I can't tell if the linked commit is an actual attempt or just an experiment but it did always strike me as odd to make a JS runtime in Zig when my impression was there were a lot of work-stopping compiler bugs at the time.
show comments
hbbio
Given they have "unlimited" AI usage, do we expect the port to be complete tomorrow?
elffjs
Comparing this claude/phase-a-port branch with main: “Showing 1,646 changed files with 773,950 additions and 151 deletions.”
show comments
thayne
When I first heard that bun was written in zig, I thought that was an odd choice for such a large project, mostly because the language is "unstable" and is still making significant breaking changes.
I would guess dealing with breaking changes is a big motivation for this.
wg0
If nothing, it'll be good marketing material targeted at non-technical enterprise executives so that they pressurize their engineering teams in meetings that look people are porting such complicated things from one different language to totally different language then why are we not using AI effectively?!
cropcirclbureau
The only Bun shipped product I've used in anger is OpenCode and I regularly run into segfaults on it. I doubt this is the reason for migration but every time it happens, it reminds me the real cost of unsafe code. That being said, Zig is an absolute pleasure to write and I can't wait until it has a real library ecosystem, Rust's greatest boon.
show comments
toledocavani
For better or for worse, at least Bun is open source, and the world is not lacking a NodeJS alternative.
What is the most interesting here for me is:
- a big, clear outcome and acceptance criteria, vibe coding project on
- a public, working, high performance, full featured, production codebase by
- the leading LLM model maker known for the strongest coding ability
A good example no matter if it successes or not.
mohsen1
I am also porting TypeScript to Rust. With a different design I managed to make it faster than tsgo port. I've made a lot of progress in the last 4 months but needs more work. Contributions are welcome!
It seems there was an issue where the image API ignored the ICC Profile.(now fixed)
Any developer with experience implementing image formats would almost certainly avoid this mistake. This is a problem that cannot be solved with vibe coding. In this situation, the user is merely a guinea pig for bug fixes.
show comments
rollulus
Rewriting it using an LLM is one. But did all the contributors became as proficient in Rust as they were in Zig over night as well?
show comments
bijowo1676
Its never been easier to rewrite X in Rust than today.
Will everything eventually be rewritten in Rust and we finally achieve utopia?
show comments
jvidalv
Bun can't be used for anything serious, only as a "script kiddie" to run small scripts.
Trying to run it as a replacement for node in persistent backend/api scenarios is just plain broken.
I suspect that an experiment is being run. In any case, that'll be a hell of a story!
ozgrakkurt
Just checking some loc numbers from nodejs, bun and deno:
On nodejs: `tokei src`: 98333 LOC C++ Code
On bun: `tokei src` 573572 LOC Zig Code
On deno: `tokei libs cli runtime` 289573 LOC Rust Code
This seems wrong though so would be appreciated if someone who knows the structure of these projects can correct me on the folder names.
Doing `tokei lib src test deps` gives more than 5M loc. but not sure if that is fair
anymouse123456
This is a huge loss for the zig language and community.
As a fan of the language, I hope it leads to some reflection on things that might need to change moving forward.
show comments
jgalt212
That PORTING.md file is massive and seemingly comprehensive. Was that AI written as well? Is there a general Zig to Rust porting template being used?
thatxliner
Didn't they write a whole blog post on why they chose Zig over Rust?
arthurcolle
Could just be an experiment or something. It's Monday, the week is young
apatheticonion
Having written a JavaScript runtime in Rust in the past - Rust is an excellent choice. Not just due to the development experience, but also for embedders who want to consume the project as a a library (rather than a binary, e.g. node).
Not sure about vibe-coding it. While they aren't using v8, LLMs made it easier to understand v8 quirks and update v8 as they make weird changes every now and then. It couldn't write the runtime without help though.
So the bad, bad Zig that opposes the clanker mania has to be punished, even if top comments deny it.
Anthropic is one of the most evil companies in existence today. Whenever someone produces something, they steal it.
born-jre
Let the guy cook, would be nice benchmark of llm nothing else. Damn I wish I had access to infinite tokens for crazy experiments like this.
notnullorvoid
Probably a good thing for the project even if the only net positive ends up being the Bun team stops maintaining a fork of Zig.
ngoquocdat
I think they are simply experimenting to fully exploit Claude's models' powerful capabilities.
nananana9
Alright, back to node.
I was hopeful for this project, and I've reported crashes & bugs in the bundler with the hope that it will stabilize over time, but this is just silly - I'm not going to risk them pulling the rug under me and replacing the runtime with 1 million lines of vibecoded rust.
ratstew
This feels more like a reaction to Zig's anti-LLM policy than anything. Anthropic would probably like to contribute something back to Zig at some point, but I doubt anyone would ever believe their PRs were not written by Claude.
show comments
kadhirvelm
I can't imagine going from reviewing code in Zig to letting Claude code handle it in Rust. Seems like a lot of change to deal with in a short amount of time. Wonder how much the bun team culture will change? We've been really liking bun so far
kandros
Unexpected, I was waiting for them to maintain a zig fork
simultsop
Which makes one think, why they did not buy deno at first place then?
If they did, I guess they would rewrite deno in C++
icase
oh for christ’s sake
confessinator
Aside from Zig's anti-AI stance and maintaining their own Zig fork, I think this port will showcase that Anthropic can re-engineer a massive codebase.
As an aside, I've been bitten by Zig's breaking changes on my own projects as well. It's taken the shine off of Zig and I'm looking at alternatives.
_pdp_
Claude Mythos cannot do the porting?
shevy-java
Poor Zig - it's bleeding now.
Everyone wants to be a Rustee these days.
larpa
"Claude, migrate bun to Rust, make no mistakes"
root_axis
Any confirmation that a genuine port is underway? This might just be an experiment.
ivolimmen
I am not a fan of AI but my limited experience with running local small LLM's did show me that rewriting some scripts into a different language worked really well. So my guess is this will just turn out fine.
joknoll
maybe anthropic should‘ve just acquired deno
Animats
How well does that long translation prompt work?
hiroakiaizawa
Interesting. What are the main trade-offs they expect from the switch?
forrestthewoods
I hope they ship and use this. It’ll be a super interesting case study in a few years.
show comments
iamgopal
the days are not far when golang will be ported to rust.
show comments
GianFabien
Here we go again ...
Company A buys company B. A's management decrees the henceforth B's aqcuihired team must comply with company A's standards.
Second system effect kicks in. Bugs multiply.
Half of original company B devs leave.
I'm investigating whether future projects should revert to using Deno.
gib444
> Read this whole document before
writing any code.
Hm does that actually work?
Edit: in a way that can be verified, and not the AI tool saying it did
Capricorn2481
April 26th - Bun announces they used AI to fork Zig so they could make an optimization for a 4x improvement
April 27th - Zig contributor mlugg clarifies why the specific optimizations Bun did were ill advised and wouldn't have been accepted in Zig, regardless of AI use [1]
May 4 - Bun is looking into Rust as an alternative.
This, to me, seems like total whiplash. Has anyone at Bun made a statement on why they're making such dramatic changes? It seems like the lesson to internalize from mlugg is not "switch to Rust"
Interesting. When I thought of Zig, I thought of Bun. In my mind it was the flagship application for that language. Is there another? I wonder how the Zig team feels about this. To me it seems like Rust has definitively won now.
show comments
sergiotapia
>*No `tokio`, `rayon`, `hyper`, `async-trait`, `futures`.* No `std::fs`,
I'm not a rust dev but even I kind of notice that tokio is kind of shunned in most projects. Why is that? Is it just bad or what?
show comments
ConanRus
instead of writing it once in C++
matrix12
it will make it more portable.
markovmodel
what a win
altun
I guess it's like Trump saying, "I'll take Greenland too..."
nothinkjustai
Makes sense on merit. There really isn’t room for Zig when Rust exists, is more ergonomic, and also safe.
0x142857
you can use both zig and rust in a single project, duh
show comments
hakrgrl
People are asking why they would switch from zig to rust. I wonder the opposite: why would anyone would use zig over rust?
show comments
Entambi
hahaha eat your heart out "don't port it to rust" gang
I work on Bun and this is my branch
This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to compare a viable Rust version and a Zig version side by side.
Interesting to see this when the current top post on HN is someone worrying about Bun as it was acquired by Anthropic. The top comment there describes “Anthropic does experiments on their own codebase, the Bun team is not gonna do the same vibe coding experiments”.
Yet here we are, what looks like a massive undertaking for vibe coding.
Time will tell how this will turn out. Would be nice if the Bun maintainers could give some clarification about what they’re doing here, and why they’re doing this.
Interesting how times have changed. Back in 2015, the entire Go runtime (already a mature codebase) was rewritten from C to Go semi-automatically: one of the maintainers wrote a C-to-Go conversion tool (for a subset of C they used) so that it compiled and produced identical output, and then the resulting code was manually refactored to make the Go code more idiomatic and optimized. And now you can just ask a language model.
The slides: https://go.dev/talks/2015/gogo.slide#3
An interesting similarity:
>We had our own C compiler just to compile the runtime.
The Bun team maintain their own fork of Zig too
The problem with vibe coded re-writes is that you basically sign off on understanding the generated codebase at that point. Any historical knowledge of the codebase is gone.
Linked commit is probably not the most convincing for this tagline. Here's a branch[0] of Claude mass rewriting Zig code into Rust which is currently at 773,950 additions and 151 deletions:
[0]: https://github.com/oven-sh/bun/compare/claude/phase-a-port
I wonder if a successful, albeit slower, approach would be to walk the git commit history in lockstep, applying the behavioral intent behind each commit. If they did this, I would be interested in knowing if they were able to skip certain bug fix commits because the Rust implementation sidestepped the problem.
Why not rewrite claude-code in Rust?
So, Anthropic acquires Bun team because claude-code uses Bun. They port Bun from Zig to Rust presumably because Rust "is better" (imagine big air quotes here). Again presumably, they want to make claude-code "better". Why make it so complicated? With all the power of LLMs they have, surely they can make claude-code the best possible by writting it in Rust directly.
Given the recent gripe that Bun/Anthropic indicated regarding compile times with Zig (i.e. that their vibe-coded 4x compilation speedup PR wasn't accepted), it appears to me as an "interesting" move to switch to a language that probably delivers 4x longer compilations than even vanilla Zig.
I want zig to succeed but given that zig is not yet 1.x I'd imagine a large code base like bun would have difficulties addressing major breaking changes. Also given the fact that bun is using a fork of zig https://x.com/bunjavascript/status/2048427636414923250?s=20
Picking a pre 1.0 language to build your product always seemed like a bad choice to me. Purely on that basis and ignoring the recent drama this seems like a reasonable idea for tech debt pay down to me. Assuming automated conversion can work without making things worse, which is not exactly a given.
I'll be very interested in how this AI port turns out. I am involved in a number of active projects that are being held back by the language / framework is holding back the project, but where a rewrite would be too big of a project to undertake by using only human power.
I've had more success vibe coding Rust than I have in more dynamic languages. I suspect the strictness of the Rust compiler forces the AI agent to produce better code. Not sure. It could be just that I am less familiar with Rust so it feels like it's doing a better job.
At this point, it looks just like an experiment. It's not a definitive "were going to switch".
I think people here are reading too much into it.
Why? Are there particular reasons that the maintainers of Bun feel the need to attempt to migrate from Zig to Rust?
So I can't tell if the linked commit is an actual attempt or just an experiment but it did always strike me as odd to make a JS runtime in Zig when my impression was there were a lot of work-stopping compiler bugs at the time.
Given they have "unlimited" AI usage, do we expect the port to be complete tomorrow?
Comparing this claude/phase-a-port branch with main: “Showing 1,646 changed files with 773,950 additions and 151 deletions.”
When I first heard that bun was written in zig, I thought that was an odd choice for such a large project, mostly because the language is "unstable" and is still making significant breaking changes.
I would guess dealing with breaking changes is a big motivation for this.
If nothing, it'll be good marketing material targeted at non-technical enterprise executives so that they pressurize their engineering teams in meetings that look people are porting such complicated things from one different language to totally different language then why are we not using AI effectively?!
The only Bun shipped product I've used in anger is OpenCode and I regularly run into segfaults on it. I doubt this is the reason for migration but every time it happens, it reminds me the real cost of unsafe code. That being said, Zig is an absolute pleasure to write and I can't wait until it has a real library ecosystem, Rust's greatest boon.
For better or for worse, at least Bun is open source, and the world is not lacking a NodeJS alternative.
What is the most interesting here for me is:
- a big, clear outcome and acceptance criteria, vibe coding project on
- a public, working, high performance, full featured, production codebase by
- the leading LLM model maker known for the strongest coding ability
A good example no matter if it successes or not.
I am also porting TypeScript to Rust. With a different design I managed to make it faster than tsgo port. I've made a lot of progress in the last 4 months but needs more work. Contributions are welcome!
https://tsz.dev
https://github.com/oven-sh/bun/issues/30197
It seems there was an issue where the image API ignored the ICC Profile.(now fixed) Any developer with experience implementing image formats would almost certainly avoid this mistake. This is a problem that cannot be solved with vibe coding. In this situation, the user is merely a guinea pig for bug fixes.
Rewriting it using an LLM is one. But did all the contributors became as proficient in Rust as they were in Zig over night as well?
Its never been easier to rewrite X in Rust than today.
Will everything eventually be rewritten in Rust and we finally achieve utopia?
Bun can't be used for anything serious, only as a "script kiddie" to run small scripts.
Trying to run it as a replacement for node in persistent backend/api scenarios is just plain broken.
RSS grows unbounded under Bun: https://discord.com/channels/876711213126520882/148058965798...
I suspect that an experiment is being run. In any case, that'll be a hell of a story!
Just checking some loc numbers from nodejs, bun and deno:
On nodejs: `tokei src`: 98333 LOC C++ Code
On bun: `tokei src` 573572 LOC Zig Code
On deno: `tokei libs cli runtime` 289573 LOC Rust Code
This seems wrong though so would be appreciated if someone who knows the structure of these projects can correct me on the folder names.
Doing `tokei lib src test deps` gives more than 5M loc. but not sure if that is fair
This is a huge loss for the zig language and community.
As a fan of the language, I hope it leads to some reflection on things that might need to change moving forward.
That PORTING.md file is massive and seemingly comprehensive. Was that AI written as well? Is there a general Zig to Rust porting template being used?
Didn't they write a whole blog post on why they chose Zig over Rust?
Could just be an experiment or something. It's Monday, the week is young
Having written a JavaScript runtime in Rust in the past - Rust is an excellent choice. Not just due to the development experience, but also for embedders who want to consume the project as a a library (rather than a binary, e.g. node).
Not sure about vibe-coding it. While they aren't using v8, LLMs made it easier to understand v8 quirks and update v8 as they make weird changes every now and then. It couldn't write the runtime without help though.
For those curious: https://github.com/alshdavid/ion
https://x.com/bunjavascript/status/1966806250827714736
Haha, is it really okay not to retract that that the official account previously posted a caricature criticizing Rust?
Maybe Mythos told them to quit using zig because it is not safe
this isn't vibe coding. this is vibe rewriting. ~500k lines of code. nobody is reading those diffs line by line. nobody.
I mean this is self-evident. Bun got bought by Anthropic to shill in the open source space:
https://bun.com/blog/bun-joins-anthropic
"I got obsessed with Claude Code"
So the bad, bad Zig that opposes the clanker mania has to be punished, even if top comments deny it.
Anthropic is one of the most evil companies in existence today. Whenever someone produces something, they steal it.
Let the guy cook, would be nice benchmark of llm nothing else. Damn I wish I had access to infinite tokens for crazy experiments like this.
Probably a good thing for the project even if the only net positive ends up being the Bun team stops maintaining a fork of Zig.
I think they are simply experimenting to fully exploit Claude's models' powerful capabilities.
Alright, back to node.
I was hopeful for this project, and I've reported crashes & bugs in the bundler with the hope that it will stabilize over time, but this is just silly - I'm not going to risk them pulling the rug under me and replacing the runtime with 1 million lines of vibecoded rust.
This feels more like a reaction to Zig's anti-LLM policy than anything. Anthropic would probably like to contribute something back to Zig at some point, but I doubt anyone would ever believe their PRs were not written by Claude.
I can't imagine going from reviewing code in Zig to letting Claude code handle it in Rust. Seems like a lot of change to deal with in a short amount of time. Wonder how much the bun team culture will change? We've been really liking bun so far
Unexpected, I was waiting for them to maintain a zig fork
Which makes one think, why they did not buy deno at first place then?
If they did, I guess they would rewrite deno in C++
oh for christ’s sake
Aside from Zig's anti-AI stance and maintaining their own Zig fork, I think this port will showcase that Anthropic can re-engineer a massive codebase.
As an aside, I've been bitten by Zig's breaking changes on my own projects as well. It's taken the shine off of Zig and I'm looking at alternatives.
Claude Mythos cannot do the porting?
Poor Zig - it's bleeding now.
Everyone wants to be a Rustee these days.
"Claude, migrate bun to Rust, make no mistakes"
Any confirmation that a genuine port is underway? This might just be an experiment.
I am not a fan of AI but my limited experience with running local small LLM's did show me that rewriting some scripts into a different language worked really well. So my guess is this will just turn out fine.
maybe anthropic should‘ve just acquired deno
How well does that long translation prompt work?
Interesting. What are the main trade-offs they expect from the switch?
I hope they ship and use this. It’ll be a super interesting case study in a few years.
the days are not far when golang will be ported to rust.
Here we go again ...
Company A buys company B. A's management decrees the henceforth B's aqcuihired team must comply with company A's standards.
Second system effect kicks in. Bugs multiply.
Half of original company B devs leave.
I'm investigating whether future projects should revert to using Deno.
> Read this whole document before writing any code.
Hm does that actually work?
Edit: in a way that can be verified, and not the AI tool saying it did
April 26th - Bun announces they used AI to fork Zig so they could make an optimization for a 4x improvement
April 27th - Zig contributor mlugg clarifies why the specific optimizations Bun did were ill advised and wouldn't have been accepted in Zig, regardless of AI use [1]
May 4 - Bun is looking into Rust as an alternative.
This, to me, seems like total whiplash. Has anyone at Bun made a statement on why they're making such dramatic changes? It seems like the lesson to internalize from mlugg is not "switch to Rust"
[1] https://lobste.rs/s/ifcyr1/contributor_poker_zig_s_ai_ban#c_...
Interesting. When I thought of Zig, I thought of Bun. In my mind it was the flagship application for that language. Is there another? I wonder how the Zig team feels about this. To me it seems like Rust has definitively won now.
>*No `tokio`, `rayon`, `hyper`, `async-trait`, `futures`.* No `std::fs`,
I'm not a rust dev but even I kind of notice that tokio is kind of shunned in most projects. Why is that? Is it just bad or what?
instead of writing it once in C++
it will make it more portable.
what a win
I guess it's like Trump saying, "I'll take Greenland too..."
Makes sense on merit. There really isn’t room for Zig when Rust exists, is more ergonomic, and also safe.
you can use both zig and rust in a single project, duh
People are asking why they would switch from zig to rust. I wonder the opposite: why would anyone would use zig over rust?
hahaha eat your heart out "don't port it to rust" gang
I fully support this decision