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.
> 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 still unbelievable, because it still has not happened in this case. The agent wrote it. Nobody thinks it's unbelievable that an LLM can generate a million lines of code in a month. You either do not understand what the detractors are saying or are arguing in bad faith
Perhaps it will happen, but I am yet to see good results from AI code review (it can be useful as an additional review, but not (yet) as the sole source of review).
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.
I think we need to smell the coffee and review npm and scrutinize it because it is getting dangerously out of hand.