It's weird their promotional video repeats "you can do <million things> without installing dependencies", if I want headless browser testing is that wrong to install a project that offers that?
Why would I want everything reimplemented in this massive binary? Why would Bun be anymore in touch with nuances of all these different technologies then individual projects dedicated to their own speciality?
JS Runtime, Package Manager, Test Runner (both unit and headless browser), Bundler, JSX, PosgreSQL/MySQL/SQLite drivers, S3 client, Redis client, Formatter, Linter, etc.
Not to mention parsers for YAML, TOML, Markdown which are easily three separate projects worth of complexity in their own right.
I guess one clear downside is to get all these great features they're pushing for 1.4 you needed to wait until all these features were ready. Given 1.3 was pushed out in October 2025, a 10 month release cycle is tough.
> Why would I want everything reimplemented in this massive binary? Why would Bun be anymore in touch with nuances of all these different technologies then individual projects dedicated to their own speciality?
It's funny because the top article on HN is about a malicious rust crate package, and people keep making comparisons to js/npm and how both language suffer from frequent security issues because they have weak std libs.
I saw a post recently about how LLMs are much more effective in Ruby on Rails because it's batteries included, so you don't get so many implementation details crapping up the context window.
I assume the same benefit applies to humans as well!
I am not into the Ruby on Rails world, but I find LLMs much more effective with powerful type systems like Typescript. Especially if you nudge it to keep things strict and (statically) eliminate invalid states. Do they use similar systems (build-time typing) for Ruby?
When the LLM can verify its own output by running static analysis they produce better results. They also seem to understand type definitions and avoid going to the source which, in theory, should reduce context size.
If agents are good at RoR, it's ironic because they're bad at Ruby. They aren't good at holding a model of the 20 different things various code you've loaded has monkey patched, no longer respecting their original contracts.
I don’t believe they are better at Ruby. Agents got better overall and people draw bad conclusions from their anecdotal evidence. Ruby on Rails is mostly DHH cult with people praising Ruby as poetry.
This is coming from someone working 13 years as Ruby dev. I love the language, but I want to be honest that I didn’t had experience with other languages before and seeing statically typed languages (Java, TypeScript), Elixir opened my mind to the amount of cargo cult inside Ruby community stemming mostly from people limited to knowing only 1 language.
I've read much of the same for Go. It's half true. Python doesn't have as many batteries but its common external packages are probably more present in training data than Go stdlib.
It’s total BS. Most of the frameworks are batteries included like Django, Laravel, Spring.
Tbh we need to do some real research about it, because all those articles are just feelings that it seems to work better. But mostly it feels better, because we got stronger models and improved agent harnesses
Something that frustrates me about that discourse is that people argue about the mere existence of dependencies but all 'supply chain' (1) attacks are issues over when dependencies change. Dynamic systems are harder to reason about than static ones.
(1) scare quotes because I think it's dumb for us software people to call code we picked up on the side of the road part of a 'supply chain' like that means anything.
Some of these feel like solved problems effectively, so having them in the standard library is nice (at the expense of keeping these forever for backwards compatibility once a new tech replaces it). I do think having a larger standard library for common things (like golang) is the way to go. If a dependency seems to basically be installed by default everywhere, maybe it should go in the standard library.
> It's weird their promotional video repeats "you can do <million things> without installing dependencies",
A couple years ago a common complaint was that the JavaScript ecosystem relied too heavily on dependencies for everything. Remember the left-pad incident where the developer deleted the popular dependency out of protest for reasons I can even remember? Or when colors.js was sabotaged to break everything that depended on it? The node-ipc package was sabotaged to delete files on developer’s machines. Then we had a wave of supply chain attacks that tried to insert malware into build scripts of popular dependencies.
So the ecosystem started moving toward more batteries-included style development in response.
I've still yet to run into any enterprise project using bun in the wild. It really feels like something entirely contained within startups that would choose wildly inappropriate tech like next.js.
Add in the influencer dev brainrot culture and you get these VC backed efforts to privatized publicly important projects (node.js) under control of quite evil people that have zero record of helping others.
I always thought Bun's approach was to be the JS runtime with a large well-designed std-library, this isn't really new. It's nice to have a choice of a more or less-featured runtime depending on the project's requirements -- if size and complexity are an issue, there's a variety to choose from.
I for one prefer batteries-included. Decision fatigue for every cobbled together package takes its toll. Having a single, trustworthy, good-enough solution for so many things makes my life easier.
“ Why would I want everything reimplemented in this massive binary? “
This isn’t about what individual developers would want but what is most beneficial to Anthropic and claude code. They are likely using Bun as a vehicle for standardizing and enriching local user environments in order to address common tasks that claude generally writes bespoke scripts to accomplish.
Out of the things you mentioned I think the following make totally sense to be included in a language runtime like this:
JavaScript runtime (obviously), package manager, test runner for unit tests, bundler, JSX, SQLite bindings, formatter, linter, YAML and TOML parsers. Maaaaybe even a Markdown parser and HTML5 parser. Definitely JSON, CSV and XML parsers.
I.e. similar to Python. Though Python is a bit of an incoherent mess. If you have all these you need them to be coherent.
Things like headless browsers are really annoying to include in FaaS environments, but are super useful. If they're in the runtime binary already, that'd be great.
Ideally everything not built specifically for any given project is part of the OS or some other battle tested, supported system package.
For example, I might well choose to reimplement eg a subset of TOML parsing to avoid the dependency risk.
I don’t write JavaScript/TypeScript, but if I did, I’d find Bun’s “batteries included” approach compelling, at least to the extent I decide I can trust Bun, after due diligence
I don't use Bun, so I don't know if quality has degraded. But if it hasn't and they're shipping features users want faster than ever, I wouldn't call it slop. I don't care who wrote the code if the end product is working.
I recently pivoted to Rust for the backend development, after getting tired of the nodejs ecosystem fragmentation and how fragile things feel. Bun seems very interesting since it allows you to do so many things without pulling in 3rd party libraries and bundlers? Is anybody using it instead of nodejs? how's the experience so far? I might have to give it a try.
Yes, I know there's probably better options than Rust for building APIs, but I wanted to learn it, so why not?
I'm using it, though I'm leery of how the project is run. It's been great, to be honest. I have been able to build very low-dependency projects quite quickly. Bun's documentation is decent, and its underlying features are performant.
The most appealing thing of Go to me is the good batteries including tooling. I don't use it much outside of little personal projects where I really don't want to deal with dependencies and want a small binary.
Yeah, I prefer Rust as a language but the ecosystem and toolchain is risky. E.g. build time scripts from upstream is too risky these days and it’s commonly used.
This has been my choice for a while too, especially when I found out that you can embed a full-ass webapp in a single executable.
Backend + web API + the actual web pages all contained in a single file. If you have sane defaults, deploying is literally just copying a single executable over.
I use it heavily for personal use and find it works very well and lets me ship small applications quickly. I still use rust and other languages too as appropriate.
I know we're all using AI, but Bun seems like the one singular project where there's just been a crazy increase in the amount of output, a 10x on the 10x.
slightly aside, but I find it worrying that our industry treats a lot of cannon events in stride and don't organize around that idea or to mitigate the risks around that idea.
things that everybody basically just complained but ended up working out fine,
- Bun rust rewrite.
- Elon Musk firing 80% of twitter by stack ranking employees by code committed
- autocompletion basically just taking over everyone
maybe I'm just taking extremely outlier outcomes. but it is still fascinating to see people complain about how LLMs don't think
I really am curious about the issues that I'm ignoring
twitter was a dumpster fire before and now it is (to me) less of a dumpster fire.
so far it seems like the bun rewrite is going quite well. I haven't found any major issues since the merge despite, robobun being the top committer in the repo.
claude code uses bun written rust. and it has been in prod for a month or so. I am finding it hard not to celebrate because it was quite literally a +1M -4K line change that is touching people today.
> irrespective of the political turmoil.
I was mostly concerned with the technical perspective of firing 80% of people by stack ranking. the consensus in HN at the time was that twitter had months left before all production systems burn down, because all the organizational knowledge has left. but seems like firing 80% went just fine for them. which I find fascinating.
This is a huge win for Bun & Anthropic. I've been keeping an eye on Bun development cycle since they announced the Rust rewrite and the huge drama and backlash it generated. They seem to be proving the skeptics wrong with this release.
~3 months start to finish and the price of 1 engineer for a year, to rewrite a critical infra codebase that tens of millions of user software relies on. Truly the goalposts keep moving. This kind of project would've have been 10x the effort and price a few years ago.
Once a model like Fable/Mythos is trained, that was used for this project, the inference costs are profitable. CapEx vs. OpEx. Every new Zig->Rust port of this caliber using Fable/Mythos costs the standard token price, it's not subsidized. The model already exists for the original CapEx, you can do 1,000 ports of this for standard token pricing.
Which one did it not prove wrong? The fully AI written version of Bun has released, fixed a ton of bugs that existed in the zig version, added a lot of new features and performance improvements and has been shipping with every single installation of claude code for months, the most widely used LLM-harness out there.
By every single measurable metric this is better software than the old hand-written version ever was.
It is for sure a big accomplishment, but without having paid too much attention to the drama, I understand that the porting was meant to show Anthropic's models amazing capabilities. From what we know, the process took longer than expected and involved dozens of engineers from Anthropic actively working on it, presumably each one with dozens of SOTA agents helping. It definitely was an expensive process when you sum up the engineers hourly rate and the tokens consumed by frontier LLMs. It's not something that a small team engineers can accomplish with a Claude Max subscription (obviously not, but those are the vibes some people were getting with the project).
If it was one memory leak, it would be meh in the fix list, but the fact they've announced that they've eliminated all memory leaks because of Rust in about eleven days that's what's wild to me.
We are living in a new world when it comes in how software is prompted into existence.
From the release video, something catching my attention:
> In Bun 1.4, I rewrote Bun in Rust. [...] I did it in 11 days, using Claude Code, and wrote about how, in our blog.
Everything else in the video is phrased as "we", and even the section in the blog post is "We rewrote Bun in Rust"[1].
There's no question Jarred did the work and deserves enormous credit for it. I just found the contrast interesting, because the video explicitly frames the rewrite as "I", whereas the rest of the release frames it as "we".
While it has been used by Anthropic, the main question is if it works in other Bun's 1.3 production settings. Ignoring all the improvements, if it does work and no major bug or problems occurred, We are in for some management top down "Rewrite it in Rust" action over the next few years. And perhaps even worst, management will believe in Claude feed into Claude development.
This isn't so much about Bun or Node.js any more. It is the battleground for AI and non-AI coding.
The policy does not forbid use of LLMs for research, analysis, bug discovery and reporting, patch review, etc. as long as the output is not included in contributions. The committee says that it expects the policy will evolve and will be revisited periodically.
I think around $300-400k, but that does not include the github issue/pr/ci stuff that runs continuously, which could double or triple it. Somewhere, the first two weeks were said to be about $200k.
That total assumes API billing rates, which isn't what Anthropic pays for the inference. So I'm confused why people keep quoting that. It's not representative of what it'd cost for you either because you could use cheaper models.
> That total assumes API billing rates, which isn't what Anthropic pays for the inference. So I'm confused why people keep quoting that. It's not representative of what it'd cost for you either because you could use cheaper models.
It is, because this rewrite was marketing for Claude. So it reflects the price for what other companies might need to pay if they want to rewrite something else with similar size.
Am I the only one starting to get annoyed by Bun just due to all the surrounding drama? I was genuinely surprised this was an actual link about an update - my gut inclination opening that was Jarred probably decided to rewrite Bun to JavaScript to stay pure or something like that.
The author didn’t care to himself, just merging enormous PRs with “lol” tweets about how github doesn’t display all the changes because there are too many.
This is unmaintable mess, and the author himself is struggling already, given how he pushed the release date ten times.
It’s not maintainable by humans because there’s not a single human person who actually wrote any of it. But I guess it’s maintainable by LLMs. Which is part of the anthropic marketing
For me, notably absent from the release changelog and accompanying YouTube video they were excited to trumpet in the blog back in July, and the claim (still) this took 11 days. It's August 20th.
The rewrite part of "functionally equivalent to the existing zig version" did in fact take 11 days based on the available data. When that was done, they spend some time on a ton of new features and hardening and bugfixing that the Rust rewrite enable. This took additional time.
Lobste.rs is now flagging Bun 1.4 post as spam and comments are dismissing it as nothing, even as that blog post got much more discussion and piling on about the rewrite.
Internet echo chambers are quite a problem. AI success and its immense implications are wreaking havoc on the ability of even intellectuals in HN and lobsters to face reality in front of them, even as their predictions become falsified again and again.
> Internet echo chambers are quite a problem. AI success and its immense implications are wreaking havoc on the ability of even intellectuals in HN and lobsters to face reality in front of them, even as their predictions become falsified again and again.
In this scenario, do you see yourself as an intellectual? In this case, one that is illuminated by the glory of AI. Or just looking for validation and not finding?
Did you… perhaps read the entire comment you just posted? The crowd that was saying “no way they did that in 11 days” sure seems correct given that the release today is 3 months later. 3 months is longer than 11 days. Significantly so, in fact.
1.4 also adds a lot of features so its more than a port. Plus Claude Code has been using the rust port since atleast July 19. So its definitely less than 3 months.
Or, more likely, the amount of crappy auto generated code and “features” they crammed into this release resulted in so many bugs that a “simple rewrite” would up being 3 months of whack-a-mole with the issues they created. That’s the predictable result from the lack of engineering discipline involved here.
Claude Code has millions of users and like I said had been using the 1.4 canary a lot earlier than 3 months. But even 3 months is an absurdly impressive timeline for this. And its even more insane to think LLMs are only going to get better. Jeez.
Be honest, though: had they shipped earlier—which they probably could have safely done—they would have been called “reckless” by the detractors. There was no way to make them happy here.
Perhaps. But they didn’t, instead they spent months claiming it was done, while maybe adding a bunch of new features (why? Get the base rewrite out first) which only made them look worse.
Everyone was saying they shouldn’t just accept the LLM’s output without cautious review. Seems they took the time to make sure it was a good release. Not sure why that doesn’t sound like a valid reason not to rush to you.
If they had used the time to actually review the code I would agree! But it sure seems like they used the time instead to play whack-a-mole on bugs and cram in about 50 new, completely unrelated features. That implies they still have not actually reviewed the code they are shipping.
We’re literally on a thread discussing the release notes, which are filled with new features.
> Also, fixing bugs is good.
Yes, fixing bugs is good. The Bun team should have spent time on that in the first place, instead of creating a bunch more with this marketing fueled rewrite.
Not sure why people try so hard to interpret this in such a hostile way. It's very obvious that the 11 days were for the faithful, mechanical, agentic port, and then they followed up by commanding refactoring. The comments about the faithful port not being idiomatic rust are annoying
167 comments
[ 1.2 ms ] story [ 14.0 ms ] threadWhy would I want everything reimplemented in this massive binary? Why would Bun be anymore in touch with nuances of all these different technologies then individual projects dedicated to their own speciality?
JS Runtime, Package Manager, Test Runner (both unit and headless browser), Bundler, JSX, PosgreSQL/MySQL/SQLite drivers, S3 client, Redis client, Formatter, Linter, etc.
Not to mention parsers for YAML, TOML, Markdown which are easily three separate projects worth of complexity in their own right.
I guess one clear downside is to get all these great features they're pushing for 1.4 you needed to wait until all these features were ready. Given 1.3 was pushed out in October 2025, a 10 month release cycle is tough.
It's funny because the top article on HN is about a malicious rust crate package, and people keep making comparisons to js/npm and how both language suffer from frequent security issues because they have weak std libs.
I assume the same benefit applies to humans as well!
When the LLM can verify its own output by running static analysis they produce better results. They also seem to understand type definitions and avoid going to the source which, in theory, should reduce context size.
So yeah others are catching on the importance of a type system to enforce that successful contract for AI agents.
This is coming from someone working 13 years as Ruby dev. I love the language, but I want to be honest that I didn’t had experience with other languages before and seeing statically typed languages (Java, TypeScript), Elixir opened my mind to the amount of cargo cult inside Ruby community stemming mostly from people limited to knowing only 1 language.
Tbh we need to do some real research about it, because all those articles are just feelings that it seems to work better. But mostly it feels better, because we got stronger models and improved agent harnesses
(1) scare quotes because I think it's dumb for us software people to call code we picked up on the side of the road part of a 'supply chain' like that means anything.
A couple years ago a common complaint was that the JavaScript ecosystem relied too heavily on dependencies for everything. Remember the left-pad incident where the developer deleted the popular dependency out of protest for reasons I can even remember? Or when colors.js was sabotaged to break everything that depended on it? The node-ipc package was sabotaged to delete files on developer’s machines. Then we had a wave of supply chain attacks that tried to insert malware into build scripts of popular dependencies.
So the ecosystem started moving toward more batteries-included style development in response.
Add in the influencer dev brainrot culture and you get these VC backed efforts to privatized publicly important projects (node.js) under control of quite evil people that have zero record of helping others.
This isn’t about what individual developers would want but what is most beneficial to Anthropic and claude code. They are likely using Bun as a vehicle for standardizing and enriching local user environments in order to address common tasks that claude generally writes bespoke scripts to accomplish.
JavaScript runtime (obviously), package manager, test runner for unit tests, bundler, JSX, SQLite bindings, formatter, linter, YAML and TOML parsers. Maaaaybe even a Markdown parser and HTML5 parser. Definitely JSON, CSV and XML parsers.
I.e. similar to Python. Though Python is a bit of an incoherent mess. If you have all these you need them to be coherent.
For example, I might well choose to reimplement eg a subset of TOML parsing to avoid the dependency risk.
I don’t write JavaScript/TypeScript, but if I did, I’d find Bun’s “batteries included” approach compelling, at least to the extent I decide I can trust Bun, after due diligence
In 1.3 you couldn't even use the repl without downloading dependencies.
In 1.4 it is now finally built-in, hurray! That alone is why I'm going to install 1.4. Finally a truly portable typescript repl.
Take Python - the standard lib now has things like a toml parser, sqlite client.
And while I avoid the entire JS ecosystem as much as possible, a simple search to find a good Postgres client was not elucidating.
https://wiki.postgresql.org/wiki/List_of_drivers two options - with node-postgres / pg seeming to be the most supported or postgres.js which has more abstractions but is less active
Contrast that to the question for Java, where it's clear the official JDBC driver is the best option.
A year from now folks will be; I can’t use it anymore it’s too unreliable but for now keep looking the other way.
I don't use Bun, so I don't know if quality has degraded. But if it hasn't and they're shipping features users want faster than ever, I wouldn't call it slop. I don't care who wrote the code if the end product is working.
Bun 1.4 Rust rewrite is not looking good https://news.ycombinator.com/item?id=49357401
Yes, I know there's probably better options than Rust for building APIs, but I wanted to learn it, so why not?
Go is a good stdlib and trivial build toolchain.
You just cargo build and all your apes gone.
Backend + web API + the actual web pages all contained in a single file. If you have sane defaults, deploying is literally just copying a single executable over.
- Chet Haase
How is this even possible?
I know we're all using AI, but Bun seems like the one singular project where there's just been a crazy increase in the amount of output, a 10x on the 10x.
How are they doing this?
Jarred spins it as "pre-release" [1] but it was pre-embargo.
[1]: https://bun.com/blog/bun-in-rust#loops-that-write-review-cod....
https://youtu.be/i38DgEuaJwM?si=6oKAysKoRDPCihsL&t=176
slightly aside, but I find it worrying that our industry treats a lot of cannon events in stride and don't organize around that idea or to mitigate the risks around that idea.
things that everybody basically just complained but ended up working out fine,
- Bun rust rewrite. - Elon Musk firing 80% of twitter by stack ranking employees by code committed - autocompletion basically just taking over everyone
maybe I'm just taking extremely outlier outcomes. but it is still fascinating to see people complain about how LLMs don't think
Can't do that anymore though, they keep having "laundry fires".
twitter was a dumpster fire before and now it is (to me) less of a dumpster fire.
so far it seems like the bun rewrite is going quite well. I haven't found any major issues since the merge despite, robobun being the top committer in the repo.
This gives your response away as completely non-serious. You can go troll elsewhere.
twitter has (irrespective of the political turmoil etc.) purely as a technical product added more users, more features etc.
to me that seems like it worked out fine.
> irrespective of the political turmoil.
I was mostly concerned with the technical perspective of firing 80% of people by stack ranking. the consensus in HN at the time was that twitter had months left before all production systems burn down, because all the organizational knowledge has left. but seems like firing 80% went just fine for them. which I find fascinating.
What does that have to do with anything? They very clearly don't "think", that doesn't mean they can't be useful....
Claude building stuff means a lot of things that everybody wanted to do, just couldn't allocate the attention or other resources - now get built.
Mainly node compatibility though more test coverage and different performance improvements.
There was a lot of sentiment around the lines of:
- Bun is done for, it's all slop now
- there's no way a fully AI-written codebase can work
- Jarred is an idiot for trusting AI to rewrite the whole thing
- they're never going to release this, there's going to be a billion of bugs
This release proved all of this wrong. It also serves as a great advertisement of how capable Anthropic models and harness are to enable this.
By every single measurable metric this is better software than the old hand-written version ever was.
We are living in a new world when it comes in how software is prompted into existence.
Hey, did the memory leak really solve with slop rewrite?
> In Bun 1.4, I rewrote Bun in Rust. [...] I did it in 11 days, using Claude Code, and wrote about how, in our blog.
Everything else in the video is phrased as "we", and even the section in the blog post is "We rewrote Bun in Rust"[1].
There's no question Jarred did the work and deserves enormous credit for it. I just found the contrast interesting, because the video explicitly frames the rewrite as "I", whereas the rest of the release frames it as "we".
[1] https://bun.com/blog/bun-v1.4#we-rewrote-bun-in-rust
This isn't so much about Bun or Node.js any more. It is the battleground for AI and non-AI coding.
https://lwn.net/Articles/1086041/
It is, because this rewrite was marketing for Claude. So it reflects the price for what other companies might need to pay if they want to rewrite something else with similar size.
Maybe run it as process 1 in a future ClaudeOS.
This is unmaintable mess, and the author himself is struggling already, given how he pushed the release date ten times.
Jared has always done that. Thats not specific to this 1.4 release.
As opposed to the famously stable and robust JS ecosystem.
Though it feels like the web tooling is thankfully moving away from JS/Node
EG webpack in js => rspack (rust) typescript in typescript => typescript in go (the loss of bootstrapping is a bit sad but worth it)
How about you make a video on something you published and see how you look?
I guess this is much reduced by now, and the effort required on that front should not be rejected from being part of the migration.
But if they went down in cpu usage and memory usage, removed a memory leak, and are MORE compliant with nodejs... it sounds like a MASSIVE success?
Comments here 3 months ago are quite something: https://news.ycombinator.com/item?id=48132488
Internet echo chambers are quite a problem. AI success and its immense implications are wreaking havoc on the ability of even intellectuals in HN and lobsters to face reality in front of them, even as their predictions become falsified again and again.
In this scenario, do you see yourself as an intellectual? In this case, one that is illuminated by the glory of AI. Or just looking for validation and not finding?
> Absolute crickets from the "there's no way LLM's can rewrite Bun to Rust this quickly, it's going to be buggy, it's marketing" crowd
> Comments here 3 months ago are quite something: https://news.ycombinator.com/item?id=48132488
Did you… perhaps read the entire comment you just posted? The crowd that was saying “no way they did that in 11 days” sure seems correct given that the release today is 3 months later. 3 months is longer than 11 days. Significantly so, in fact.
We’re literally on a thread discussing the release notes, which are filled with new features.
> Also, fixing bugs is good.
Yes, fixing bugs is good. The Bun team should have spent time on that in the first place, instead of creating a bunch more with this marketing fueled rewrite.