71 comments

[ 0.25 ms ] story [ 7.8 ms ] thread
If you’ve ever worked at a tech company you already know the answer without reading any further
Author here: An apology on the graphs, they just count rust files touched in commits, not total commits. So if there were two commits and one touched 3 .rs files and another touched 2, it'd be counted as 5 for the purposes of the graphs. I may fix this later but, yeah.
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.

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.
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.
Yes this is a typical case of showing results fast. I wonder what the cost for the remaining 10℅ of debugging and fixing all the bloat will be. Not so cheap I am guessing
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.
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.
> 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.

This post doesn’t make sense. It was rewritten in Rust. The rewrite itself is complete (no more Zig).

Various people have claimed that Bun in Zig had a lot of tech debt. If they’re to be believed, it seems natural to assume the rewrite does, too. Perhaps all this activity is paying down some of that debt.

(comment deleted)
I didn't follow the thing too closely when it happened. Sure, I was aware of the big picture. But wow, I didn't expect that after all this noise there still hasn't been a release? That's just crazy to me.

I shouldn't be surprised though, of course. Giving any credit or slack to a high-valuation LLM company is a silly endeavor.

I'm not sure how much insight we can glean from looking at the number of commits and release cadence here. In the aftermath of such a major refactor/rewrite, I would expect it to take some time to get back up to their usual development speed.

Jared and the other developers are new to the Rust codebase, even if the structure is largely familiar. They're also likely focusing on other priorities right now such as tracking down instances of 'unsafe', rather than making user-facing changes (which might encourage a release).

Bugfixes could encourage rapid new releases, but perhaps the rewrite simply hasn't been very buggy? As far as I know, those on the canary channel haven't reported any major issues, or even really noticed the change. So perhaps there's little reason for new releases right now, as the team slowly churns through the backlog.

> P.S. Anthropic’s C compiler and Cursor’s FastRender web browser haven’t had any commits for months.

I always assumed those were just experiments in capability, and weren't meant to be ongoing projects. I would hope that nobody is using them directly today.

The CI/CD costs are an interesting take, most of the rebuttals to AI ROI are something like “more code doesn’t mean more value!” but if you are charging per CI run then it actually does! Particularly with CI and extra testing being the main way to prevent the loops the AI companies are shilling from going off the rails
(comment deleted)
(comment deleted)
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.
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.

Why did they buy an open source project anyway? If is not “officially” supported why not fork and use? Claude code is probably the most used anyway
I really do not understand how software developer think anymore. Using a LLM to translate a project in a short time, is by itself incredible. Just like one-shot whatever office clone.

But what makes software is not the fast creation of a "product" but that actual development of its features. Figuring out how everything needs to work together, fixing the bugs, and the o so boring UI work.

I have used LLMs to create stuff like word clones just for fun. It was a disaster. Sure, it had the basic functionality. But the moment you started with page structure (harder then one non-stop scrolling page), tables, images, rotating, and so many details that make up just the basics of word. Not even the extended functionality. You see every LLM just fall on its face.

Sure, i can clone sqlite from c to rust. Hell, i may even get it to do all the tests 100%. But there is a 99% chance that the clone will be slower, as it lacks the years of optimizations from the original language. There will be new bugs because of the language changeover. There is a need for future support and fixes.

People threat software like its something it is not. But unlike the past where your clients question your sanity for charging 100k for a piece of software. Not understanding its not just about writing the code. Now those expectation are even more pushed forwards, because of articles like this.

I constantly see software being published on reddit that does X, Y, Z only for the authors to abandon it as fast as they vibe coded it. Because fixing bugs is NOT sexy. Even with a LLM at your fingertips. Dealing with nagging users, is not sexy. Dealing with security issues, is NOT sexy. Dealing with data structure / databases, especially as your system changes ... you get the point.

Not understanding to the core the software you wrote, is going to exploded in your face.

This is why these stupid "we rewrote X into Z with a LLM in Y days" mean nothing. Its one thing to get a head start using this trick, its another to actually learn the code of your rewrite. And dedicated the time into maintaining the port, growing it, fixing it. This is where a lot of software fails. But now this crap is out there, instead of the maintained version of Zig, now we have a unmaintained Rust version that clouded the airwaves because if people now search for it, those articles "X in Z days" will pop up.

What have we become ...

> Not understanding to the core the software you wrote, is going to exploded in your face.

Short-termism at its peak. Code maintainers will learn the hard way how to set the boundaries between ai-generated code, and human maintainable code.

I'd like more people to be writing about this, because I find it fascinating. I have my own private project that is heavily LLM-coded, just to learn about what it's like. It's amazing how everything is different yet everything is the same. Big complicated features can start working quickly and give a massive endorphin boost, but then fixing them up and integrating them in properly and polishing the UI? It all feels even more painful having experienced the heady thrill of the initial implementation. And things get to a point where you can feel the inertia set in, the point where things have gotten so hacked up that the LLM can't make any progress without creating an even bigger mess. It's the point where you have to go back and fix up the architecture, or scrap the whole thing and restart with a better plan, or a bit of both (rewind to the "last sane point"). It's like developing with a jetpack -- you can go way faster towards your goal, and you can slam into walls way faster and more painfully too.

I think there are tons of learnings to be shared about how to do this stuff, but it seems like it's all blocked behind arguments over whether AI is the best or worst thing ever, and penis-measuring contents about how to hold the tool. The net benefit is a very open question, and both the doom and gloom perspective and the AI booster perspective are valuable and have a lot of things right. But there's a dearth of information about what things work, what things don't, what happens in the process of using AI, how to adjust one's behavior and which of those adjustments is harmful even if effective.

But then, I'm part of the problem. I keep meaning to write up a series of experience reports, but it's a lot of work. More fun to vibe a new feature into existence, or to finally fix a UI wart...

As I understand it, bun was already vibe coded so nothing of value was lost in vibe porting it to a different language.
A fundamental miscommunication seems to be what part people are interested in. Just because I like to bake cakes doesn't mean I want to grow and mill my own wheat. Just because I like to make programs doesn't mean I want to tyoe code or learn the details of some library.
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.

This doesn't answer the question posed in the title unfortunately. I am none the wiser about how it's going. The author just speculates that the rewrite isn't actually complete.
I don't get it. Because they haven't cut a new arbitrary version number, we're denying it got done (in their perspective) and being used in a massive product already?

If you're being pedantic, no it's not "done," but nothing ever is.

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.

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.

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

Just a couple more 100hr weeks of debugging, and the last 80% will be done :-)
I'm gonna say it bluntly: I don't care about bun, never cared about bun and think nodejs is sufficient. The drama surrounding zig and rust still leaves me with a bad taste because I also don't like how nonsensical topics like that influence what we do and what we (have to) care about on a day to day basis. That is just my opinion!
the author wrote a whole blog post asking how the bun rewrite is going and the answer from the thread is: nobody knows, including the author
Maybe it would have made more sense for Anthropic to rewrite Claude Code in rust, and cut out the middle man (bun)?
Maybe their “TUI-over-React” team doesn’t want to get fired because of AI, either?
> I hadn’t seen the numbers for the CI/CD costs of Buildkite, and as you might have noticed from above, some PRs were written by Anthropic employees.

The leaked code of the claude had switch flag where claude pretends to be employee. You can't trust/expect that those PR's were authored by people.

> we’re approaching $800k in money spent on this rewrite.

That’s peanuts, if not the shells of the peanuts, for a project and company of this magnitude