Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Just a couple more 100hr weeks of debugging, and the last 80% will be done :-)by CrzyLngPwd
- For me this is how all workflows with AI end up lookingif you really want robust products. Do whatever with AI, go fast (from the point of view of perception, initially) BUT it is not going to work without extra work.
and ho, the bloat, do not forget the bloat, which is technical debt towards the future.
I am not anti-ai per-se, but I consider the software I write as a prouct to add features to and maintain over time. So in this case I think it is not wise to say that bc you got something impressive fast you are done. Now you have bugs, architecture, bloat removal, and others...
Letting an AI manage all the workflow is a recipe for disaster in anything that is not strictly short-term. For this reason, I hardly code one-off scripts myself anymore and I hardly use AI for big things besides discussions with the prompt, reviews and snippets. For adding tests it can also be useful.
For full, long-term products, they try to sell agents, and tokens and the like. I think they do not work well enough what I tried. It always ends up as a bloated unmantainable mess.
Unless something that is totally autonomous (by this I mean 100% autonomous) and automated ever exists, I see writing software that can be maintained by humans still critical. As long as this exists, the productivity upper bound will be that of humans reviewing and driving the workflow, even if with AI support.
by germandiago - Many repeat the point of “$165k is cheaper than team of multiple engineers working on the rewrite for a year”, which I think is flawed — the team of engineers would have produced idiomatic rust, and it would take probably 100k+ of tokens more to make the bun in rust idiomatic rust.
- > produced idiomatic rust
I keep seeing this. What is "un-idiomatic" rust?
by irishcoffee - I doubt file by file rewriting takes as much work as rewriting and refactoring the code - especially at this scale.by tcfhgj
- > the team of engineers would have produced idiomatic rust
Not necessarily. Didn’t Microsoft port the TS compiler to Go and they did it by translating the TS? It wasn’t idiomatic Go.
by asp_hornet - Yes, and curiously many of the tellings of this story don't account for the costs of the human software engineers (Jarred and the other bun team members) who guided all of this work.
- IMO a team of engineers (presuming this is pre-AI) would have improved the existing Zig codebase, rather than spent time and money on a Rust port in the first place. In fact, I still think most teams of engineers would choose to improve what they have even now, circa AI.by nozzlegear
- Would they have, in a year? The general plan of attack would likely still be the same: rewrite it in rust while keeping the structure as similar as possible, no matter how unidiomatic, then adjusting the design to make it more idiomatic to rust. Doing both at once is much harder.by rcxdude
- I feel your estimate of tokens is a few orders of magnitude off, it’s on the low side.
I use more (albeit cached) when centering a div.
by Tinkeringz - They also would have produced a team of engineers that knows the Rust codebase.
- Everybody who has rewritten software understands the current phase: it mostly works, but there are always things to fix to make sure that there are no regressions, and the pressure is huge for any release.
I still believe it was the good decision, but I also know that I wouldn't be the first person to run the release in prod.
I think Jarred should start making release candidates instead of releases to take some of the pressure off.
by xiphias2 - This article could increase its credibility by being updated to acknowledge that Bun-on-Rust has been live in Claude Code itself since June 17th, and available as a canary release since it landed on main.
Rewrites of this scale certainly justify long canary release periods!
by simonw - I mention Anthropic dogfooding this in the article.by tomlockwood
- I'm not sure Anthropic even cares about "releasing" the next version. The rust one has been in use in Claude Code for more than a month now, used by millions of people, and that's as far as they probably really worry about it. They bought Bun for Claude Code and I doubt the open source project matters to them otherwise.by losvedir
- Anyone know why? Can’t CC run on any JS runtime?by rienbdj
- It's just a marketing stunt. They've got the ad for Claude-powered code rewrites, and that worked beautifully. Everyone got the message: spend big bucks with Anthropic to get rid of whatever codebase bugs you - please, think of the IPO!
If it was about Claude Code itself, they could have rewritten it. They keep saying they don't even write code any more, so it shouldn't even matter what language it's in.
by pornel - Why wouldn't they?
Bun is a major part of the web ecosystem, having it developed by them via AI, sounds like a gigantic pr win.
by epolanski - I very much doubt they would want to abandon the wider community. They do benefit from others using it.
To the contrary, I think any problem with this release would be jumped on harshly so they're being more careful than usual. There's not a rush for the community to move to 1.4 and any issues could poison the community trust.
by usef- - If that is really what they are concerned with, they probably could have just had Claude Code rewrite Claude Code in rust? That likely would be far more efficient than changing the language of your typescript runtime that ships to run your react-based CLI app.
I imagine the $800k or whatever this has cost is coming out of Anthropic's marketing budget, so they can make a big splash about it.
by mikeocool - The bun rewrite inspired me to be much more aggressive on porting code, rewriting code, or vendoring external dependencies to tailor them specifically to our needs in ways that doesn’t make sense to upstream.
I feel like it made me generally more ambitious in what I’d throw at a coding model, but also made me focus a lot more on our testing harness and keeping a lot of it at the boundaries outside the language specific parts.
Having been part of several huge rewrites before, some multi-year long, I definitely would consider bun’s rewrite an enormous success. To keep such a level of test and feature parity, and add improvements on top of it, is a massive engineering feat.
by Tehnix - I did suspect that the triumphalist pronouncements, and even the seemingly honest and forthright deep dive, were a little premature.
This is a key problem with LLM exuberance: it's very tempting to trade on decades of experience in software using LLMs, because one is tired of typing and manual figuring-out, it seems to work if you're competent, and the payoff is essentially immediate. The real bill comes in the mail much later.
by abalashov - >because one is tired of typing
I consider typing to be secondary to software engineering, but I do concede that for those cases that typing really is the bottleneck, LLMs can certainly be of value.
Those cases are rare, though.
by yuye - This is so real now that we have LLMs. The stuff I'm working on doesn't seem to exist in LLM training sets, but I still get tempted to try when I get tired of doing the tedious parts.by krupan
- I am fascinated by the discourse around this Bun rewrite. I read a lot of drama and personal accusations, there are pieces like this one trying to extract clues, and it seems everyone has a deeper ideological concern behind whatever they are trying to say. For this article, it seems to be skepticism towards AI and how successful it can be at replacing programmers. Other takes, like the one from the Zig maintainer, were also along those lines but more about the open source ethics and the future of that in a LLM world.
I am mostly bullish on AI capabilities, so from my perspective I don't see why we should be skeptical that frontier LLMs guided by experienced devs can translate whole libraries like that. Good follow-up questions would be how expensive it currently is to do so, and whether we will see people branching into all-in on AI versus no-AI camps as happened in this case.
by pu_pe - > so from my perspective I don't see why we should be skeptical that frontier LLMs guided by experienced devs can translate whole libraries like that
There's a laundry list of reasons to be skeptical about LLM results in general. The biggest one is that LLMs are excellent at creating output that looks right but is nevertheless still wrong.
In this particular case, there's also a specific reason: This is obviously a marketing stunt regardless of whether the claimed results hold up. Anthropic has a long history of just lying and making shit up, so any results are subject to extra scrutiny.
- > experienced devs
No one on their team had Rust experience
by vdfs - You see this response because the port of Bun from Zig to Rust does not have anything to teach us about Zig, Rust or porting between languages with LLMs.
There are so many non-quantifiable properties to evaluate of the 'before' and 'after' codebases. Choices and preferences to be had about languages, language porting in general, and LLM coding.
After all that, pretend we could have a clear convincing distillation of the port and want to go apply the lessons learned. If someone doesn't get LLM porting results as good as Bun did, or it cost them substantially more in tokens, then they're "holding it wrong." If someone is underwhelmed by Bun's results, then it was just a proof of concept and the models have gotten so much better in the last 6 months anyway you can't compare.
by dogleash - As a comparison point, someone decided to try to fix the issues in the Zig original and is now claiming sub-second build times, plus fixed bugs, by modernizing the codebase and sticking with best practices - indicating that all of the issues that justified the rewrite were self-inflicted and addressable.
https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
I have no skin in this game, and the Zig version is also using LLMs if that helps take the culture war out of it. But, it has always been true in my experience that someone who really understands a problem space can outcompete someone who just throws resources (in hundreds of thousands of dollars of token spend) at it.
by bendmorris - This looks like a meme or attempt at a joke.
> Bun is the quintessential AI slop project at this point. Inheriting that is no easy task. I don’t think any human should sacrifice their sanity untangling this mess of 600K lines of slop code. For that reason, I will not be accepting any human-coded contributions until I deem the project to be in a sane enough shape. It will likely require most subsystems to be rewritten.
They're refusing to accept human-authored contributions. They're using LLMs to do the work. The author says they'll use LLMs to de-slop what they think is slop, and humans are banned from contributing.
I don't think you should take this seriously.
by Aurornis