My Thoughts on the Bun Rust Rewrite

History

When Jarred joined the Zig community about 5 years ago, I described him as someone who had strong "beginner energy". That is, he moved fast and tried a lot of different stuff, jumping head first into problems that he was not yet equipped to solve, leading to mediocre outcomes in terms of engineering, but learning a whole heck of a lot in the process. I see it as quite a healthy attitude, particularly for young people and students. This is the best way to level up and learn new things.

As he focused his efforts on Bun he began to attract attention. JavaScript being the most popular programming language in the world, there are a lot of potential eyeballs on a promising new toolchain.

This attention could have been harnessed in a few different ways. For example, he could have easily achieved a solid living via crowdfunding, even for San Francisco standards. But having graduated from the Thiel Fellowship school of thought rather than university, he was essentially groomed from a young age into uncritically embracing the Silicon Valley mindset, and he took venture capital.

From the beginning, Jarred was appreciative towards the Zig project. He credited Zig on the Bun website for the project's performance achievements. He set up a monthly donation to Zig Software Foundation that amounted to $60,000 per year. He didn't have to do either of those things, but he did, and it was pretty cool of him. Even in his blog post that I'm referencing, he expresses what I perceive as sincere grattitude towards the Zig project.

However, once Bun became a VC-backed startup, he started racing towards the finish line. Now, instead of working on a free and open source project, learning and growing with the community, Jarred was running a business. It was at this point - when he suddenly became a manager - that this "beginner energy" started to hit differently for me. It's one thing to choose a poor work-life balance for oneself; a different thing entirely to demand it of others:

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

Fun fact: people talk to each other.

I talked to those who interviewed for a job at Oven. I talked to people who worked there. Those people talked to each other. Everybody talked to everybody. The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show, from an employment perspective.

Consequently, although Zig community members were eager to find work coding in Zig on the clock, most of the talent pool steered clear of Oven and Bun.

At the same time, a rift between Zig and Jarred started widening. His singular focus on productivity and his startup's exit strategy was increasingly at odds with my longer term vision for the Zig project. I remember he kept nagging me to drop all my other priorities and work on a Language Server Protocol implementation and VSCode integration, while I had bigger plans.

The main problem, however, was code quality.

The Zig team regularly checks in on our users' projects. We read source code to find out how the language is affecting users, we test changes to see how problematic breakage might be, and we check for performance regressions.

We became increasingly horrified at the programming practices we saw in Bun's codebase. Hacks on top of hacks. Abuse of assertions. Most of all, recklessly speeding past feature after feature with very little time taken for reflection and elimination of bugs and technical debt. Jarred was already writing slop well before he had access to LLMs. Now, it's not our business to police what our users do, but you may have noticed people screaming in our faces about memory safety constantly. You can imagine how we might want to put some social distance between ourselves and a project whose irresponsible software engineering practices invite the exact kind of criticism that people are eager to level.

We made futile attempts to guide them towards better programming practices. There were a few exceptional heroes who did their very best in a dysfunctional company. You know who you are. But you can't stop a rising tide.

By this time, we all felt at ZSF that Bun was a net liability, and this was before RoboBun became the #1 contributor. Along with the discomfort of the publicly presumed poster child for Zig programming language actually being the prime example of How Not To Write Zig Code, at some point they would sell out (let's be honest, their vague "sell some cloud something" business plan was a farce from the get-go), we would receive some negative publicity by proxy, and we'd stop getting that regular donation.

So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over.

The (re)writing was on the wall. Even within a couple days, we already suspected a Rust rewrite was coming. And we were rooting for it! The acquisition by a large AI company was a burden, because even the indirect connection of Claude being written in Bun being written in Zig caused not only a surge of drive by slop contributions, but also an influx of tasteless AI enthusists into Zig communities who had to be informed that it's antisocial to paste LLM output into forum posts. For a moment, I feared Zig's identity would become known colloquially as a programming language associated with AI.

When Jarred announced the Rust rewrite, we were ecstatic. It seemed too good to be true. I have to admit, I didn't think the technology was there, to pull off this stunt. But he did it, and now I'm metaphorically sipping delicious tea from a mug that says "It Tastes Like It's Not My Problem Anymore".

Addressing the Blog Post

The blog post is expertly written. It's almost like the marketing department of a trillion dollar company has a lot of money riding on this article.

I do have some bones to pick however.

There's a dichotomy being presented here where you have to either choose a "style guide" or a programming language feature in order to avoid bugs. The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it. You're not giving TigerBeetle nearly enough credit. Quite simply they put in the time to find and eliminate the bugs, they make an effort to maintain a healthy relationship with ZSF, and Bun did not do that.

The argument for shipping all the million lines of unreviewed code is that the test suite is good enough to catch everything. Then why are you saying you have so many annoying bugs in the Zig code? What happened to the test suite being sufficient to catch everything? It's not sufficient to catch bugs in Zig code but it is sufficient to catch bugs in 1 million lines of unreviewed slop?

Performance increase is attributed to LTO, which Zig has supported for all of Bun's existence. It used to be enabled by default until we ran into too many LLVM bugs, all of which also affect Rust. We probably tried to tell you to try enabling it and you didn't listen. We have good advice, damn it!

The post claims they were fuzzing their Zig code, while during our calls the whole Bun team told us that they were not fuzzing anything. This appears to be an outright fabrication.

The blog post outlines a bunch of engineering work done to reduce binary size, to better make the case that "Bun is better in Rust". But all that engineering work had nothing to do with the rewrite. I think this is precisely why it took so long for the blog post to come out, you were doing the engineering work that you should have done in the Zig codebase since the beginning. We've been trying to warn you about your comptime abuse for years. We even made this time report thing specifically for projects that need to audit their use of comptime/inline usage and compile times.

I noticed that you neglected to mention compilation speed. Zig compiler project is about 600,000 lines of code - roughly the same size as Bun before the rewrite, and I'm clocking 16s to build from scratch with a clean cache, followed by 90ms for each subsequent edit with incremental compilation enabled. What are the corresponding measurements of Bun post-rewrite?

What Did We Learn Here Today?

Zooming out a bit, I want to make a few things clear.

One, I'm genuinely grateful for the donations ZSF received from Bun. We spent that money paying contributors to work on Zig.

Two, I actually don't have any personal criticisms of Jarred. He has different taste than me, he wants different things out of life than me. But I think he's actually happy and successful exactly where he is. He figured out how to accomplish all the stuff in life that he wants. He gets to live out his productivity fantasy fever dream, he's probably already super wealthy. He has minor tech celebrity status.

Honestly, I think he did well for himself, and I don't wish him any ill will.

That said I'm happy that our business interests are no longer intertwined! As soon as the Internet stops arguing in public about whether the rewrite was good or bad for Bun based on the language choice, I believe that concludes our interactions.

¯\_(ツ)_/¯