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.
My bet is that Bun is going to die. They kill it with this rewrite bs.
Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
171–180 of 188 posts
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#172Earlier quoted context omitted.
Trivia: The term is "bellwether," i.e. a wether (castrated sheep) wearing a bell, used to guide the flock.
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"?
I don't think it has any choice so it probably accepted fate. I think its the same sheep but no clue if they rotate.
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#173This 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 believe steam does it
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#174Earlier quoted context omitted.
Mist of human written codebases are unusable for llm dev by that definition.
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.
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#175Earlier quoted context omitted.
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.
Are these… real names? I can no longer tell if this is satire.
That is the point ;)
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#176Earlier quoted context omitted.
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? Ma…
> It's not like people audit every line of kernel/driver/BIOS/EFI code before running Linux? That's basically Torvolds full time job?
> 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.
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#177Earlier quoted context omitted.
Who do you mean when you say "none of them"? 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.
https://news.ycombinator.com/item?id=48238789
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?
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#178Earlier quoted context omitted.
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?
No, he's stated the opposite, e.g. https://x.com/jarredsumner/status/2058283214981251080?s=46
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.
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#179Earlier quoted context omitted.
Nobody reviewed resulting code. Maybe all tests are empty and this is why they pass. Maybe tests were modified to pass because this is the only thing LLM could do to make them pass. Maybe it hallucinated something in the process. We have no idea.
We do have an idea, and it contradicts your guess: https://news.ycombinator.com/item?id=48133806
You suggest there is only JS tests that do not need a rewrite? This is crazier than I thought…
I took tests as an example. There are so many other things that can go wrong. Rust and Zig standard libraries may have different semantics not picked up by AI. Like one guarantees insertion order of a dictionary and other does not. Differences in how runtimes react to Linux signals, how they do file IO, etc.
If I were a Bun user I would be moving off from bun unless it has excellent test coverage (which I think it does not). During a normal release cycle I offered a small increment of functionality with small number of issues. Here I’ve been offered a complete rewrite, potentially having thousands of issues. I don’t want to be a guinea pig in this experiment.
I’m genuine curious how this will unfold.
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#180Earlier quoted context omitted.
Very amazing indeed. Here you are making bold assumptions about a huge pile of code not a single human being has ever read in any meaningful amount.
The only assumption you need to make is how the process went about, which was described by Jarred on a HN comment when the PR was first discussed: they had prompt that described exactly how things should be translated, for each "pattern" they were using in Zig, an appropriate equivalent was described in Rust. Zig and Rust are not that different, both are system languages and things can be done similarly in both langu…
>The only assumption you need to make is how the process went about, which was described by Jarred
This is not how the process went. This is how Jarred thinks it went, a huge difference.
>my guess is that the LLM wrote a transpiler to do the job
My guess is different. I think one agent translated code, another compiled it, feeding errors back into translator to fix. Then last agent modifies code to fix tests. All governed by a set of md files.