I'm curious how much this would cost a paying customer. Can you please give us an estimate?

Looking forward to the blog post. Do you plan to run both the Zig and Rust binaries side-by-side across a wide range of real applications (potentially shadowing in production) to weed out bugs?

I can hope this will lead to little to no memory issues in using bun as a web server

    git rev-parse HEAD && ag "unsafe" src | wc -l
    19d8ade2c6c1f0eeae50bd9d7f2a4bf4a2551557
    14865

I doubt it will end up as stable release very soon, but I'm happy to be proven wrong. I have some skepticism about this whole rewrite, Jarred Sumner has enormous internet following and it feels like an ad.

> I started looking at the commits, and it's basically solving the ,,tests not pass'' problem by changing the tests themselves

Not sure if these decisions were made by the LLM, but I've always felt that Claude is more prone to doing "shady stuff" like modifying tests than finding correct solutions to problems.

GPT/Codex is more honest in this regard.

> solving the ,,tests not pass'' problem by changing the tests themselves

https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed...

This is great! Just add a random sleep(1) to a test, don't worry about it, it's going to be fine!

> I started looking at the commits, and it's basically solving the ,,tests not pass'' problem by changing the tests themselves. The real work of making it working on programs that are already deployed will be just starting now.

Wow, This is definitely quite something for sure.

Can jarred comment about if he has read the commits or not too or respond to your comment, this has basically made me lose the small faith I had in what bun is doing if it turns out to be correct.

Merging a complete rewrite in another language in 9 days seems insane to me. Maybe I'm just too cautious but with something like this I'd split off as a separate binary and get some heavy use customers involved as testers first to see if it causes any unforeseen problems before slowly expanding it out.

I'd want to be pretty damn confident it won't cause any regressions before sunsetting the original codebase in favor of this one.

It seems it was an experiment at that moment, and that it went well? I do hope they release it under 2.x though, cannot imagine how a 1M LoC can break in so many ways, especially if what xiphias says is true:

https://news.ycombinator.com/item?id=48132902

The experiment might have turned out well, or the author might have spent enough time to bring it to a place they was comfortable.

Frustration moves mountains, I don't think this rewrite was done lightly.

I'm no believer... 9 days later... Lessssssgoooooooo wooooooooo <sunglasses and rave>

Well it was 9 days ago, at the time they were not confident, but maybe the results were insanely good.

> was just a lie to damp criticism.

Citation needed. Couldn't it just as easily have been one person being as suspicious of the task as everyone else seemed to be?

"We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely."

No matter how I look at this, it's churn for the sake of churn.

Even if the translation was free and into ideal idiomatic Rust (and it's obviously not - it's now Zig with Rust syntax) then this would be churn for the sake of churn.

At some project scale the language really stops being any limiting factor, and you're instead mostly dealing with working past past architectural decisions, integration of large changes, deep optimization, steering the codebase into alignment with project roadmaps and long-term goals, regression testing as features get introduced, maintenance of multiple release trains... Experienced software engineers mostly stop caring about simple things like the programming language choice at that point, because whatever issues come from that choice have already been resolved. What matters is stability, careful orchestration of large changes and a stable and comprehensive test suite.

not enough people are emotionally prepared for if it’s not going wrong even in the slightest

Yes, only LLMs from now on.

It's not that weird to end up with this when translating C/Zig/C++ to Rust. A first pass can use unsafe and then when the code is in Rust you can work on reducing the unsafe.

Trying to eliminate all unsafe as part of the rewrite, whether done by human or LLM, would be making too big of a change in the process of rewriting.

The benefit of using Rust is that you know exactly where the unsafe code is so you can handle it explicitly and deliberately to avoid issues by imposing carefully crafted constraints... oh.

The really interesting thing to do would be to ask the agents to submit the diff as a coherent patchset...

> "The codebase is otherwise largely the same. The same architecture, the same data structures."

And 6700 commits.

I don't know their reasoning (not much Rust) but this was on the front page last week:

Async Rust never left the MVP state

https://news.ycombinator.com/item?id=48019163

Least unstable js project

This PR appears to be over a million lines (though GitHub won't load for me).

Of course the quality is the real question. I haven't had amazing results with LLMs with Rust, but they're less bad at it than they are at Zig, which is probably the reason for the rewrite.

At least in this case the original code was written carefully by hand, so the design is sane, and now just the auto-translation is in question. Now it just needs to be battle tested.

Bun is now literally vibe-coded, that's your proof. And Bun developers will solely use LLMs at some point (pretty close to "vibe coding").

I don't know, there's been some pretty bad software mistakes, possibly bigger than a PR to convert an app to Rust:

https://en.wikipedia.org/wiki/Therac-25

Claude Code itself is purely vibecoded, both CC and Bun leads are saying that humans are not writing code at Anthropic anymore. It is amazing how much money they intend to squander, because it's all funny money to them, investors just give it to them hand over fist for them to burn. Developing wrappers around the model isn't even the hard part and yet they're going to burn themselves to the ground getting high on their own supply.

Maybe this is the best marketing trick for Claude Code ever. Maybe there was pressure from Anthropic to do this and prove the value. Even partial success is enough to prove the value, justify the value and usage, and AI dependency even further.

On the other hand they might be super confident in the results, and if it goes well they might use is as an example of how good claude is

Well, realistically as well, humans gave us softwares that are full of security holes (and bugs), which one have you seen that a human perfected on the first time around? Give AI some time as well to be fair.

Won't touch it with a ten foot pole.

My initial reaction was that this is pure insanity but in fairness this is a fairly 1:1 port of existing code, so the developer's mental model of it should still match fairly well.

For instance look at this Zig function: https://github.com/oven-sh/bun/blob/ed1a70f81708d7d137de8de0...

Versus this Rust version: https://github.com/oven-sh/bun/blob/ed1a70f81708d7d137de8de0...

I did pick that at random but it does look like the best case. I skimmed through a lot of the Rust code and there's a surprisingly small amount of `unsafe`.

Still pretty insane to merge this in such a short time with so little testing, but I can easily think of bigger software engineering mistakes. Hell it's not like Bun even needs to be commercially successful any more.

I for one am REALLY GLAD to see it consumes itself.