Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

Background

Bun is a TypeScript runtime, like a faster NodeJS. Zig is a systems programming language, like a modern C. Bun was written in Zig until recently - one of the largest Zig codebases. Bun claims near 100% AI contributions. Zig allows 0% AI contributions. Bun was acquired by Anthropic, a leading AI model lab. Bun’s founder experimented with a massive agentic rewrite from Zig to unsafe Rust. That experiment was merged days later and is now the official version.

This situation is controversial on a few fronts, though apparently no one involved actually wants Bun to stay in Zig. The drama lives purely in the meta-discussion. The migration process itself is pretty interesting; I would consider doing something similar in the right situation.

Who to Believe

When people choose between Zig and Rust for their projects, they will naturally see the Bun situation as a data point. The fact that one of the biggest Zig users wound up reversing the decision feels relevant, regardless of the reasons. People will try to understand what happened, and decide which is more true:

• Anthropic/Bun story: Bun tried everything reasonable, and was still overwhelmed by memory bugs because Zig wasn’t up to the task.
• Andrew’s story: The Bun code is a mess because of their engineering decisions, including overusing AI agents to write and review everything.

I’d lean more toward the latter, but I suspect the dominant factor is more boring:

• Ray’s story: Faced with a legitimate challenge of memory bugs, there were several viable options. Management eagerly approved the Rust rewrite option because it was a great marketing opportunity to showcase their new Fable model, Anthropic already uses Rust, and Zig is openly against using Anthropic’s products. That makes fine business sense; it just isn’t a marketing story. The marketing needed to focus on how their AI was powerful enough to do this rewrite (even though it was not powerful enough to catch a use-after-free).

For better or worse, this baggage is now top-of-mind in the Rust vs Zig question. The situation tends to pit Jarred’s judgment against Andrew’s in the eyes of the community. Any face-saving exaggeration spoken through Anthropic’s megaphone could unintentionally affect Zig’s reputation. I can understand why, rather than leave well enough alone, Andrew would decide to… add some context.

Is This a Smear?

From my perspective, Anthropic is the party we need to hold accountable here. That’s what this is all about. Bun founder Jarred Sumner is getting caught in the crossfire in a sense. So is Zig. It would be nice if this could be discussed strictly on the technical points, and we’ll get to them. However, I don’t think Anthropic is making a technical argument; they are dealing in spectacle. Anthropic is using Jarred’s credibility to help sell their narrative. In responding to that, we’re commenting on his credibility. That’s messy. I don’t love it. Still, if reporting the things that someone says and does comes off as a smear, then maybe that behavior was part of the problem too.

The Meat Grinder

My first impression of the Bun project was the 2022 announcement, including this warning to recruits:

Oven is going to be a grind, especially the first nine months or so. If work-life balance means a lot of time spent not working, it’s probably not a good fit.

When I see a statement like that from a prospective manager, it says a number of things, not the least of which is “this person has no idea what they are doing.” A lot of reasonably good coders have never seen an example of a good manager, and have all kinds of weird ideas about what management is. Running at “crunch time” all the time is bad for health and bad for productivity. That is a robustly established fact about knowledge work. For some references, see the Human Factors section of Hillel’s Empirical Software Engineering.

My advice? Don’t work for people that brag about 90-hour weeks. Work for people who will defend your ability to sleep at night.

In Andrew’s piece, he summarizes what he’s heard from the grapevine of the Bun team’s experience: poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show. I mean… of course it was. The hearsay is essentially repeating what was announced publicly. Their job listing might as well have said, “now seeking applicants for total shit show.”

It’s bad form for us to say this out loud. We’re supposed to let the Tech Bros go on about how cutting corners is some genius productivity hack. Then the people that listen to them can eventually call us in to fix the results. It would be a great arrangement if I cared less about outcomes. It’s quite lucrative.

FWIW, I’ve used Bun a few times and liked it well enough. Cool tech is often produced in spite of bad work environments. I’m not the one saying that their environment resulted in a buggy unmaintainable mess - Bun is the one saying that.

Say Something Nice

The piece about the migration process is very cool, with details that are reusable. No complaints; I think that’s the real contribution here. I particularly like the honesty in explaining that this was a port to unsafe Rust, allowing a literal file-by-file migration to minimize risk, paving the way for redesign in future steps. That’s a sensible move explained well.

There’s some truth to the idea that language choice is becoming more reversible. This method will take its place among other types of rewrite automation with pros and cons. These techniques can be combined and further hardened with Formal Methods. DARPA’s TRACTOR (Translating All C to Rust) research program published a report this year which should cover the state of the art. My favorite book on software modernization projects is Kill It With Fire by Marianne Bellotti. As agents allow us more moves we can make with old code, we still need good judgment and communication in deciding where to go. Let’s talk about that next.

The Rewrite Rationale Is Fluff

These are the basic ingredients of explaining a technical decision:

• What is the motivation?
• What options did you consider?
• What are the pros and cons?

Here’s a great example by Richard Feldman on his decision to move the Roc compiler from Rust to Zig. I was initially shocked by that move (I’m somewhat fanatical about language safety), but ultimately his points made sense and this started my curiosity about Zig.

When the Bun rewrite was merged, I’d hoped to see a similar treatment. This is what we got instead, two months late:

• ✅ What is the motivation?
• ⚠️ What options did you consider?
• 🚫 What are the pros and cons?

For the aspiring tech leads out there: When you skimp on these ingredients, especially the “pros and cons,” you risk giving the impression that you approached the problem with one answer already in mind and are giving it a post-hoc justification. Maybe you have reasons that you aren’t saying. It feels dishonest.

All Pros, No Cons

Rather than a real tradeoff comparison, we get a “Bun is better in Rust” section covering only upsides. A change like this always has trade-offs; an obvious one would be build time. Typically when you use Rust for a large codebase, you are buying safety and paying in slower compilation. There’s no shame in that; it can be a winning bargain. In the past, this factor was important enough to Bun that they forked the Zig compiler to try and improve it. If we’re right that the Rust port increased build time for contributors, why not disclose that? It comes off as more credible to own the impact and the priorities that make it the right move overall. They also seem to be padding the list by mixing in other improvements they’ve made after the rewrite that aren’t really related to it.

They Didn’t Try a Style Guide?

Recall that the motivation was memory bugs. Definitely not Bun’s only source of bugs but a frequent one, causing four fix commits per week by my count. Painful. Theoretically, every memory bug represents a violation of some convention - an expectation of how this kind of object should be dealt with. Therefore it behooves us to establish a clear idea of what’s expected in what circumstance. We should try to use any language effectively for that matter; Rust style guides are a thing too, but manual memory management adds scope to the expectations we need.

How have other people solved this problem? Another flagship Zig codebase is TigerBeetle, a financial transaction database. It is not plagued by memory bugs; in fact it appears to be one of the most reliable databases in existence. They will gladly tell you that this is due to their TigerStyle approach and some innovative testing strategies. Worth a look! The word “style” might undersell it; it’s a whole engineering philosophy with Zig coding guidelines as one element.

Here’s a taste of TigerStyle:

All memory must be statically allocated at startup. No memory may be dynamically allocated (or freed and reallocated) after initialization. This avoids unpredictable behavior that can significantly affect performance, and avoids use-after-free. As a second-order effect, it is our experience that this also makes for more efficient, simpler designs that are more performant and easier to maintain and reason about, compared to designs that do not consider all possible memory usage patterns upfront as part of the design.

Clearly, if we’re weighing a rewrite in Rust, we’d first consider if we should use the current language differently. Here’s how Bun’s write-up presents that option:

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. How do you make sure the style guide is followed? Historically, code review was the answer with best-effort enforcement via linters & static analyzers.

I expected the next sentence to discuss Bun’s style guide, why it wasn’t working, perhaps how it evolved over time… nope. They seem to just pay lip service to the primary way the community addresses their problem, shrug their shoulders, and move on. Did I miss something? Over four years on a project of this size, it’s surprising they didn’t seriously attempt this if they experienced these problems. It’s almost like the project was run by someone who tries to hold all the context in their head and never have meetings. What’s more bewildering is that they dismiss style guides with hesitations that are refuted within the same paragraph.