Rewriting Bun in Rust

Join the discussion

• Hacker News
• > Historically, rewrites are a terrible idea.

  This changed for me over the last 5 years.

  The first scenario was joining a company where a software product barely worked. We did the traditional incremental refactoring / rewriting, but eventually learned how rotten the core was that rewriting from first principles was the best path forward.

  The lesson learned here is that the conventional wisdom probably only applies to rewriting complex but working systems.

  Then multiple scenarios in the agentic coding age. Between day jobs and hobbies I've reproduced major chunks of complicated software like Salesforce, Gmail, Pioneer Rekordbox with very lean teams.

  Much like the blog post, the trick is to get an excellent verification loop with a compiler, linter, and test harness / test suite around the core behaviors.

  It's feeling more and more that designing and implementing comprehensive test harnesses is the real work, once you have that let the LLM cook.

  by nzoschke
• I think the same, it's possible our job will morph into "coding agent herders". In this case I guess the test harnesses, linters, workflows, etc will be our herding dogs.
  by yomismoaqui
• Every time I've rewritten a major project I've made it smaller and faster while fixing all the major bugs and most of the minor ones. My current team has had similar experiences. I'd be curious to see what a Zig -> Zig rewrite of the same magnitude would have done for quality.
  by hansvm
• In what ways does Anthropic use Bun? I know it's used as the "runtime" for Claude Code, but rather than porting a million lines of Zig to Rust, why not just port Claude Code to rust and not need to bundle a JS runtime at all? Does Anthropic use Bun otherwise? Maybe for JS execution tool calls in Claude responses?
  by losvedir
• I’ve wondered the same. Especially because codex is written in rust.

  Why not just port Claude code over.

  But my guess is that maybe it doesn’t have as robust a test suite?

  This might embolden them to do it…

  by atonse
• "The blog post is expertly written. It's almost like the marketing department of a trillion dollar company has a lot of money riding on this article."

  -- Andrew Kelley

  https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...

  by dwdz
• Without accusing anyone of anything, I do think that this coming from the head of Zig, who gets a lot of negative publicity from the Bun rewrite (unjustifiably, it's a wonderful language) makes it harder for me to take this without wondering if there's some animosity that's really the main complaint.

  > Two, I actually don't have any personal criticisms of Jarred

  The author says two things that really popped out to me that you could say are "professional" and not "personal" criticisms, but I think they're still rude and contrast this statement.

  > Jarred was already writing slop well before he had access to LLMs

  > The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience

  Now, both of these may be true. I don't have any evidence though, so I don't know how to take it.

  All this to say, I'll take both of these posts without a ton of salt when it comes to the non-technical parts.

  by jjice
• That's the power of a strong test suite. LLMs excel when you have verifiable rewards. I imagine we'll get a lot more rewritten in rust projects in the future. Rust is also an ideal target for such rewrites as it offers a lot of verification (via its type system) and is low overhead with zero-gc. There's less and less reason to use GC'd languages in the agentic coding era.

  I think Rust is a locally optimal target for LLM coding, we might see a better language in the future, but I think Rust will dominate for quite some time.

  by theLiminator
• > There's less and less reason to use GC'd languages in the agentic coding era.

  Faster iteration, maybe? Rust's safety guarantee isn't exactly free (while still being very excellent) and does affect iteration time. I have a private project (>300K LoC) that has been translated from Python to TypeScript and the reason we couldn't use Rust was definitely the iteration time.

  by lifthrasiir
• Personally I don't care that they used AI to rewrite Bun to Rust. Even if 1.4 is not good enough it will probably get better over time.

  What has pushed me back to Node is seeing how amateurish the transition has been handled.

  - No LTS support for the Zig version regarding CVEs etc.

  - Huge bugs like the 3MB memory leak mentioned in the blog post abandoned in the Zig version to basically force people into the Rust version to fix their apps in production.

  - Zero involvement with the Bun community about such a major decision. One day it was "stop the drama I'm just playing with this" and a couple of days later "yolo merged to main".

  Jarred basically keeps operating as if he was a lone hacker working on his personal project.

  by pier25
• this reminded me of WoW classics: Leeroy Jenkins

  yolo!!!

  by vincnetas
• > One day it was "stop the drama I'm just playing with this" and a couple of days later "yolo merged to main".

  Yeah, that was beyond ridiculous.

  by jgalt212
• LTS is more relevant if there was any kind of compatibility that was broken. They still haven’t released 1.4 even though it seems to have gone extremely well by every metric in the wild, with tons of people using Claude code with no regressions in a month. Nothing to me suggests they’re being careless here.

  In fact, he had two adversarial reviewer Claude instances on every code change, every line. I don’t know a single human team that does two independent reviews of every line, except maybe the people that wrote space shuttle software.

  Also they fixed the memory leak. How does it matter what language it’s written in? At the end of the day, people use it to run their typescript code among other things.

  How many bun users care that’s it’s written in zig? I certainly don’t. I’ve been using bun for 2 years and I think I looked up zig once. It’s just not relevant.

  Did it get more stable? Yes. Slimmer? Yes. More performant? Yes. Is there any proof that it got LESS secure? No. The code has been out for two months. By now all the nay sayers would’ve found the smoking gun. They haven’t. How much more proof would you like that this was a resounding success?

  This is our new reality. The agents are so good that projects like this are in the realm of possible. That’s exciting.

  by atonse
• > - No LTS support for the Zig version regarding CVEs etc.

  Every release would have tons of CVEs and would take so much effort. E.g. the example from blog with memory issues. Better just think that Zig version was not there what comes to security. Use at your own risk.

  > Jarred basically keeps operating as if he was a lone hacker working on his personal project.

  They have right to do it, however. It is expected, especially if company owns it.

  by nicce
• Paying customers get LTS. Are any paying customers asking for a Zig branch LTS? Or are you expecting open source maintainers to do free work for no particular reason?
  by alexjurkiewicz
• 1.4 has no breaking changes from 1.3 so why would there be an LTS and any guarantees for people staying on 1.3? All known regressions have been fixed like any other release as far as I can tell
  by iknowstuff
• > Zero involvement with the Bun community

  Yeah. The human aspect of the transition was just incredibly bad. The person behind Bun has just demonstrated how much he values the community.

  But I'm sure he will build another community around this rewrite. After all, there is an abundance of people cheering "Rust rewrites".

  Until the new favorite language comes up.

  by egorfine
• To add more context around lifetime errors and TigerBeetle's particular style guide:

  >Many projects opt to answer these kinds of questions through a style guide. TigerBeetle's TigerStyle is an example in Zig and Google's 31,000 word C++ style guide is another. The challenge with style guides is enforcement.

  TigerStyle[1] is a bit more than just a style guide. The key rule for this discussion, uplifted straight from of NASA[2], is *static memory allocation*: all memory is allocated in the startup phase, and there's absolutely zero `alloc`s afterwrads . This plus crash only[3] design means that we never call `free`.

  This rule is self-enforcing and compositional, in Zig. There's no global memory allocator, so the code after startup simply hasn't the API to allocate. You can't circumvent this by accident. Of course, if the programmer is byzantine, they can stuff allocator in the global, or just directly `mmap` and `unmap` pages of memory, but, at our scale, we don't have problems with that. This is a similar in kind (not degree) to Rust, where untrusted code generally can circumvent safety guarantees, even without literally spelling `unsafe`.

  And, naturally, never `free`ing goes a long way towards solving many memory errors by construction. Empirically, they just haven't been a problem for TigerBeetle. It's hard to untangle contribution of static allocation in particular from everything else we are doing, but it would make sense for it to play a leading role.

  (As a footnote, we aren't actually do static allocation to avoid memory errors, we use it as a linter to check that every quantity has a known _logical_ static limit, the main property we care about)

  [1]: https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...

  [2]: https://spinroot.com/gerard/pdf/P10.pdf

  [3]: https://www.usenix.org/legacy/events/hotos03/tech/full_paper...

  by matklad
• By all accounts, TigerBeetle has been a tremendous success, congratulations! My understanding is that it has a deliberately fixed scope, which makes me wonder: how applicable would TigerStyle be in more general-purpose applications? If the system needs to, say, ingest arbitrary JSON documents ranging from 100 bytes to 100 GB, how would TigerStyle fare?
  by jrpelkonen
• It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this appears to have been a massive success, which is absolutely remarkable.
  by padjo
• Technology does not exist in a vacuum, nor does anything that is engineered. It's not this abstract stuff detached from the world.

  PEOPLE make stuff, people use stuff, and people are ultimately the ones who are going to pick and choose which stuff gets made, used, adapted, enhanced, and carried into the future.

  AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that.

  Assessed from the perspective of "technology in a vacuum", of course. it's a success. He did the thing that transformed the thing from one kind of stuff to another kind of stuff. It still does all the things it did before, and in many cases with better stats than it did before.

  Assessed from the human angle, and especially the angle of Bun as a community, I would bet money that this rewrite -- executed by nobody for nobody, built and maintained by machines, maintainable only by machines -- has killed the entire project.

  Maintainable only by machines, because anybody with any knowledge, experience, or investment into Bun as a platform, or who contributed patches themselves, or whoever had a question about how it works and went "Hmm, I'm gonna go into the codebase and take a look at how that happens", they all got slapped in the face and summarily kicked out of the tent with the rewrite.

  by afry1
• We also need to ask if the better is because of Rust, or just because the old was a mess and the language was good otherwise.
  by bluGill
• Well the rewrite has newly introduced many immediate and critical safety (as in Rust sense) problems. It's clear and obvious if you read the code knowing the basic rules of unsafe Rust. And don't be surprised if it doesn't appear as obvious to you or Jarred or Claude, because not knowing they don't know is the exact reason why they failed at it.

  And for the emotional aspect. I'm working as an R&D engineer and one of my recently assigned experiments is to evaluate replacing workers with LLMs, quality software with slops. Every bit of exaggeration they make is making my coworkers lose jobs and I'll be no exception. The entirety of me consists of reasons going against this kind of marketing compaign.

  by endospore
• There were/are absolutely plenty of real problems with the resulting code pointed out. Running Miri trivially found soundness issues, `SAFETY` comments that demonstrate that the model in question fundamentally doesn't understand/simulate understanding how unsafe rust works [0], etc.

  [0] https://github.com/oven-sh/bun/blob/fc865b398e51de8a95ddde4b...

  by lunar_mycroft
• > This Rust rewrite would've taken a team of engineers with full-context on the codebase a year of work. With 1 engineer using Fable & closely monitoring Claude Code, we went from start to 100% of the test suite passing on all platforms in 11 days.

  This is impressive from a technological standpoint, but it does gloss over the fact that it would have cost $165k in tokens were Bun not part of Anthropic.

  The comparison here isn’t completely fair - it would take a small team a year to port it if they spent $0 extra on it.

  I’d be interested to see a comparison between spending $165k in 11 days on Claude vs splitting that between 50 people over 11 days for a line-by-line rewrite of the Zig code. I suspect Claude might be faster and therefore cheaper, but maybe not by a lot.

  by dabinat
• $165k won't get you far on salaried engineers. There's every chance that 1 engineer, assuming Anthropic employs them, is on $500k or more. Assuming average of $336k in that pool of 50 engineers, then for 11 days for 50 engineers you've spent $710k[0].

  Salary info: https://www.levels.fyi/companies/anthropic/salaries/software...

  [0]The maths I used (posting because I'm tired and prone to mistakes):

      $336,000 / 260 (working days of the year) = ~$1,292.
      $1,292 * 11 * 50 = ~$710,769

  by Jenk
• Your example of using 50 people for this reminded me of the classic “Nine women can’t make a baby in one month.”

  HINT: those 50 people must be coordinated...

  by yomismoaqui
• I feel like a core difference is that the AI implementor can get cheaper/faster (and indeed _uniformly_ better), whereas it would be very difficult for the same humans to do so.

  Even if this is not the right answer today, it can at the very least serve as a herald of a possible future, no?

  by tekacs
• I think it'd take you at least eleven days to meaningfully coordinate 50 people!
  by Philpax
• > I suspect Claude might be faster and therefore cheaper, but maybe not by a lot.

  While Jarred used Mythos-class model, some open weights, if they were as capable (certainly, GLM 5.2 looks the part), would have been way, way cheaper than professionals.

  Approx costs:

    DeepSeek v4 Pro & Mimo v2.5 Pro   $3,426  ($2,567 / $600 / $259)
    Tencent HY3                       $3,892  ($1,180 / $552 / $2,160)
    GLM 5.2                          $30,016  ($8,260 / $3,036 / $18,720)
    Qwen 3.7 Max                     $37,925  ($14,750 / $5,175 / $18,000)
    Claude Opus 4.8 & GPT 5.5 xhigh  $82,750  ($29,500 / $17,250 / $36,000)
  
    5.9 billion uncached input tokens, 690 million output tokens, 72 billion cached input token reads.

  by ignoramous