Is the Bun Rewrite in Rust Actually Done or Just Hype?

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.

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 […]

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.

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.

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.

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.

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.

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!

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.