I wish this was clickbait…

Bun, a technology that has been a long-standing point of interest, is currently undergoing significant changes, leading to both excitement and concern within its community. Despite being a strong supporter of Bun and its team, recent developments have made it harder to use, a sentiment echoed by others. Dax from Open Code, for instance, has publicly announced their decision to move away from Bun in favor of Node.js, citing various reasons including Windows stability, Electron compatibility, and the necessity of spawning separate processes. However, the most critical issue is the uncertainty surrounding Bun's future. This uncertainty stems largely from a major rewrite of Bun in Rust, as detailed in an article by William Johnson. Jared, a key figure in Bun's development, confirmed that 99.8% of Bun’s existing test suites pass on the Linux x64 Glibc in the Rust rewrite. Bun was previously one of the largest projects built with Zig, a powerful but often problematic language. Zig's novel issues, community dynamics, and a strained relationship between the Bun and Zig teams have seemingly contributed to this rewrite. What began as an experimental side project to see if agents could parallelize and rewrite a complex system like Bun has proven viable, suggesting that this Rust rewrite is likely to merge and ship. This transition from forking Zig to effectively forking itself into Rust presents numerous challenges and learning opportunities, particularly in migrating software using AI tools. While the rewrite addresses some long-standing concerns, it doesn't resolve all of them, painting a future for Bun that is simultaneously brighter and scarier. Before delving deeper into Bun's rewrite, a brief mention of Work OS, today's sponsor. Work OS is an authentication platform that, while not necessary for every project, becomes crucial as projects scale. It offers built-in features like Radar to combat spam and robust multi-protocol authentication (MPA) support. Work OS also hosts MPA Night, a popular event in San Francisco, highlighting its commitment to the MPA community. Many large companies, including OpenAI and Vercel, rely on Work OS for their authentication needs, underscoring the importance of robust, pre-built solutions rather than rolling one's own. The issues driving Bun's rewrite can be categorized into three main layers: problems with Zig, problems with Bun itself, and the inherent challenges of rewriting an entire system. Zig, while a powerful language often seen as a successor to C, comes with its own set of peculiarities. Its "comp time" feature, allowing dynamic code generation at compilation, offers incredible flexibility for multi-platform support and system integrations. However, this power can also be a "foot gun" when combined with Zig's lack of inherent memory safety. This combination can lead to memory leaks and security vulnerabilities, especially when porting applications across different operating systems like Windows and Linux. Many Bun users have experienced these issues, particularly with memory management, especially in earlier versions and on Windows. Bun itself, despite its strengths, has its share of problems. It allows bundling JavaScript code into a single binary, making deployment easier for tools like Claude Code and Open Code. However, this also means these tools inherit Bun's underlying issues, particularly on Windows. Dax from Open Code has been meticulously migrating away from Bun-specific APIs, such as `bun.file` APIs, which, while faster and more elegant than Node.js equivalents, create vendor lock-in. Although Bun supports Node.js APIs, Open Code's initial choice of Bun-specific APIs now complicates their migration. Jared has acknowledged Windows stability issues, questioning if they persist beyond Bun 1.3.10, but users like those of Claude Code on Windows confirm that stability issues remain. Dax's decision to move off Bun is driven by Node.js's superior Windows stability, easier Electron desktop app embedding, and the ability to explore alternatives like Deno. Furthermore, benchmarks indicate that Bun's performance advantages are not significant enough for Open Code's use case. While Bun excels in package management and bundling, and can offer substantial performance gains in high-throughput server environments (e.g., 3x faster than Node.js for 20,000+ requests per second), these benefits are often negligible for local agent applications. William Johnson's article further emphasizes concerns about Bun's future, despite its open-source nature and continued development by the same team under Anthropic's ownership. The acquisition, initially seen as a positive step for Bun's profitability and future, now feels less reassuring given Claude Code's declining performance. The rewrite process itself, with 13,000+ unsafe calls already existing in the Zig codebase and only being halfway done, presents significant challenges. The TypeScript Go project offers a counter-example of a successful rewrite. They chose Go for its syntax similarity to TypeScript, enabling a line-by-line port of the existing TypeScript compiler. This approach, initially suboptimal and not leveraging Go's parallelization strengths, still resulted in faster code simply by being a native language. This demonstrates that treating languages as tools for compilers, rather than as ends in themselves, can lead to effective rewrites. Similarly, the Bun team is using Rust not out of affection for the language, but because it provides the necessary tooling to prevent specific types of bugs. The power of AI agents in this context is immense; they can be instructed to iterate on code, fixing unsafe functions and addressing borrow check errors until compilation passes. Rust's detailed error messages are particularly valuable here, providing clear feedback for AI agents. Jared's insights into the Rust port highlight the complexities. The current implementation uses dozens of crates for faster compile times, but this blocks cyclic dependencies, which were common in Bun's Zig codebase (e.g., using tag pointers for interfaces). Traits are the idiomatic Rust approach, but they incur runtime and memory overheads that Jared wants to avoid. He's exploring alternative approaches, like using macros to generate external Rust declarations and relying on the linker for inlining. This indicates a deep learning process happening concurrently with the rewrite. The ability to iterate rapidly with AI tools like Mythos, which the team has access to, is likely accelerating this process. However, Rust compilation times are a known challenge, and avoiding cyclic dependencies while maintaining performance will be a hurdle. Despite these difficulties, Jared has unequivocally stated that the Rust port will only be merged if it is measurably superior to the Zig implementation in performance, memory usage, and, crucially, stability. Given Jared's dedication and past work, his word on this is trustworthy. This rewrite is a bold, public experiment in using AI to overhaul a foundational system. If Bun can successfully transition its entire codebase to a new language in a short timeframe, it would be groundbreaking