Rewrite Bun in Rust has been merged

Same since they own Bun, they have every incentive to make this seem easier than it was.

I'd also be interested generally in how much tacit knowledge was needed to come up with these rules and how much iteration on this file was needed, for example how many of the rules here came from a failure case hit as part of iterating on the translation.

We got told that someone wrote a huge, sophisticated driver in Rust in a single day using Claude Code. This is being pushed as a case of AI doing something that we encounter on a regular basis, way faster than a human could do it.

Some ommitted details: Turns out the official spec for this driver is written in C, and the standard has a massive official suite of unit tests.

It would be _so_ easy to alleviate any doubt from this and hype up the IPO even more. They just need start a separate repo with all the hidden work they needed to do to prod the AI along, and let everyone replicate the results. After all, isn't that what all their customers are trying to achieve? A million lines of usable code in "7" days? Never mind the fact that it will also boost Anthropic's usage metrics as everyone tries to replicate it into their workflows.

If it was beautiful, they would've started with a blog post about this with links and instructions. Perhaps I will still be proven wrong and a blog post is being written as I type this.

Smart pointers weren't invented by Rust. If you write code in other languages with pointers you mentally model the same types already.

> and `bun_collections` Rust crate already exists.

This is wrong. It's part of the PR in the codebase. It did not previously exist.

Nonetheless, it’s a fact it would have taken much longer without LLMs, I’d say all possible.

I find this is a valid success story if you can look past the embellishments. More than that, it’s really cool, actually.

Is that the conspiracy?

bun_collections doesn't look much older than the porting guide.

> 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.

Maybe... it wasn't such an overreaction?

[0]: https://news.ycombinator.com/item?id=48019226

How can you possibly verify this, if a 1M line patch was written over 7 days? It's at best a hunch (vibes?), and at worst a lie.

https://github.com/oven-sh/bun/issues/29732

At home:

> 10428

Not accurate. Bun is a batteries-included JavaScript & CSS transpiler (parser), minifier, bundler, npm-like package manager, Jest-like test runner, as well as runtime APIs like a builtin Postgres, MySQL and Redis client. This is naturally a ton of code.

EDIT: I misread, sorry! You said "JavaScript interpreter wrapper", which is correct.

Yeah, Cursor did the same thing, bragging about how many lines of code they managed to produce for a semi-working browser, completely missing the idea where less code is better, not the other way around.

There's nothing unusual about a rewrite coming in with a similar LOC number.

False.

0 test files were deleted. 0 pre-existing tests were skipped, todo’d, or had assertions removed. 5 new tests were added in test.skip/test.todo state to track known not-yet-fixed bugs in the port that lacked test coverage before.

The merge changed 28 test files in total.

+1,312 lines

−141 lines

Most of that +1,312 is new tests.

The depth-of-recursion tests for TOML/JSONC parsers went from 25_000 -> 200_000 because Rust’s smaller stack frames (LLVM lifetime annotations let the optimizer reuse stack slots) mean 25k levels no longer reaches the 18 MB stack on Windows.

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!

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.

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.

I'm convinced the future of writing code is heavily LLM assisted

[0] https://tsz.dev

It was uncertain then, and not so uncertain now.

What? How?

You contribute to projects run by others with the understanding that others run the project, is this not the default assumption others have too when contributing to FOSS?

Is it disrespectful if my proposed feature was merged, but then later was removed because the maintainer just didn't want the feature anymore? In my mind, pretty clear it wouldn't, I'm only a contributor after all, not the maintainer or the person running the project.

It doesn't need to be rewritten because it was written well in the first place.

You definitely cannot!

If you can't trust your test suite to catch an automatic language translation you shouldn't trust it at all. :)

It seems to be used by anthropic as a way to shift the discussion window into it being acceptable that you yolomerge millions of lines.

If this has been merged, I expect that Bun-rust is good enough to power Anthropic's internal agents to do live testing.

did you read their Mythos paper? they're anthropomorphizing it like crazy. Maybe it's just cheap heat, but if they really believe the LLM is conscious..wew

However, doing it the right way takes a bit more time, involves community feedback, and doesn't produce headlines about huge codebases being rewritten by LLMs in just a few days, so ...

Hopefully that answers all your questions.

I don't understand the rationale behind how any project, especially of this magnitude, can seriously build something stable this way.

My consolation - and it could be pure cope - is that at least I am in the same boat as a huge company like Anthropic, and they surely wouldn't be stupid enough to also build their cli tools around something that they saw as risky.

feelsbadman.

No later than next week.

Imagine you want to monopolize programming by pushing LLM as an obligatory middle-men. Then people who can program without LLMs are direct threat to your business plan. It's time for us to start hiding. I'm cosidering adding `co-authored by Claude Code` to my hand-written commits and running Claude in useless loops to mock API usage.

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.

The people making Zig have said they don't want that.

Node.js is a distribution of the V8 JavaScript engine (the thing that executes JavaScript in the Chrome browser), along with a bunch of standard library code written mostly in C++.

Bun is a distribution of the JavaScriptCore engine (the thing that executes JavaScript in the Safari browser), along with a bunch of standard library code written mostly in Zig (and now Rust). Bun's standard library is in many cases compatible with or inspired by the Node.js standard library, but with some changes for convenience and performance.

My question is, if it's this trivial to rewrite Zig to Rust, and trivial in general to write Rust at all, why not just use Rust for your server side code in the first place? What's the value of continuing to use JavaScript and putting so much effort into the runtime?

Also at some point Bun was acquired by Anthropic. And some people feared that this will greatly influence Bun's development.

Let's see. $10T in market cap, a significant chunk of everyone's assets and retirement funds, are currently dedicated to AI build out because of the potential for AI like Claude Code, which is recently doing $3b in revenue, and built completely on Bun.

If Bun is able to successfully vibe code a complete language shift in this short of time, it much more concretely validates the potential of vibe coding / AI for the entire industry.

Defining specifications with the level of detail needed to build applications exactly as intended is not as trivial as it may seem.

> "Apparently if you build a submersible with carbon fiber you are a witch and need to be burned on a stake. But look we're making reliable trips down to the Titanic with no problems."

Realistically, this is a forum of experienced engineers watching a company make some extremely questionable but very flashy engineering decisions. There's going to be a lot of people standing around here going "gee I dunno, that seems questionable".

Personally, I think the rewrite will largely work - logically, direct translations from one language to another are pretty well within the realm of the few things LLMs should perform extremely well at. But I also think more information will come out showing this was much more bespoke than just prompting an agent to do the translation. This just feels too much like an ad for Anthropic, I think it's likely there was a lot more human involvement and planning than we are being told.

You've just learned that you can't do random shit and not get called out? Were you born yesterday?

Aside from the big marketing play, Claude not being able to easily generate zig code was probably a big motivator - it doesn’t make anthropic look good and it doesn’t fit into how they’re doing things

Also, you’re assuming that actual traditional maintainers even exist now. Likely it’s a smaller team of people running mythos agents with an unlimited budget and no real need to fully understand the code

Is it, really? I can't imagine how much money in tokens was spent to get something like this + Jarred's and the teams salaries to review/manage this.

Then I decided that software is of limited value without a team to maintain it. Not necessarily because they fix it, but because they represent a bunch of humans who collectively understand it and therefore give it more possibilities.

And now this. I'm not sure what to make of it.

Prev they have presence in 31 regions but now it's down to just 6

https://docs.deno.com/deploy/classic/regions/

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.

I had to literally force quit my browser because of how much it lagged iirc.

See jared comment [0]

If this helps bun and rust is a better lang for developing bun going forward with the help of claude. Then i think that is just fine.

I thought rust was making the codebase complex so zig won on speed and dx.

But with llm and a large codebase it seems like rust gives fewer bug and you can develop it faster & safer.

https://news.ycombinator.com/reply?id=48133519&goto=threads%...

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

I am in that post, defending bun.

I thought for sure the peanut gallery was overreacting. Especially when the concern was absurd - because who would do such an insance thing? Like, at the time I legitimately thought 'no way a project switches over in a few months'. Even as an absurd hypothetical, I couldn't even imagine the prospect of it being done in a matter of days.

Feeling really confused right now.

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

If it works out it’ll be a good study case for marketing.

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

It's entirely plausible that when that comment was posted, he doubted it would work well enough to keep.

(Sensible default for LLM code, btw. But sometimes it works great.)

Or do those protections only cover whiny open source developers upset about a chat bot writing blogs?

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

I'm sure there's lots of other large scale applications of AI, just not many/any projects that are open source and so high profile - with the changes being done so far.

Personally, in the past 3 months I've shipped about 2.3M lines of a legacy project migration, though the new codebase is Java + Oracle ADF because of reasons™ and instead of being an interesting codebase, it's more forms heavy and essentially acts as a front end for a large Oracle instance, think more CRUD than application runtime (with an upsetting amount of XML).

The difference also is that it wasn't migrated by using AI on every file, but rather dumped the DB schema into JSON, and converted the old form contents to a YAML intermediate format that describes what's in the forms and have been iterating ever since of creating code that generates code - basically AI assisted development of a codegen solution + AI assisted sidecars that get merged with the generated code based on markers, when something can't be automated that way and often times also AI controlled browser based testing (since Playwright is in the cards for everything, but not yet).

Seems to be going pretty okay so far, will probably take months more of iteration and fixes, currently the automated testing is taking a while because let me tell you - not only Oracle ADF is shit, but so is WebLogic, like fuck I'd be so closer to being done if I was allowed to pick Python + HTMX or even Java + Thymeleaf. That's still better than a team spending a year on the migration and getting like 10% of the way there.

Obviously there's no more details to publicly share, but the overall vibe is clear: as long as you can test any changes, you can iterate faster than without AI - and the code ends up being more readable that colleagues would often write. The problem is that people would squint at the suggestion of 100% test coverage previously so most code is even written in a way that is straight up not testable (and often nothing is decoupled from the framework properly and tests take way too long, both time and resources).

If you use Bun in production, does this feel like a well managed upstream?

I don't use Bun, I don't care that they are using an LLM (though it is impressive that this actually worked), but the project management aspects of this is just wacky.

In general, we never like to appeal to popularity (a logical fallacy), but why would you assume here that we would point to Bun specifically (or any project for that matter) [1] as an example of Zig’s quality?

We prefer to judge Zig’s quality on its own intrinsic merit:

For example, we subject the language through TigerBeetle to inordinate amounts of fuzzing, perhaps more than any other language (you could say Zig is lucky to have TB’s test suite aimed against it!).

Literally 1,024 dedicated CPU cores, 24/7.

Zig holds up remarkably well.

We also recently pledged $512K to the ZSF, together with Synadia.

These are the kinds of things we prefer to point to. Not hype, but real end-to-end systems engineering, and long term financial support, regardless of the language we choose to use.

[1] I picked Zig back in July 2020. At the time, the largest project was River, but already Zig was a phenomenal choice, and the years have only shown that Zig was probably one of the best design decisions in the development of TigerBeetle. It turned out better than I imagined.

This is just marketing budget.

Async Rust never left the MVP state

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