We put the Bun Rust rewrite in production

10 points by sorenbs 22 days ago | 1 comment

At Prisma we've been working on a Compute offering to complement our hosted Postgres. We settled on Bun early in the process as we liked the experience we'd be able to provide thanks to Buns batteries-included approach.

But then we started using Bun in anger, and we found many memory leaks in the Bun internals, that we knew our customers would face as well. Prisma Compute is operating long-running services, utilising memory snapshots to pause the instance when not in use. We need these Bun instances to be able to reliably serve customer workloads for days and months.

We were able to fix some of these memory leaks directly in the code base, but getting the patches upstreamed proved difficult. And running on a fork with an ever increasing number of patches wasn't an appealing option.

And then as our Beta launch approached, Jarred announced the big rewrite (prior discussion: https://news.ycombinator.com/item?id=48132488)

We have found that the rewrite directly addresses several of the memory leaks we had identified. And we have found the new Rust codebase to be easier to contribute to. So we made the decision to launch on Bun Canary and do whatever we can to help improve Bun.

We wrote about it here, and you can have your agent of choice deploy an app in just a couple minutes if you want to give it a try. It's Beta, so we are still busy polishing the experience: https://www.prisma.io/blog/launching-prisma-compute-public-beta

aqrln 22 days ago |

Other than memory leaks, we also saw a bug in Bun.SQL's connection pool that would consistently lead to deadlocks after restoring the VM from scale-to-zero. It was also fixed by the Rust rewrite/translation.

Overall, the empirical evidence we got clearly showed that the Rust version was much more stable and reliable.

There was a lot of discourse on the internet about the trustworthiness of the automatic rewrite, but my understanding is that it was essentially a glorified machine translation and not a re-implementation from specs and tests, akin to using Google Translate or DeepL but for code. Of course it's a simplification, and I'm looking forward to reading Jarred's upcoming blog post about all of the non-trivial aspects of it, but it's still essentially the same code, largely written by humans and translated by an LLM. The main differences are the bugfixes that the codebase got for free thanks to Rust having destructors (a lot of Bun's bugs and memory leaks seem to have been caused by manual resource management in Zig), as well as whatever issues the Rust compiler found even in the non-idiomatic code.

One valid area of concern is the amount of unsafe code and it potentially adding new kinds of UB for things that wouldn't have been UB in Zig, for example, by converting raw pointers to Rust references and inadvertently violating aliasing rules. As long as those things have been audited for, I wouldn't be any more concerned to use the rewritten version than the original even if basically nothing else was reviewed. And as long as the code is being refactored to get rid of those unsafe blocks and refactor it to idiomatic Rust in reviewable chunks, the surface area for bugs will continue to shrink and more pre-existing bugs will be uncovered and fixed.