> 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 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"?
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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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 already has been proven that LLM's can maintain such codebases.
Proven is a strong word. In my experience AI fails miserably at anything beyond junior level tasks. We will see soon, once bun goes into production.
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?
Is it? Seems like bugs in Claude Code are getting out of hands. That project has a bit more lifetime.
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.
So what you’re saying is that this boycot is 6 months overdue?
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.
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.
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.
And also that it’s capable and trustworthy enough to rewrite the whole runtime in another language flawlessly such that no human needs to code review?
Idiocracy.
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.
yt-dlp - Bun support is now limited and deprecated
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 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.
doesn't make any difference
the point is, users haven't been using it for years, like the original
there is absolutely no way that you can internally test all the use cases that users encounter, especially with such a large code base
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.
What a slap in the face to all the Zig developers that spent their time, effort and probably even some money contributing to it.
https://xcancel.com/YoavCodes/status/2058170216408813583#m
The bun rewrite was Anthropic's Vietnam and the open source community needs to react and and build resistance.
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.)
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.
