Bun's Rust Port and the New Reality of AI Engineering

When I first saw Bun's Rewrite Bun in Rust pull request, my first reaction was not "Rust wins" or "Zig loses". It was much simpler than that: this is the kind of thing that used to sound like science fiction, and now it is sitting in a GitHub PR.

The numbers are hard to ignore. More than a million added lines, thousands of commits, thousands of files, and a runtime that many people already use in real projects moved from Zig toward Rust at a speed that would have sounded absurd only a few years ago.

And yes, AI appears to be a big part of the story.

I use Bun in real applications, so I cannot look at this only as a spectator. I want Bun to be fast. I want it to be stable. I want it to keep being the lovely little shock to the JavaScript ecosystem that made package installs and test runs feel less like waiting for water to boil. So I read the news with both caution and excitement.

Mostly excitement.

What happened

Bun started life as one of the most visible success stories for Zig. That alone made it interesting. Zig is a young systems language with a very practical spirit: explicit memory management, fast compilation goals, C interop, comptime, and a general sense that low-level programming can be simpler than the C and C++ world we inherited.

I follow Zig partly because of Bun. Bun made Zig feel concrete. It was not just another language with nice ideas and examples on a homepage. It was powering a real developer tool that people could install, complain about, enjoy, benchmark, and ship with.

Then Bun's creator, Jarred Sumner, opened and merged a PR moving Bun toward Rust.

The PR description says the port passes Bun's existing test suite on all platforms, fixes several memory leaks and flaky tests, reduces the binary size by several megabytes, and keeps benchmarks between neutral and faster. It also says the architecture and data structures are largely the same, with no async Rust and few third-party libraries.

That last part matters. This does not sound like a handcrafted rewrite into a beautiful new Rust architecture. It sounds more like a close translation: preserve the shape of Bun first, then use Rust's tooling and compiler to make the dangerous parts visible and gradually better.

That may not be romantic, but it might be exactly why it worked.

Why I think this is a big deal

For years, language choice felt like a deep commitment. If a project started in C++, Go, Zig, Rust, or Java, the decision shaped its future. You could rewrite later, of course, but rewriting a serious codebase was expensive enough that most teams treated it as a last resort.

AI changes that calculation.

Not because AI magically understands everything. It does not. Not because a translated codebase is automatically good. It is not. But because AI is very good at a certain kind of work that humans often find exhausting: repetitive, structure-preserving transformation across a large surface area.

That is why Bun's port feels important even if the port still needs cleanup. The milestone is not that AI produced perfect Rust. The milestone is that a huge, real codebase could be moved far enough, fast enough, that the result could pass tests and become a serious engineering option.

The original human work still matters. In fact, it matters more than ever. Bun's existing architecture, behavior, and test suite are probably the real foundation that made this possible. AI did not replace all the years of engineering that came before. It stood on top of them.

But standing on top of existing human work and moving it into a new form is already enough to change software.

The Rust and Zig angle

I do not read this as a simple victory lap for Rust or a funeral bell for Zig. That framing is too easy, and easy framings are where nuance goes to take a nap.

But it does put pressure on Zig.

Bun's PR says memory leaks and memory bugs cost the team a lot of development and debugging time. That is not a small complaint. If a fast-moving, highly capable team using Zig still found memory management painful enough to explore a Rust port, other teams will notice.

Rust's promise is not only memory safety. It is memory safety with performance, strong compiler checks, destructors, ownership, a mature ecosystem, and a language that gives tooling plenty of structure to work with. Those traits are already useful for humans. They may be even more useful when AI agents are changing code at scale.

Zig still has real strengths. It is simple in places where Rust is famously not simple. It has an honest low-level feel. Its compile-time model is powerful. Its C story is excellent. I still like following it, and I do not think one port erases a language.

But if Bun's Rust version keeps the speed, reduces binary size, and gives the team better tools for preventing memory bugs, the question becomes uncomfortable: for many new projects, why start with manual memory management if Rust plus AI gives you enough speed and more guardrails?

That question will not kill Zig. Good languages do not disappear because one famous project changes course. But it will reshape the conversation.

The uncomfortable part

The community reaction has been mixed, and I think that is healthy. Some people are shocked. Some are excited. Some worry about code quality, review depth, and how much of the new Rust is actually idiomatic or safe.

Those concerns are fair.

A mechanical port to Rust does not automatically gain all the benefits Rust can offer. If large parts of the code rely on unsafe, then the port is not the end of the safety work. It may be the beginning. Rust can label the sharp edges, but people still need to remove, isolate, and understand them.

At the same time, that visibility is itself valuable. In Zig, many memory invariants are part of the discipline of the programmer. In Rust, the code has to say more of the quiet parts out loud. The ugly parts can become searchable, reviewable, and measurable.

That is one reason I am leaning positive. Not because I believe AI-generated code deserves blind trust. It does not. But because this port may turn hidden engineering pain into visible engineering work.

And visible work can be improved.

The new reality

What happened with Bun will not stay unique for long.

Other teams will look at this and ask different versions of the same question. Can we port this old service to Rust? Can we move this frontend to a new framework? Can we replace this internal DSL? Can we split this monolith? Can we finally attempt the migration that was always too boring, too large, or too risky to justify?

The answer will not always be yes. Sometimes AI will make a mess quickly. Sometimes the test suite will be too weak. Sometimes the old code will contain knowledge nobody wrote down. Sometimes the generated code will work while slowly becoming impossible for humans to love.

Still, the door is open now.

That is the part that feels historic to me. The successful outcome is not guaranteed, but the category of possibility has changed. We are entering a time where large-scale software transformation may become normal engineering work, not a once-a-decade rewrite story told around the office with haunted eyes.

I do not think programming languages stop mattering. They still shape how humans think, how tools reason, and how bugs appear. But language choice may become less permanent. A codebase may become less like a building poured in concrete and more like a city that can be renovated while people still live in it.

That is both wonderful and terrifying, which is usually how the future enters the room.

What I hope happens next

I hope the Bun team spends the next few months making the Rust version boring.

Boring is good here. Boring means fewer crashes. Boring means clear ownership. Boring means fewer unsafe blocks over time. Boring means the benchmarks stay fast, the binary stays small, and real applications keep working without developers needing to care that a historic rewrite happened underneath them.

If that happens, this PR will be remembered as more than a dramatic migration. It will be remembered as proof that AI can help move serious software across language boundaries while preserving enough behavior to keep going.

And if it does not work, it will still be remembered. It will become a warning about review, maintainability, and the danger of letting speed outrun understanding.

Either way, something changed.

We are no longer only writing code with computers. We are beginning to write code with systems that can read, translate, imitate, and reshape code at a scale no single person can comfortably hold in their head.

If anyone ever tells the story of our time, let them say we lived when computers stopped being only obedient tools and started becoming creative participants in the making of software. Let them say we saw the first strange mornings of that age, when the machines learned not only to run our programs, but to help rebuild them.