Bun started as a bet that JavaScript tooling could be much faster. That bet paid off. Now, Bun is making another one: rewriting its runtime in Rust. Here's everything you need to know about why, where things stand, and what it means if you're building JavaScript applications today.
What Is Bun and Why It Matters
Bun is an all-in-one JavaScript toolkit. It combines a fast JavaScript runtime, a bundler, a package manager, a test runner, and a transpiler into a single binary. If you've been frustrated by Node.js startup times, slow npm runs, or juggling separate tools for bundling and testing, Bun was built for exactly those pain points.
The numbers are striking. According to benchmarks published on bun.sh, Bun handles 59,026 Express.js "hello world" HTTP requests per second on Linux x64, compared to 25,335 for Deno and 19,039 for Node.js. For WebSocket throughput, Bun clocks 2,536,227 messages per second against Deno's 1,320,525 and Node's 435,099. Bun also bundles 10,000 React components in 269ms. Rolldown completes the same job in 495ms. esbuild takes 572ms.
These aren't hypothetical gains. Companies including X (Twitter) and Midjourney run Bun in production. Tailwind's standalone CLI is compiled with Bun. Claude Code, Anthropic's AI coding assistant, ships as a Bun executable to millions of users.
Why Bun Was Originally Written in Zig
Bun's creator, Jarred Sumner, started the project in 2021. He was building a voxel game and got frustrated with Next.js hot reload times. He began porting a JSX and TypeScript transpiler from Go to Zig, a systems programming language that compiles to native binaries and offers fine-grained memory control without a garbage collector.
Zig was a pragmatic choice for a small team obsessed with performance. It gave Bun low-level control over memory layout and system calls, which directly contributed to the benchmark advantages the runtime is known for. Bun shipped its 1.0 release in September 2023 and its 1.2 release added built-in PostgreSQL, S3, and Redis clients.
But Zig is a young language with a small ecosystem. Finding contributors who know Zig well is harder than finding Rust developers. The Rust ecosystem, by contrast, is large, mature, and has become the dominant language for systems-level rewrites across the industry (see: the Linux kernel, Android, Firefox, and much of the cloud-native toolchain).
The Decision to Rewrite in Rust
The Rust rewrite is still described as experimental. Jarred Sumner announced the milestone on Hacker News in what became one of the more closely-watched threads in the JavaScript runtime community this year.
The core reasons for the rewrite come down to three things:
Contributor accessibility. Rust has a vastly larger developer community than Zig. More contributors means faster bug fixes, more platform support, and a healthier open-source ecosystem around Bun.
Maintainability at scale. Rust's ownership model and strong type system provide compile-time safety guarantees that help catch bugs before they reach users.
Long-term stability signals. Bun was acquired by Anthropic in late 2025. As Jarred wrote on the Bun blog, Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. That stakes profile demands a codebase that's as battle-hardened as possible.
Where the Rewrite Stands Today
The headline number: the Rust rewrite has achieved 99.8% test compatibility on Linux x64 glibc. This figure comes from Jarred Sumner's own announcement on Hacker News.
99.8% compatibility is a meaningful threshold. It means the Rust rewrite, running Bun's existing test suite, behaves identically to the Zig implementation in the overwhelming majority of cases. The 0.2% gap represents edge cases and platform-specific behaviors, not fundamental incompatibilities.
The rewrite is currently scoped to Linux x64 glibc. macOS, Windows, and ARM support come later. Bun's current stable release series (v1.3.x) continues to ship from the Zig codebase. The Rust rewrite is parallel, experimental work.
Performance Implications: Rust vs Zig
The most common question is whether Rust will be faster or slower than Zig. The honest answer: it depends, and the gap is smaller than most people assume.
Both Zig and Rust compile to native machine code. Neither has a garbage collector. Both allow the same class of low-level optimizations. The real performance benefits of the rewrite are likely to come from:
- A larger contributor pool finding and fixing performance regressions faster
- Rust's ecosystem of performance-focused crates like Rayon and Tokio
- Memory safety eliminating a class of bugs that cause random slowdowns in production
What won't change: Bun's use of JavaScriptCore (WebKit's JavaScript engine) for actually executing your JavaScript code.
What Changes for JavaScript Developers Using Bun
For most JavaScript developers, the Rust rewrite won't require any changes to your code or workflow. Bun's explicit goal is 100% backward compatibility.
What you can expect to improve over time:
- Fewer edge-case bugs, especially on non-Linux platforms
- Faster patch releases from a more accessible codebase
- Better cross-platform parity
- Increased confidence for production adoption
Using Bun with Cosmic
If you're building with Bun today, integrating Cosmic is straightforward. Install the TypeScript SDK:
bun add @cosmicjs/sdk
Then initialize your client:
import { createBucketClient } from '@cosmicjs/sdk'
const cosmic = createBucketClient({
bucketSlug: process.env.COSMIC_BUCKET_SLUG as string,
readKey: process.env.COSMIC_READ_KEY as string,
})
const { objects } = await cosmic.objects.find({
type: 'posts',
})
This runs identically on Bun, Node.js, and Deno. Cosmic's REST API and TypeScript SDK don't depend on any runtime-specific APIs.
What's Next
The timeline for the Rust rewrite becoming the default Bun binary is not publicly committed. The likely next steps are:
- Closing the remaining 0.2% compatibility gap on Linux x64
- Expanding platform coverage to macOS (both x64 and ARM)
- Windows support
- A public beta period before the Rust binary becomes the default release
The bigger context is Anthropic's acquisition. Bun now has institutional backing from one of the best-funded AI labs in the world. That financial and organizational support changes the risk calculus for anyone evaluating Bun for long-term production use.
The Bottom Line
Bun's Rust rewrite isn't a pivot or a panic. It's a deliberate maturity move by a team that has already proven it can execute. The 99.8% test compatibility milestone is real progress, the Anthropic acquisition provides genuine long-term stability, and the move to Rust opens Bun's development to a much larger contributor community.
For JavaScript developers: Bun was already fast. The Rust rewrite is about making it more reliable, more maintainable, and more accessible to contributors, while keeping the performance characteristics that made it worth paying attention to in the first place.
The runtime wars aren't over, but Bun just made a significant move.
Building your next Bun app? Cosmic's REST API and TypeScript SDK work seamlessly with any JavaScript runtime. Start free.
Top comments (1)
Everyone seems to either be comfortable with the "rewrite" being done by Claude - or they ignore it.
IMHO the PR that merged the rewrite into main was rushed. Over 1m changed lines in 2000+ files via more than 6300 commits.
Accepted, closed and merged in under a week. Brings some strong "lgtm" vibes.