Bun Was Rewritten in Rust. But the Code...

追加: 2026-05-19

[00:00:00]I think the story is actually really exciting for human-driven software development. In 2009, Ryan Doll released Node.js and Node.js allowed the legion of front-end JavaScript developers to start writing serverside logic in JavaScript. To say that Node.js was embraced by the industry is a massive understatement. In 2012 though, Ryan left the project. But in 2018, he released Dino, another JavaScript runtime written in Rust that was significantly more performant than Node.js. Dino. Notice it's an anagram of Node. just rearrange the letters.

[00:00:30]Clever, right? In 2022, Jared Sumner released a new JavaScript runtime called Bun. Out of the gate, it was far faster than Dino. And much to the dismay of restations, it was written in Zigg. Now, fast forward to December of 2025.

[00:00:44]Anthropic acquires Jared Sumner's company Oven. Apparently, the infrastructure supporting Claude runs on Bun. Okay, that makes sense. Not much news for a little while after that. But then on May 4th, 2026, there was a disturbance in the force when it became known that a complete Rust rewrite of Bun was happening. Okay, that's pretty interesting. Maybe if they work fast, they'll get it done in only a year. So that would be May of 2027.

[00:01:08]That would be pretty impressive. On May 5th, Sumar stated on Hacker News that the rewrite is just an experiment and that there was a very high chance that this code gets thrown out completely.

[00:01:19]The branch was called Claude/phase A port, seeming to imply that Claude was playing a large role in the port. On May 9th, Jared reported that 99.8% of Bun's test suite was passing for the Rust rewrite. He also shed some light on the rationale for the port. Seems like memory leaks and stability issues were the main inspiration. Now's not the time to say, "I told you so." Let's be mature about this, okay? We'll bring it up later. Then all of a sudden, on May 14th, the experimental Rust branch was merged into the main branch. To be clear, that doesn't mean it was released, but it does mean that you can't install it using the bun upgrade- canary command. Maybe by the time you watch this video, it's been released.

[00:01:58]Looking through the comments, the skepticism is not hard to spot. Let's talk about what the code looks like.

[00:02:04]Because onlookers were quick to point out that the Rust code can't be described as idiomatic and it's full of unsafe blocks. Doesn't that negate the benefits of switching to Rust? There's this file in the repo called porting.mmd that kind of gives us some insight into what the original strategy was. It says the goal of phase A is to draft RS next to the zig that captures the logic faithfully. It does not need to compile.

[00:02:25]Obviously, that part's a little bit out of date. Things seem to be compiling and actually working. It seems like one requirement is that each.zig file result in a RS file with the same base name and it must reside in the same place of the directory tree. This requirement alone seems like it would make writing idiomatic Rust pretty difficult. No.

[00:02:42]Tokyo rayon hyper async trait futures so on and so forth. No async functions.

[00:02:48]Unsafe is fine when the zigg was already unsafe. So that's where we get these unsafe blocks. Presumably this is what was fed to the language model when they were prompting it. Um and so this kind of explains the state of the code.

[00:03:00]There's a lot here. It looks like they actually for some things they actually made a translation guide. They give the zig version and then the rust version.

[00:03:07]Yeah. And like a there's a even a type map. So if it's this type in zig make it this type in rust. That makes sense. Oh, okay. And an idiom map. Yeah. So, you see this? You see this pattern in Zigg.

[00:03:17]This is what you should do in Rust. This this makes a lot of sense for a uh a translation project. Yeah. The goal here is not to get idiomatic Rust code right out of the gate. And I suspect there are two main reasons for this approach.

[00:03:29]Number one, it has a better chance of preserving existing behavior because there's not as much potential for things to get lost in translation, so to speak.

[00:03:36]Translating big chunks of logic from language A to language B and incorporating the idioms of language B seems far more likely to lead to things slipping through the cracks. Instead, it's see this line or several lines of Zigg, translate that directly to Rust. I actually think this is a pretty smart approach. First, switch languages and validate that there were no regressions because that's the part that can't really be done incrementally. Once that's validated, there can be a more incremental transition to Rust idioms.

[00:04:02]Imagine what you'd have to do if you waited until the Rust rewrite was idiomatic before you merged. Every feature, bug fix, and so on that went into main would also have to go into the Rust branch. And that sounds like a nightmare. So yes, if your criteria is strictly idiomatic Rus code, then by that standard, the code is a mess. But I think they're taking the right approach here. Now, does this prove that AI can turn one prompt into a 700,000line project and software developers are cooked? No, I don't think so. A plain English prompt still can't build a complex 700,000 line project from scratch, even with today's frontier models. But if you have an existing implementation that you want to migrate to another language, that door seems more open than it's ever been. Even if your project is large, think of the new freedom this gives teams who are agonizing over which language to start a new project with. The language decision new projects face is now a two-way door because with a reasonable amount of effort, it can be reversed later. That means developers have more freedom than ever to pick newer bleeding edge languages because there's always the option of migrating to something stable if they run into issues in the future.

[00:05:08]That is my biggest takeaway here.

[00:05:09]Language models now empower developers to be more bold when choosing a language. If the original language is no longer serving the project's needs, swap it out. If a new language comes along that has something the project needs, migrate to it. Speaking of newer languages, as in languages created in the past two decades or so, check out my video on the Nim programming language.

[00:05:29]Thank you all for watching and I will see you in the next one.