Filed the original GitHub issue reporting that Bun's Rust codebase fails basic Miri checks and allows undefined behavior in safe Rust code. The framing implies this is a fundamental soundness problem, not a minor oversight, since safe Rust's core contract is that UB cannot occur without explicit unsafe blocks.
The editorial argues that UB in safe Rust 'is not supposed to happen' and that it almost always means unsafe blocks are violating their invariants, with those violations leaking through safe API boundaries. It characterizes Miri as table-stakes hygiene and suggests the failure indicates either missing CI integration or a deliberate decision to defer fixes — neither of which inspires confidence in a runtime that handles JavaScript execution.
The editorial emphasizes that Miri is 'not an exotic or experimental tool' but the standard, compiler-team-maintained interpreter for catching UB, and running it is considered basic hygiene for any Rust project using unsafe blocks or FFI. The implication is that a well-resourced, high-profile project like Bun should have had Miri in its CI pipeline from day one of the Rust rewrite.
The editorial contextualizes the issue as 'among the first public, technical stress-tests' of Bun's Rust rewrite, which was announced in late 2025 as a move toward better ecosystem tooling and contributor accessibility. The UB findings cast doubt on whether the rewrite is mature enough to deliver on its promises, particularly given the complexity of transitioning from Zig.
A community member opened [issue #30719](https://github.com/oven-sh/bun/issues/30719) on Bun's GitHub repository, reporting that the JavaScript runtime's in-progress Rust rewrite fails basic Miri checks — Rust's official tool for detecting undefined behavior (UB) in code. The issue carries a blunt title: the codebase "allows for UB in safe rust," which in the Rust world is roughly equivalent to saying a bridge passed its load test but the inspector found cracks in the foundation.
The report quickly gained traction on Hacker News, accumulating nearly 400 points — a signal that this touched a nerve in the developer community. Miri is not an exotic or experimental tool; it is the standard, compiler-team-maintained interpreter for catching undefined behavior, and running it is considered table-stakes hygiene for any Rust project that uses `unsafe` blocks or FFI. That Bun's Rust code reportedly fails these basic checks suggests either the team hasn't integrated Miri into their CI pipeline, or they've chosen to defer these fixes — neither of which inspires confidence in a project that handles JavaScript execution.
Bun, created by Jarred Sumner and backed by Oven, has been one of the most closely watched projects in the JavaScript runtime space. Originally written in Zig (itself an unconventional choice), the team announced a partial rewrite in Rust in late 2025, framing it as a move toward better ecosystem tooling and contributor accessibility. The Rust rewrite has been a major undertaking, and this issue is among the first public, technical stress-tests of that effort.
Undefined behavior in safe Rust is not supposed to happen. That's the entire contract: if you don't use `unsafe`, the compiler guarantees memory safety. When UB appears in nominally safe code, it almost always means that an `unsafe` block somewhere is violating its invariants, and those violations are leaking through safe API boundaries. This is the Rust equivalent of a type-safe language throwing a `ClassCastException` — the abstraction has failed.
Miri catches these issues by interpreting Rust code at a much finer granularity than normal compilation. It tracks pointer provenance, validates memory access patterns, and flags data races. Projects like the standard library, Tokio, and major crates run Miri in CI as a matter of course. For a project as high-profile as Bun — which executes arbitrary user JavaScript and therefore has an enormous attack surface — skipping or failing Miri checks is a material concern.
The Hacker News discussion surfaced several competing perspectives. Some commenters argued this is expected for a large, early-stage rewrite: Miri compliance is something you iterate toward, not something you achieve on day one, especially when porting from a language (Zig) with a very different memory model. Others pointed out that the whole pitch of rewriting in Rust is safety, and shipping code that fails the language's own safety validator undermines that value proposition before the rewrite even reaches production.
A third camp focused on process. Several experienced Rust developers noted that Miri should be integrated into CI from the first commit that contains `unsafe`. Retrofitting it later means accumulating UB debt that becomes exponentially harder to fix as the codebase grows — each `unsafe` block's invariants may depend on assumptions scattered across dozens of call sites. The longer you wait, the more likely you are to build correct-looking abstractions on top of unsound foundations.
There's also a meta-narrative here about the broader "rewrite it in Rust" phenomenon. Every major Rust rewrite — from Firefox's Stylo to Android's kernel modules to Microsoft's Windows components — has had to navigate the gap between Rust's theoretical safety guarantees and the practical reality of large codebases with extensive FFI and `unsafe` usage. The successful ones invested heavily in tooling, review processes, and incremental verification. The ones that treated Rust as a magic wand for safety without changing their engineering processes often ended up with the worst of both worlds: `unsafe` Rust that's harder to audit than the C/C++ it replaced.
If you're running Bun in production today, this finding is about the *rewrite*, not the current stable release (which is still primarily Zig). There's no immediate action item for existing Bun users — your runtime isn't affected by UB in code that hasn't shipped yet.
If you're evaluating Bun for new projects, factor this into your timeline expectations. The Rust rewrite is clearly still in an early phase, and the team's response to this issue — whether they integrate Miri into CI, prioritize fixing the UB, or defer it — will tell you a lot about the project's engineering maturity. Watch for a Miri CI job in Bun's GitHub Actions within the next few weeks; its presence or absence is the single clearest signal of how seriously the team takes this.
For teams planning their own Rust migrations or rewrites, the lesson is concrete: integrate Miri from day one. Make it a CI gate, not a nice-to-have. The cost of running Miri is measured in CI minutes; the cost of retrofitting soundness into a large codebase with accumulated UB is measured in engineering-months. Every `unsafe` block should have a documented safety comment explaining why the invariants hold, and those comments should be validated by Miri, not just by code review.
The broader principle: adopting a safe language doesn't automatically make your code safe. Rust gives you a framework for reasoning about safety, but that framework requires discipline — particularly around `unsafe` boundaries, FFI layers, and the abstractions you build on top of them. A Rust codebase that ignores Miri is like a TypeScript codebase where every third file starts with `// @ts-ignore`: you've got the tool, but you've opted out of its value.
This issue is early-stage and the Bun team hasn't signaled a final response yet. The most likely outcome is that Miri gets added to CI and the team works through the UB findings over the coming months — that's the standard playbook and Oven has generally shown good engineering instincts. But the community will be watching closely. Bun staked its Rust rewrite on credibility and contributor growth; letting basic soundness checks slide would undermine both. For the rest of us, it's a useful case study in what "rewrite it in Rust" actually costs when you get past the blog post and into the codebase.
What I don't understand is if they were going to translate Zig to unsafe Rust, why not just build a translation tool for it? You could do a one-to-one mapping of language constructs, hardcoding patterns in your codebase, and as one friend put it "Tbh they could've just hooked up zig t
This issue is misleading.The issue isn't the existence of undefined behavior that miri would catch. The issue is exposing an API that allows undefined behavior from safe code - which miri only catches if you go write the test that proves it.This isn't an all together unreasonable thing to
This doesn't seem surprising, given the straight translation that they prompted.Couldn't a case be made that it's better to get Bun to the to the language with the stronger type system first and, once there, use that stronger type system as leverage for these kinds of improvements as
I was a little shocked that they could get it fully working in a week to be honest. My side project is a very similar ambition (https://tsz.dev) but I am in no way claiming success. i keep adding more and more tests to ensure things works. Even after all of TypeScript's own tests pass
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Here's the thing:I was first interested in Bun because it was written in Zig. I was interested in Zig because I respected Andrew Kelley's decision-making, and his taste matched my own.I got really excited about Bun for many reasons after that, but they essentially came down to a similar ro