I have to say, this whole saga is extremely interesting. Not just from a popcorn-enjoyer's point of view, but as a bit of a bell weather for 2026 software dev.
What's funnier to me is none of them seem to want to abandon npm which keeps getting exploited and hacked. NPM has been the source of just how many industry wide hacks? Three major ones, and a massive supply-chain industry wide campaign against npm. But yeah, bun is the real concern here.
I think we need to smell the coffee and review npm and scrutinize it because it is getting dangerously out of hand.
At the least, my interpretation of deno lore is that they tried to ditch npm and found this limited their adoption so significantly that they had to patch it back in. That would provide sufficient warning to me that attempting to move away from npm was unwise.
Yeah, seems we're going to keep hearing people whine about Bun, while still using npm. This begs the question, what would make for the best NPM alternative?
I really think the actual problem is not the vibe coded aspect, nor questions about supply chain security. It is the apparently reckless and rushed nature of the rewrite which eroded user trust. In the span of about 2 weeks the narrative went from being an experimental branch to be being deployed as a canary ready for public testing. All the while the Jarred from Bun was posting here, promising blog posts and more transparency about what was going on. All that I can find is a single AI generated post (https://bun.com/bun-unsafe-audit) after people raised concerns about the quantity of unsafe calls in the Rust rewrite.
This is ridiculous and the response is entirely expected, it’s not about the code anymore, it’s about people. If you claim that doesn't matter, then I think the user response tells you otherwise. It signaled that Bun was not being transparent while asking people to trust it as a core runtime system. Why would I trust a runtime that actively would just do major changes so callously? There’s a balance between all of this. You don’t need to be as methodical as Python is now with PEPs. I think Swift got similar crap, though, nowhere as bad when it rolled out major language changes out of the blue to support Apple’s own product needs a few years back. This was kept secret and released in one burst, bypassing the entire Language Evolution process they crafted for Swift. Apple’s actions are more understandable by the nature of the company wanting to keep some things under wraps, even though it did erode trust somewhat. Apple is now a 50+ year old Fortune 100 company and Apple engineers really just kinda demurred on the bad taste it left in the community’s mouth, but at the same time, what do you expect from a company with a long history of being rather tight-lipped on major product changes. Bun has not really built this reputation nor has their parent company, but they are asking for that here and I just don’t think they have the leverage to do it.
They could have done this more methodically, made sure that the community and industry were okay with it. Maybe they actually did this more thoughtfully behind the scenes and this entirely a marketing stunt, but their lack of transparency at this moment makes it difficult to give them the benefit of the doubt. Trust is currently in short supply, burning it up on stunts like this is stupid.
Sounds about right. I think the response is a bit of an overreaction at this point, but an understandable and easily preventable one. It would have saved a lot of grief to have been more transparent and set clearer expectations: rather than yolo the experimental code into main, put it in a "v2" branch, publish an expected release timeline with 2.0.0 projected for ~Q4 2026 - Q1 2027, and announce a transition of 1.x to maintenance mode with only security fixes. The technical execution and release planning may or may not be excellent, but the political execution so far feels like an unforced error.
The other frustration is that the folks at Bun seem to entirely not get the problem they are creating for themselves.
One of the responses to this announcement was Jarred asking: “What issue did you run into with the Rust rewrite? If there’s something specific I’ll fix” Dude, this is a comms problem, not a technical problem. Refusing to accept that makes the situation worse and I think it is completely believable if Bun eventually dies over this because it’s clear the folks running the show don’t understand part of the process of winning customers is to build a community where Bun is just considered the obvious choice. I remember awhile back they also forked Zig to do some “optimization” that was pointed out by Zig maintainers to be worthless. There’s a pattern developing here and it’s not a good one.
>“What issue did you run into with the Rust rewrite? If there’s something specific I’ll fix”
Besides, he doesn't mean he'll fix. He means "I'll let our AI vibe code a fix". We'd rather talk to the AI directly at this point, what exact value he adds?
Their whole point was "drop in node replacement" - instead of hitting that target they built an entire framework of tools, seemingly changing focus every month or two, and are now rewriting all that to a new language.
When you have infinite LLM coding monkeys, you don't ever feel the practical need to stop. Only the common sensical need, and if you lack that, you just don't stop. You let the code monkeys pile up more output.
Points to a badly ever-shifting platform at the whims of vibes and people with more coding resources than strategic plans.
Not perfect, but I use Verdaccio to run my own npm server and for third party deps, I clone, eval, and then if it's clean, push a safe copy to my own server (not for everything, just the most sensitive, hardcore stuff but eyeballing building a tool to semi-automate it due to recent chaos). You can even clone from remote URLs (point to a tarball from package.json instead of a version) so I've considered just using a private bucket.
Tedious, but makes the "npm hacked again" posts mostly moot.
pip install pulls in what I've listed in my package list, plus their dependencies which are at most 2 levels deep. The dependency's dependencies are reviewable.
npm install pulls in my dependencies plus god knows what else at god knows how many levels. 500MB of dependencies? The dependency's dependecies are not reviewable.
I wish people would stop trying to compare NPM to PyPi and others. NPM is an unfixable disaster because of the entire mindset and ecosystem around JavaScript.
From my perspective it is a synthesis of "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." and "but npm is the source of all the shiny shiny!".
I kept checking the thread for responses and finally realized it, but too late to edit. I will probably wake up in a few days from a nightmare about this misspelling on HN. Happens all the time, no joke.
I think that in my mind, it was always some sort of weather related bell, like you ring it, when the weather changes.
Hopefully the sheep reference will help me remember.
I have ADHD. I am super sensitive to noise. When other people let their phones ding incessantly, it drives me crazy.
I went hiking in Albania recently. I saw many sheep grazing in the mountains. I wondered about the sheep chosen to wear the bell. Like, was it the same sheep every day? Did the chosen sheep think, "Fuck me this thing is annoying"?
Time will tell. I predict this is just the same 20 year pattern of: people on the internet are irate about $latest_thing, and everyone will move on to some other hot topic.
But surely, whether or not the Internet mob moves on has no bearing on what actual lessons to learn from this saga. Will the vibe rewrite turn out to be a disaster or are LLMs already capable of writing human level code at this scale? That question is interesting no matter the level of attention this gets.
maintaining a fork on the zig version works short term but does open some questions about longterm stability/approach and if features should be cut to make maintenance easier; ie Bun.Image, fetch("", {grpc: true}), Bun.redis since it never got finished, etc
For some reason, when thinking about this, the visual of all the scientists at CERN camping out for the results of the Higgs Boson experiment jumped into my mind.
This is not as big an experiment as that. But, for software dev, it feels very significant.
I wonder how many "behind the curve/not super modern" corporations were using Bun or Deno to begin with.
Part of me thinks it's a mild overreaction. It's not like people audit every line of kernel/driver/BIOS/EFI code before running Linux? As long as the tests pass and the performance doesn't regress and it's secure... why are people so mad that it was vibe coded? Is it because it was an irresponsible thing to do? Maybe?
To be pedantic, tests prove that the code passes the test suite, nothing else. They do not prove by themselves that the code is correct, secure, maintainable, efficient, etc. Those are much harder to measure and have a ton to do with organization, architecture, culture, shared knowledge of the maintainers, etc. All of which is lacking during and after this rewrite.
> As long as the tests pass and the performance doesn't regress...
AMD had 20+ million tests for their FPUs back in the day of Intel's FDIV bug and ACL2 found bugs in their implementations of floating point computation.
Agentic vibe coding is not an application of ACL2 theorem prover to anything. Agentic vibe coding is an opposite of it, it will make its way to pass the tests with any means necessary, be it patching the code, the tests, or expected results.
> it's secure
You can't say that before formal verification. Which is an opposite of what vibe coding is.
> As long as the tests pass and the performance doesn't regress and it's secure... why are people so mad that it was vibe coded?
Because the chances that they had a test suite that was actually comprehensive enough to guarantee correctness through this kind of refactor are approximately zero.
Normally we combine tests with careful "correctness by construction" design work and code review because we know that tests aren't sufficient.
It's actually more like 50 devs, each of them specialized in their own field, with 20+ years programming experience.
And even they make mistakes sometimes (see the recent TOCTOU exploit wave).
What vibecoders never get: it's about stability of software. Nobody will rely on your vibecoded project if even you yourself don't give a damn about any API stability or API contracts.
If you expect others to use vibecode assistants to use your software/library... then what was the reason in the first place to write it, if it's effectively not solving a problem? The whole points of dependencies and packages goes out of the window once the library maintainers start to use slopcoding practices.
This is a very uncharitable interpretation of the twitter post: "It’s a combination of anthropic’s stance of not doing human reviews or any kind of rational roll out and stabilization."
They mention nothing about agents being used, rather focus on humans in the review cycle and some sort of gated roll-out process. Why we would bin these practices in the name of a faster release cycle is an important question & debate.
I kind of agree, but it goes both ways. Has Jarred said that there was no review? I know that he stated that rust bun passes tests. Now, I don't know the amount or quantity of coverage, but as a thought experiment, let's assume they are good. What does that count for?
I think most people believe it unlikely that one million line of codes can be reviewed in one week, and the fact that tests pass does not imply good code.
I have no idea whether the new or old code is/was good, just pointing out what seems like a plausible thought process for people who object to this rewrite.
I think it is interesting, using your framing, to consider why people may or may not believe that one million lines of code could be reviewed.
I mean, until very recently, the idea that one million lines of code could be written (rather than mechanically translated) in a month was unbelievable.
It is clearly the case that times have changed since the tools have been updated. So if we challenge one assumption, why not also challenge the other?
Bun presumably will have access to Mythos, which is purportedly reviewing million line code-bases (Mozilla, etc.) and uncovering real value for the devs of those projects.
I find it hard to deny extrapolating these trends to this Bun rewrite.
But AFAICT he's never suggested they reviewed all the code, and that they didn't seems like a pretty safe assumption given the volume, and timeline.
I personally think the test suite passing counts for something, and I would bet they also set up some pretty intense LLM-powered verification loops and quality gates (which I hope the forthcoming blog post will detail). I've seen mechanical LLM ports that went extremely well (though nowhere near this scale, so we could review the code (which is how I know they went well)).
I think the most hysterical reactions that we are seeing from some people are premature, knee-jerk responses. We're gonna _find out_ if the Rust version really is better than Zig version, and soon.
And even if it is better overall, I think if there is an AI-slop-induced major bug we are definitely gonna know that, too, because we have a highly motivated community of folks ready to tweet the shit out of it the instant it is found.
So even as a pretty heavy daily user of Bun, I'm actually really glad they did this. The value of the public experiment is high, and if new Bun sucks, well, I still have Deno.
I'm saying that AI is going to develop software from here on. I don't think you can expect that a human is going to review every line of code. Not that it's good, but that's just how it is. It's not so different from manufacturing. A human is not reviewing every weld. I see a lot of sloppy beads, but in a lot of cases, it's good enough.
I'm saying that's self-evidently ludicrous. Software is not like welding. Do you think Notch could have become rich and famous by welding? How about Bill Gates, famous as a really consistent welder?
On civil engineering projects, I’m pretty sure a human reviews each weld. For mass-produced things, maybe not, although a company would not look good in a lawsuit if they had inadequate inspection procedures which allowed a fault causing injury or death to occur.
There's no way that AI develops software from now on. It isn't remotely good enough for that, nor has it really gotten better in the past few years. We're going to see a push to use AI, then a move away from it once the dreadful quality of AI slop becomes too obvious to ignore.
> Electrobun aims to be a complete solution-in-a-box for building, updating, and shipping ultra fast, tiny, and cross-platform desktop applications written in Typescript. Under the hood it uses bun to execute the main process and to bundle webview typescript, and has native bindings written in Objc, C++, and several core parts written in zig.
I think it makes sense to stay away from large code bases built using LLMs until it is proven that it is possible to also maintain such code bases using LLMs or using reasonable human effort.
It's alarming how people instantly jump to conclusions that Bun is now "AI slop".
Bun has been almost entirely worked on by LLM's for ~6 months now, long before the Rust re-write (source: https://x.com/jarredsumner/status/2054525268296118363). It already has been proven that LLM's can maintain such codebases.
It's very easy to throw shade like this on software if you've got a bugbear with it. I'm sure you can even come up with a bunch of these "stability" problems when challenged on it. I know I could, for basically any large piece of software that I've ever used.
But really, is bun worse in this regard than any other similarly ambitious open source software within it's first few years?
see that's fine with me if they want to take a year or two of human time and do the rewrite properly
this is a piece of software with no architecture, and whose owners have no regard or respect for architecture. I can virtually guarantee that on average every bug they fix will create one new bug, because that's what it's like to work on software with no intentional architecture
What are you talking about?? Bun in Rust is a port, almost exactly the same code base on a different syntax. The architecture did not change at all. Amazing how people comment without even knowing what they are talking about.
Is it that, or is it just that every software developer, enterprise, dev and non-dev alike has their eyes on Claude Code as the most popular software project ever? Software in general has tons of bugs. People need to understand scale here, and what this looks like in practice. They're doing an incredible job given the circumstances.
I'm not being literal. Revolutionary technology arrives on the scene, is extremely visible, changes a whole industry and frankly creates an entirely new economy. All eyes on Anthropic.
They don't get enough credit for being right in the middle of a revolution, yet still managing to ship something that largely works incredibly well, because this thing is a workhorse.
> It already has been proven that LLM's can maintain such codebases.
It hasn't. Those are two different scenarios. The first is individual PRs into an existing, majority human-authored and understood codebase where the PRs are initiated and merged by humans even if the code is AI generated. The second is AI rewriting AI written code that no human eye has seen. Bun took a conservative, transliteration file-by-file approach so they still understand the data structures and architecture so they will probably be okay though.
I think what they're is all is well as long as they aren't told that LLMs are doing most of the work. Being in the know is the issue here IMO as they would've continued using without a word otherwise.
That explains the massive rise in segfaults since they got acquired.
It’s approaching being as buggy as claude code which I’ve had to stop using even though I have 6 months free of max because it just crashes and freezes all the time.
It's alarming how people are willing to overlook the obvious in-your-face sloppiness of the Bun rewrite. A million lines of code in 9 days, pushed to main branch, forced on the existing userbase irresponsibly.
Nobody understands the code, nor will they be able to maintain it without AI service as an external dependency. Give me a break, I'm not running that monstrosity on my machine. Everyone running production software should move away from Bun purely as a technical decision.
I have an idea on how to tell if a codebase is rotting under AI Agent maintenance.
We can collect and analyze how the coding agent reads code during programming tasks, and see if the code access and token consumption are steadily increasing for similar development tasks. If the code readability doesn't degrade for the agent, the maintainability of the codebase should be fine.
Turns out that if they're unusable by LLMs they're likely unusable by human devs. If you follow sane clean coding principles (like not having godclasses) it turns out coding agents (and humans!) can understand and navigate your codebase, especially if you use recognizable patterns, even with very light documentation.
Agree, agentic coding seem to have shifted the trade-off about over-engineering, I found clean architecture is a good practice for coding agent, so every task have a clean and limited context, only a few directly connected classes or interfaces is relevent to any local modification.
We judge long-term quality of human codebases (at least OS) by ongoing activity; for LLM codebases maybe a consistent or increasing level of activity is a bad smell?
For example, we (and many others) depend heavily on numpy. It's been around for decades and heavily battle tested. If someone came out with a new version of numpy vibe-code rewritten in a week, with assurances that "all tests pass", do you think we would adopt it? Absolutely not. We would have no confidence that there aren't some latent bugs or that we can fully trust the results.
It has nothing to do with AI having rewritten it, it has to do with being battle tested over time. If a team of humans had rewritten it in a week, I wouldn't trust or use it either.
>it has to do with being battle tested over time. If a team of humans had rewritten it in a week, I wouldn't trust or use it either.
"it was made in a week" gets repeated a lot on HN, but the PR wasn't a release. They've been working on the rust rewrite for more than a month and it hasn't shipped.
That's like saying "It took me a month to hand-make this cupboard. If someone made a cupboard in just one day using a machine, do you think I'd trust it?".
Took me a while to understand what you meant by this, and I hope I got it right: If I use a simile or analogie, people will argue about that instead of my point?
Possibly, but my simile was strong enough to be an example. In fact, it's something that happened (still happens to some extent) in carpentry. Note well the absense of any argument against it, but the downvoting.
Great, the author speaks out what everyone thinks but cannot say, either due to being invested in the hype or due to effectively having a gag order from their employers:
In many a brand name company now tokenmaxxing is the name of the game; CryptoBase, FacePaper, AntiqueOptics, tinyflacid, they all use AI usage metrics as part of their perf review these days.
While I'm certainly sceptical of pure LLM (re)-written software, I would have to assume in the case of the cyberattack vector that Anthropic used their new Mythos model to adequately test against.
Maybe someone has more info of them mentioning that.
How does one determine what "adequate" looks like for a million lines of code?
You can't fit a million lines of code in a 1M token context window unless every line of code is one token. So you're just sort of praying you spend enough time/money burning tokens to shake out all the stuff that's bad or wrong.
so they are defending the LLM-generated code using another one of their LLMs, against attacks from yet other LLMs? So regardless of the outcome and impact on us, they win?
I have a very, very hard time believing that. Surely the acquisition left his wealth largely in the form of Anthropic stock, so his personal definition of success is "rep Anthropic so my stock goes up" and at that point he has succeeded.
Me, I still have to be competent to succeed. I don't just get to declare that because I used AI the effort was a success, and I have 0 desire to work with those kinds of people.
This is my first time hearing about Electrobun it sounds like it could be a good alternative to electron. Their site mention CEF bundling as an option has anyone tried this?
I’m confused, isn’t this rewrite still unreleased as of today? Surely people understand that a simple, “do an audit for memory safety” will bring it up to par.
I feel like all the replies have totally missed that this Rust port has (reportedly) thousands and thousands of "unsafe" statements and no human review; I'm no rust dev but that doesn't make me very confident, and probably won't consider Bun for new projects either
The author was pretty clear about his motivation on the language. It's to make it more sustainable for them to maintain bun (instead of directly making bun safer), but the former can and often will result in the latter.
Realistically speaking, when Anthropic acquired Bun, they naturally would have needed a narrative showcasing that their AI excels even at relatively new languages like Zig. But since the Zig camp explicitly declared an anti-AI stance, it makes perfect sense why things played out this way. It's a understandable business realit
I'm not joining the chorus condemning Bun for the vibe-rewrite, and I think it's fascinating whether it turns out to be a complete trainwreck or not. But FFS, it should have been a separate repo.
They're two completely different codebases... even if they are 100% feature parity, it's 100% different code. They should absolutely be separate from each other, with different issues lists. Clean separation of two different codebases isn't a strange concept...
Its not 100% different code though. Docs, build instructions, C++, Typescript...
The issues should absolutely be kept. The rewrite was file by file translation so logic bugs would remain. It's valuable to ensure the memory bugs are in fact fixed. Starting the issues from nothing does not make any sense to me.
Judging by the comments, Bun as a company doesn’t give a single shit about community. The only reason it is in the same repo is tracking down issues, discussions, etc. Those would be hard to migrate.
Right, but it's my understanding that it was done as a PR that was merged to `main`. Sure, anyone could find the last Zig commit and branch off of that, so I guess it's all po-tay-to po-tah-to.
This whole thing of shunning bun is a goofy protest against AI in general by a bunch of programmers about to transition from vastly overpaid to mostly unemployed, sometimes thinly disguised as quality concerns and piggybacking a little bit on the anti-"rewrite it in rust" train.
Still, I can't help but entirely support it. I don't want hard dependencies on gigantic megacorps, or on any single provider who can go rogue. Should have always been able to switch between them, and any of them who made that difficult should have been the ones to be shunned. Completely dropping support for bun is equally bad imo, because now your choices are limited to Microsoft and deno, making deno close to a single point of failure.
Although I have to wonder what would happen if Anthropic threw a couple of bucks at electrobun (lol, not really.)
> This whole thing of shunning bun is a goofy protest against AI in general by a bunch of programmers about to transition from vastly overpaid to mostly unemployed, sometimes thinly disguised as quality concerns and piggybacking a little bit on the anti-"rewrite it in rust" train.
It is interesting how you find millions of people put on the street “goofy”, all while concentrating wealth in the hands of a couple of hyperscalers.