- 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.
by stingraycharles
11 subcomments
- 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
by archargelod
1 subcomments
- 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
- 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.
by carpenecopinum
0 subcomment
- 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.
by selectnull
2 subcomments
- 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.
by tacitusarc
3 subcomments
- 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.
- 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.
- 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'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.
- Why? Are there particular reasons that the maintainers of Bun feel the need to attempt to migrate from Zig to Rust?
- 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?
by inkysigma
1 subcomments
- 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?
- 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?!
- 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.
by cropcirclbureau
1 subcomments
- 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.
by bijowo1676
2 subcomments
- Its never been easier to rewrite X in Rust than today.
Will everything eventually be rewritten in Rust and we finally achieve utopia?
by toledocavani
0 subcomment
- 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.
- 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.
- 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.
by anymouse123456
1 subcomments
- 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.
- I suspect that an experiment is being run. In any case, that'll be a hell of a story!
by holysantamaria
0 subcomment
- Maybe Mythos told them to quit using zig because it is not safe
by classicposter
1 subcomments
- 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.
by thatxliner
0 subcomment
- Didn't they write a whole blog post on why they chose Zig over Rust?
by apatheticonion
0 subcomment
- 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
by classicposter
1 subcomments
- 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?
by arthurcolle
0 subcomment
- Could just be an experiment or something. It's Monday, the week is young
by davidtranjs
0 subcomment
- this isn't vibe coding. this is vibe rewriting. ~500k lines of code. nobody is reading those diffs line by line. nobody.
by kadhirvelm
0 subcomment
- 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
- Claude Mythos cannot do the porting?
- Unexpected, I was waiting for them to maintain a zig fork
by ngoquocdat
0 subcomment
- I think they are simply experimenting to fully exploit Claude's models' powerful capabilities.
by notnullorvoid
0 subcomment
- 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.
- 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.
- 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++
by confessinator
0 subcomment
- 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.
- 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.
- 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.
- Any confirmation that a genuine port is underway? This might just be an experiment.
- oh for christ’s sake
by hiroakiaizawa
0 subcomment
- Interesting. What are the main trade-offs they expect from the switch?
- How well does that long translation prompt work?
- maybe anthropic should‘ve just acquired deno
- "Claude, migrate bun to Rust, make no mistakes"
by forrestthewoods
1 subcomments
- I hope they ship and use this. It’ll be a super interesting case study in a few years.
- > 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
by Capricorn2481
2 subcomments
- 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_...
by booleandilemma
2 subcomments
- 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.
by sergiotapia
11 subcomments
- >*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?
- the days are not far when golang will be ported to rust.
- instead of writing it once in C++
by GianFabien
0 subcomment
- 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.
- you can use both zig and rust in a single project, duh
by markovmodel
0 subcomment
- what a win
- it will make it more portable.
by lacymorrow
0 subcomment
- [dead]
by Amber-chen
0 subcomment
- [dead]
- [dead]
- People are asking why they would switch from zig to rust. I wonder the opposite: why would anyone would use zig over rust?
by nothinkjustai
0 subcomment
- Makes sense on merit. There really isn’t room for Zig when Rust exists, is more ergonomic, and also safe.
- hahaha eat your heart out "don't port it to rust" gang
- I guess it's like Trump saying, "I'll take Greenland too..."
- I fully support this decision
Hacker News