Auditing the Rust Port of Bun: Navigating 13,000 Unsafe Blocks

The transition of a high-performance runtime from one systems language to another is rarely a trivial task. Bun, originally written in Zig, has been undergoing a port to Rust—a move that has recently come under scrutiny following the release of a comprehensive, albeit controversial, codebase audit.

Before the Rust port ships in a released build, the Bun team conducted a pre-release pass to quantify and categorize the use of unsafe blocks. The results are striking: the current port contains 13,365 unsafe blocks. While the number is high, the audit aims to provide a roadmap for reducing this technical debt before the code ever reaches a production user.

Breaking Down the 13,365 Unsafe Blocks

The sheer volume of unsafe blocks in a Rust codebase often triggers alarm bells for developers, as unsafe is where the compiler's safety guarantees are suspended. However, the Bun audit argues that the majority of these blocks are not inherent flaws, but rather artifacts of the porting process.

The Root Causes

According to the audit, two-thirds of the unsafe sites stem from three primary sources:

  1. The Zig Port: Many ownership idioms and patterns carried over directly from the original Zig implementation.
  2. The FFI Boundary: Necessary unsafe blocks required to interface with C/C++ libraries and external engines.
  3. Performance: A small fraction (approximately 3%) of the unsafe blocks are intentionally used to squeeze out maximum performance.

The Path to Safety

Bun's goal is not to eliminate all unsafe code—which is virtually impossible for a runtime interacting with low-level system APIs—but to minimize it. The audit categorizes the blocks into two main outcomes:

  • Replaceable (~9,300 sites): These are blocks that can be converted to safe Rust code. The audit identifies patterns like raw *mut Self state machines and &self to &mut casts as primary targets for removal.
  • Permanent (~4,000 sites): These blocks will remain unsafe, though the plan is to wrap them in safe abstractions to ensure that undefined behavior (UB) cannot be triggered from safe Rust.

Soundness vs. Count

One of the most critical findings of the audit was the discovery of five functions that were fundamentally unsound. These are cases where undefined behavior was reachable from safe Rust—actual bugs that existed independently of the 13,365 unsafe blocks. The audit's first priority is fixing these soundness holes before addressing the total count of unsafe blocks.

Community Reaction: "AI Slop" and Technical Skepticism

Despite the detailed breakdown, the announcement has been met with significant pushback from the developer community on Hacker News. Much of the criticism centers on the fact that the audit page itself is labeled as "AI generated," leading to accusations that the port itself may be the product of AI-driven translation rather than manual engineering.

Critics have expressed skepticism about the level of trust one can place in a port that requires such a massive cleanup effort. As one commenter noted:

"The port is AI slop, littered with 13k unsafe blocks. and this blog post is more AI slop, claiming to present a 'plan' for how to reduce that number."

Other developers questioned the wisdom of a wholesale port of a complex system, suggesting that a piecemeal approach—migrating individual components to production and testing them in isolation—would have been a more stable strategy.

Conclusion

The Bun Rust port represents a massive experiment in language migration. By being transparent about the number of unsafe blocks and providing a public audit, Bun is attempting to demonstrate a commitment to Rust's safety guarantees. However, the gap between a high unsafe count and a "safe" implementation remains wide, and the community's reaction suggests that the technical debt incurred during the porting process may be a significant hurdle to overcome.

Sources