--- title: Bun 1.4 finally ships. The Rust rewrite drama isn't over. description: Bun 1.4 has shipped with major improvements: 1,517 newly passing Node.js compatibility tests, 5x lower idle CPU, 48% less memory for HTTP servers, 50% faster... canonical: https://daily.dev/posts/bun-1-4-finally-ships-the-rust-rewrite-drama-isn-t-over--fdy7op2yl twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Bun 1.4 finally ships. The Rust rewrite drama isn't over. | daily.dev og:description: Bun 1.4 has shipped with major improvements: 1,517 newly passing Node.js compatibility tests, 5x lower idle CPU, 48% less memory for HTTP servers, 50% faster... og:url: https://daily.dev/posts/bun-1-4-finally-ships-the-rust-rewrite-drama-isn-t-over--fdy7op2yl og:image: https://api.daily.dev/og/posts/FDy7oP2Yl.png og:image:alt: Bun 1.4 finally ships. The Rust rewrite drama isn't over. og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Bun 1.4 finally ships. The Rust rewrite drama isn't over. **[Trends](https://daily.dev/sources/trends)** · 2 min read · 91 upvotes · 9 comments ## Summary Bun 1.4 has shipped with major improvements: 1,517 newly passing Node.js compatibility tests, 5x lower idle CPU, 48% less memory for HTTP servers, 50% faster Linux startup, and new APIs including Bun.Image, Bun.WebView, Bun.cron, native streams, and HTTP/2 and HTTP/3 support. Alongside the release, controversy has flared over how the runtime's underlying rewrite from Zig to Rust was executed. Bun advocate Tero Piirainen documented repeated timeline slips based on creator Jarred Sumner's own statements, questioning whether the rewrite was necessary and whether it delivered the promised memory-safety benefits. Critics also point to the project's pull request backlog exceeding 5,000 open PRs and over 15,000 commits from an automated bot account as signs of process dysfunction. ## Content Bun 1.4 is out, and the headline is a full rewrite from Zig to Rust. The numbers are genuinely impressive: 2,900+ issues fixed, 1,517 new Node.js compatibility tests passing, idle CPU down 5x, memory usage cut up to 48% for HTTP servers, startup 50% faster on Linux. Vercel already has it in production. One user reported a 37% RPS increase on a real endpoint. Jarred Sumner says compile times are 3.4x faster than before the rewrite. New built-ins include `Bun.Image` (faster than Sharp), `Bun.WebView` (headless browser without Puppeteer), `Bun.cron()`, `Bun.markdown`, and `Bun.Terminal` for PTY-backed terminal apps. Vercel's Guillermo Rauch called it a "perfect match." The reception from the pro-Bun crowd is warm. But there's a thread worth pulling. A long-time Bun advocate published a detailed critique documenting months of missed release dates for 1.4, over 5,000 open pull requests (GitHub recommends keeping that number much lower), and heavy reliance on AI-generated commits from an automated account called "robobun." Zig creator Andrew Kelley apparently weighed in on Bun's code quality, and not kindly. The critic's core question: did the Zig-to-Rust switch actually solve the memory-safety problems it was supposed to, or was it a reframe? Sumner's own tweets don't exactly quiet those concerns. "Most of Bun's PRs now are from things Claude found while fuzzing," he posted. He also shared a screenshot of asking Claude which subcommands to add to 1.4. That's either a confident bet on AI-assisted development or a preview of what happens when a small team tries to ship a runtime that competes with Node and Deno simultaneously. Probably both. The performance results are real. The AI-generated PR volume is also real. Those two things can coexist, but the question of whether a production runtime can be responsibly driven by AI agents at this scale is one the community hasn't settled. Bun 1.4 is the most prominent live test of that question right now, and 1.4.1 is already shipping Monday. ## Questions this post answers ### What's new in Bun 1.4? Bun 1.4 adds 1,517 newly passing Node.js compatibility tests, the largest jump since version 1.0, along with 5x lower idle CPU usage, 48% less memory for HTTP servers, and 50% faster startup on Linux. New APIs include Bun.Image, Bun.WebView, Bun.cron, native streams, and support for HTTP/2 and HTTP/3. _Track Bun's release notes on daily.dev before deciding whether to adopt 1.4 in production._ ### Why did Bun rewrite its runtime from Zig to Rust? Bun's creator Jarred Sumner pursued a rewrite from Zig to Rust aiming at memory safety, but the timeline slipped repeatedly over months according to his own public statements, documented by Bun advocate Tero Piirainen. Critics question whether the rewrite was actually necessary or delivered the memory-safety improvements it promised. _Developers weighing runtime stability follow rewrite postmortems like this one on daily.dev._ ### How many open pull requests does the Bun project have? Bun's pull request count exceeded 5,000 open PRs, well beyond what GitHub recommends for a healthy repository, and more than 15,000 commits came from an automated bot account, fueling criticism of the project's development process during the Rust rewrite. _Engineers evaluating open source project health check governance signals like these on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 355 comments across hackernews, lobsters (as of 2026-08-26). **TL;DR:** Bun 1.4: Reaction to Bun 1.4 centers on a big debate over its batteries-included, everything-in-the-runtime philosophy, plus a lot of discussion (and skepticism) about the AI-driven Rust rewrite and whether the release itself is credible given recent criticism of delays. Bun 1.4 Rust rewrite is not looking good • Tero Piirainen: Reaction is split between people who see the repeated missed release dates, 5k+ open PRs, and messy AI-generated code as real warning signs, and others who point out that the Rust rewrite already powers Claude Code in production and argue the delays are just scope creep or normal project churn rather than proof of failure. **Sentiment:** 21% positive · 47% mixed · 32% skeptical **The case for** - Having common functionality (image processing, headless browser automation, parsers) built into the runtime avoids installing many small third-party dependencies and reduces supply-chain risk. - Several people note the Rust canary is already running in production (e.g. powering Claude Code) without apparent issues. - Native implementations are seen as faster and more consistent than relying on scattered ecosystem packages. - Some argue slow release cadences are normal for ambitious projects and not inherently a red flag. - Some see the Rust rewrite as a surprisingly fast, low-cost success that silences earlier doubters. **The pushback** - Bundling so many domains (YAML/TOML parsers, DB drivers, image handling, browser automation) into one massive binary is seen by some as scope creep that duplicates dedicated projects' expertise. - Many see the constant scope creep and missed self-imposed deadlines as a sign of poor project management. - Concerns that the standard-library decisions are driven by one person's preference rather than a broader standards process. - Commenters criticize the article's core evidence (unsafe blocks, dead code claims) as weak, misleading, or factually wrong (e.g. the dead-code figure was from the old Zig fork, not the Rust rewrite). - Skepticism that an AI-heavy rewrite can be trusted long-term, with fears of quality degradation ('slop') down the road. **By community** - hackernews (heated): A long, heated back-and-forth over whether Bun's all-in-one philosophy is good or bad, layered with skepticism and jokes about the AI-driven rewrite's cost, timeline, and the promo video. - lobsters (skeptical): Discussion leans toward questioning whether the release itself is meaningful content (given it was flagged as spam) and voicing doubts about AI-authored 'slop' alongside some praise for specific new APIs. **Hottest debate:** Bun 1.4: Whether Bun's strategy of bundling everything (parsers, drivers, browser automation, etc.) into the runtime is a smart batteries-included approach or unnecessary bloat that duplicates dedicated projects. **Open questions** - Is the Rust rewrite actually stable and bug-free in real-world production use beyond Anthropic's own usage? - Has the Rust rewrite actually reduced bugs or vulnerabilities compared to the Zig version, with concrete evidence rather than anecdotes? - What is the true cost and timeline of the AI-assisted rewrite, and how should that be judged as a success or failure? - Why has Bun's release cadence stalled since the rewrite began despite claims of AI-accelerated development? - Will quality degrade over time as more AI-generated code accumulates in the codebase? **Highlights** > I remember when Python advertised its strong standard library. Then the batteries got old and we went hard micro dependencies. Maybe pendulum is just starting to swing back. > — [mitsuhiko on lobsters · 3 points](https://lobste.rs/s/eesu8d/bun_1_4#c_dufm3j) > I'm tired of seeing this claim for rust rewrites: > The number of unsafe blocks in the Rust code suggests the rewrite did not deliver the memory safety that was given as the reason for doing the rewrite in the first place. This project replaced an implicit "unsafe" attached to every block of zig code with a few explicit ones that are still being removed. This includes explicit ones which cannot be removed (extern C) On the first 5 pages of GitHub search for that keyword, I found only 1 case that seems questionable. And some that could be probably removed with a change of architecture. But this quote from the post is not supported in any way. > — [viraptor on lobsters · 3 points, 2 comments](https://lobste.rs/s/caubyr/bun_1_4_rust_rewrite_is_not_looking_good#c_dtzvdp) > The benefit of having features like this baked into the core runtime is that you can guarantee they will be consistently supported and documented for the lifetime of the project. Similar to how Django benefits from shipping its own ORM and template language because it means those things will never become unsupported or incompatible with the rest of the framework. In 2026 I think image processing is a reasonable default capability for a language runtime. Headless browser automation and markdown make sense if you expect agent frameworks to be a big client of your runtime, which feels right for Bun. > — [simonw on lobsters · 3 points, 1 comments](https://lobste.rs/s/eesu8d/bun_1_4#c_f82ase) > I wish people writing posts like this would be more concrete about what they're claiming. Is it: - you think that the rewrite is not ever going to be released? - you think it is going to be released someday, and will be very buggy / worse? - you think it's taking them a long time to clean up from the rewrite, but it will be released someday and will be good? - you think it will be released someday and will be fine/good, but it's annoying that they keep delaying it? I'm in the fourth camp but I wouldn't describe that as "not looking good" as opposed to "being poorly managed". (More concretely: I expect the rewrite will be released by end-of-year and will work at least as well as 1.3. End-of-year is of course an absurd delay, it should have been released by now and should be released soon, but I have no confidence in Jarred's ability to keep a timeline.) If you disagree, care to make an actual prediction? As far as I can tell from following Bun's github, it's just that they keep adding [more](https://github.com/oven-sh/bun/pull/39229) [features](https://github.com/oven-sh/bun/pull/37048) and minor bug fixes and node compat and performance tweaks/improvements instead of cutting a new release. I wish they wouldn't do this, I do think it's a sign of bad project management, but I'm not sure why we're supposed to infer it's "not looking good" or even what "not looking good" is supposed to mean. > — [bakkot on lobsters · 1 points](https://lobste.rs/s/caubyr/bun_1_4_rust_rewrite_is_not_looking_good#c_gdnqgr) > This post doesn't contain useful information. I understand why it is on top of lobste.rs, but I don't like this fact. I wish we used our collective voting power better to help each other find signal in the noise. This post sounds like it answers two extremely interesting technical questions: * Can LLMs rewrite large codebases from language A to language B, without reducing quality bar? * For Bun's style development practices(yolo coding, if you will), does Rust reduce defect and vulnerability rate compared to Zig? The article contains no data points related to these two questions. It actively _avoids_ making a technical contribution, in favor of looking at the meta points and signalling mood affiliation. With meta points, the article fails to mention the critical detail --- that the Rust version of bun is what powers Claude Code these days. If the author knew that, and omitted from the post, that is disingenuous. If the author _didn't_ know that fact, they are probably not qualified to write about this. There's also a chance that _I_ am actually misinformed here, and Claude Code still runs the Zig version, but this is a popular enough claim that is _must_ be investigated in this sort of post. What I _want_ to read is an article discussing bugs introduced, fixed, and avoided by the rewrite. It's easy to do if there are bugs, it needs to be creative if we didn't observe the bugs. But this article is not it, not it at all. I want to read experiencies of people looking at the code, running the thing, and hitting the bugs. I don't want to read armchair analysis of release schedules, _especially_ if it doesn't contain in-class comparisons (how long did it take Microsoft to ship Go version of TypeScirpt compiler?) I want to especially highlight this passage, which I think is a emblematic of the issues I have with the article, and with its reception on lobsters: > I thought he was a true Zig talent, until I read Zig creator Andrew Kelley’s > thoughts on the Bun rewrite This is bad thinking. Sure, _a lot_ of "trust the experts" is required in our world, but we _are_ the experts. We can just go and look and see for ourselves! "Andrew thinks Bun's code is not good" is an empty statement, and argument from authority. "Bun only started fuzzing code after being acquired, shortly before or concurrently with the rewrite" is a factual statement that carries weight. All that being said, I don't actually have any problems with the post per se. I would prefer to not read it, but I imagine for someone running Bun 1.3 in production it can be quite useful, and the world _is_ a better place with this post existing. I only have the problem with lobste.rs treating this post as "LLMs vs Rust vs Zig" battle royale, while it actually adds more smoke than light in that interesting domain. (I used to write a tonne of Rust, I use Zig for work, I don't use AI for coding, my blog runs on Deno, and I don't know a person who is better at making technical decisions than adrewrk) > — [matklad on lobsters · 1 points, 1 comments](https://lobste.rs/s/caubyr/bun_1_4_rust_rewrite_is_not_looking_good#c_3zaqxw) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49374797) · 82 points · 156 comments - [hackernews](https://news.ycombinator.com/item?id=49357401) · 85 points · 107 comments - [lobsters](https://lobste.rs/s/caubyr/bun_1_4_rust_rewrite_is_not_looking_good) · 61 points · 57 comments - [lobsters](https://lobste.rs/s/eesu8d/bun_1_4) · 34 points · 35 comments - [hackernews](https://news.ycombinator.com/item?id=49328557) · 1 points · 0 comments ## Community discussion Top comments from developers on daily.dev. **@pdfopsdev** · 10 upvotes > the 'still has unsafe blocks so it's not really memory-safe' take is lazy, what matters is whether those blocks sit at ffi/syscall boundaries or in actual parsing logic. rust's whole pitch is containing unsafe to a tiny audited surface, not eliminating it. **@allinonetools** · 9 upvotes > The compatibility improvements are impressive, but the rewrite story is what caught my attention. Performance gains are great, but long-term maintainability and confidence in the codebase matter just as much. **@dustinscott** · 1 upvotes > Can't wait to go full circle and rewrite it in typescript under scriptc **@sunilgchaudhary** · 0 upvotes > Is anyone running this in prod yet? **@agustinbarrientos** · 0 upvotes > I think the compatibility gains matter more than the rewrite language. A runtime earns trust when its Node test delta, memory profile, and regression backlog stay visible release after release. --- Tags: [#javascript](https://daily.dev/tags/javascript), [#open-source](https://daily.dev/tags/open-source), [#nodejs](https://daily.dev/tags/nodejs), [#rust](https://daily.dev/tags/rust), [#bun](https://daily.dev/tags/bun) [View this post on daily.dev](https://daily.dev/posts/bun-1-4-finally-ships-the-rust-rewrite-drama-isn-t-over--fdy7op2yl) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Bun 1.4 finally ships. The Rust rewrite drama isn't over.","url":"https://daily.dev/posts/bun-1-4-finally-ships-the-rust-rewrite-drama-isn-t-over--fdy7op2yl","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/bun-1-4-finally-ships-the-rust-rewrite-drama-isn-t-over--fdy7op2yl"},"datePublished":"2026-08-20T14:15:08.355Z","dateModified":"2026-08-26T16:32:45.314Z","description":"Bun 1.4 has shipped with major improvements: 1,517 newly passing Node.js compatibility tests, 5x lower idle CPU, 48% less memory for HTTP servers, 50% faster...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/c8a2aa7af63a34f0ffb2b0fef668f121?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/c8a2aa7af63a34f0ffb2b0fef668f121?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Trends","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Trends","logo":"https://media.daily.dev/image/upload/s--ZfSp3asX--/f_auto,q_auto/v1780996004/logos/trends?_a=BAMAMiWQ0","url":"https://daily.dev/sources/trends"},"commentCount":9,"discussionUrl":"https://daily.dev/posts/bun-1-4-finally-ships-the-rust-rewrite-drama-isn-t-over--fdy7op2yl","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":91},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":9}],"keywords":"javascript,open-source,nodejs,rust,bun","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Trends","item":"https://daily.dev/sources/trends"},{"@type":"ListItem","position":3,"name":"Bun 1.4 finally ships. The Rust rewrite drama isn't over."}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/bun-1-4-finally-ships-the-rust-rewrite-drama-isn-t-over--fdy7op2yl","comment":[{"@type":"Comment","text":"the ‘still has unsafe blocks so it’s not really memory-safe’ take is lazy, what matters is whether those blocks sit at ffi/syscall boundaries or in actual parsing logic. rust’s whole pitch is containing unsafe to a tiny audited surface, not eliminating it.","datePublished":"2026-08-20T18:02:39.785Z","url":"https://daily.dev/posts/FDy7oP2Yl#c-eEYwmdN7K","author":{"@type":"Person","name":"PDFops","url":"https://daily.dev/pdfopsdev","image":"https://media.daily.dev/image/upload/s---8isRBKc--/f_auto/v1782922291/avatars/avatar_orjMeK8QKaaVZwGq7ScPz?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":10}},{"@type":"Comment","text":"The compatibility improvements are impressive, but the rewrite story is what caught my attention. Performance gains are great, but long-term maintainability and confidence in the codebase matter just as much.","datePublished":"2026-08-21T03:05:01.383Z","url":"https://daily.dev/posts/FDy7oP2Yl#c-pobOh7F1V","author":{"@type":"Person","name":"AllInOneTools","url":"https://daily.dev/allinonetools","image":"https://media.daily.dev/image/upload/s--4ZT8QlF0--/f_auto/v1769790028/avatars/avatar_igzBsWloJeaegzm9bQltZ?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":9}},{"@type":"Comment","text":"Can’t wait to go full circle and rewrite it in typescript under scriptc","datePublished":"2026-08-21T16:18:03.860Z","url":"https://daily.dev/posts/FDy7oP2Yl#c-6OixLrWZ3","author":{"@type":"Person","name":"dustin scott","url":"https://daily.dev/dustinscott","image":"https://lh3.googleusercontent.com/a/ACg8ocKHTQeQRFj8FaA9LZ2aTSaFRty7k1IA2HWRiKILsBzXZEfKkU8N=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}},{"@type":"Comment","text":"Is anyone running this in prod yet?","datePublished":"2026-08-21T13:14:59.315Z","url":"https://daily.dev/posts/FDy7oP2Yl#c-JFVeCCdFY","author":{"@type":"Person","name":"Sunil Chaudhary","url":"https://daily.dev/sunilgchaudhary","image":"https://avatars.githubusercontent.com/u/46418190?v=4"}},{"@type":"Comment","text":"I think the compatibility gains matter more than the rewrite language. A runtime earns trust when its Node test delta, memory profile, and regression backlog stay visible release after release.","datePublished":"2026-08-24T18:45:23.812Z","url":"https://daily.dev/posts/FDy7oP2Yl#c-xPQ1WB6jg","author":{"@type":"Person","name":"Agustin Barrientos","url":"https://daily.dev/agustinbarrientos","image":"https://media.daily.dev/image/upload/s--5ayxQnqn--/f_auto/v1788281802/avatars/avatar_wQYYVe5Tbj0NJ7C7qPoa8?_a=BAMAMicg0"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/bun-1-4-finally-ships-the-rust-rewrite-drama-isn-t-over--fdy7op2yl#faq","mainEntity":[{"@type":"Question","name":"What's new in Bun 1.4?","acceptedAnswer":{"@type":"Answer","text":"Bun 1.4 adds 1,517 newly passing Node.js compatibility tests, the largest jump since version 1.0, along with 5x lower idle CPU usage, 48% less memory for HTTP servers, and 50% faster startup on Linux. New APIs include Bun.Image, Bun.WebView, Bun.cron, native streams, and support for HTTP/2 and HTTP/3. Track Bun's release notes on daily.dev before deciding whether to adopt 1.4 in production."}},{"@type":"Question","name":"Why did Bun rewrite its runtime from Zig to Rust?","acceptedAnswer":{"@type":"Answer","text":"Bun's creator Jarred Sumner pursued a rewrite from Zig to Rust aiming at memory safety, but the timeline slipped repeatedly over months according to his own public statements, documented by Bun advocate Tero Piirainen. Critics question whether the rewrite was actually necessary or delivered the memory-safety improvements it promised. Developers weighing runtime stability follow rewrite postmortems like this one on daily.dev."}},{"@type":"Question","name":"How many open pull requests does the Bun project have?","acceptedAnswer":{"@type":"Answer","text":"Bun's pull request count exceeded 5,000 open PRs, well beyond what GitHub recommends for a healthy repository, and more than 15,000 commits came from an automated bot account, fueling criticism of the project's development process during the Rust rewrite. Engineers evaluating open source project health check governance signals like these on daily.dev."}}]} ```