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.
I think we need to smell the coffee and review npm and scrutinize it because it is getting dangerously out of hand.
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.
Do you know of a better alternative for JS/TS that has all the popular packages?
Tedious, but makes the "npm hacked again" posts mostly moot.
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.
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.
Points to a badly ever-shifting platform at the whims of vibes and people with more coding resources than strategic plans.
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.
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?
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.
I am building a new JS runtime called cottontail.
It’s just a prototype now but the goal is to have a huge standard library powered by native zig such that you don’t need npm.
So you’re right that npm is a disaster and I’m working on solving.
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 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"?
This is not as big an experiment as that. But, for software dev, it feels very significant.
I'm also glad I don't use bun
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?
I don't know, I see both sides.
That's basically Torvolds full time job?
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.
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.
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...
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
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 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 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.
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
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.
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.
Nope. It’s sampled.