Live data from Hacker News

Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite

twitter.com

111–120 of 188 posts

Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite

#112

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 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?

Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite

#113
post #62

Earlier quoted context omitted.

What do you mean? 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.

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.

It hasn't gotten better in the past few years? Come on...

Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite

#114
post #11
post #7

Earlier quoted context omitted.

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 already has been proven that LLM's can maintain such codebases. Is it? Seems like bugs in Claude Code are getting out of hands. That project has a bit more lifetime.

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.

Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite

#115
post #91

Earlier quoted context omitted.

Zig and Rust are significantly different languages. If bun has a good architecture in zig (which I don't know if it does or not), that doesn't necessarily mean it had a good architecture for rust. A direct translation of zig code would probably result in pretty unusual rust code, and probably a lot more unsafe usage than if it had been originally written in rust.

I don’t really understand this objection. For every tool that I use, am I supposed to divine the best underlying language for it and then determine whether or not it is written in that language? Don’t I have better things to do?

What is that tool in relation to the rest of your workshop though? If it's a simple hammer that you can swap out for $20 and you only use it once a month, who cares what kind of metal it's made out of, as long as it works. But if the $6,000 4-axis CNC machine that's at the heart of your machine shop and every minute of downtime on it costs you money, if it's starting to rust, no, you don't have better things to do than to look into what it's made of.

Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite

#116
post #66

Earlier quoted context omitted.

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.

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

Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite

#117

Earlier quoted context omitted.

I don’t really understand this objection. For every tool that I use, am I supposed to divine the best underlying language for it and then determine whether or not it is written in that language? Don’t I have better things to do?

Because of borrow checker you would build data structures differently in Rust compared to Zig. Automated translation simply maps Zig constructs onto unsafe Rust code. I have no idea how feasible it is to go from totally unique way of using Rust to mimic Zig to idiomatic Rust.

I understand that. That’s a specific example of an inaptness moving from one language to another. That’s not what I’m talking about.

I am asking if we are expected to understand this hypothetical condition about all possible tools that we use. Should I have to worry that something is written in Python when it should’ve been written in C? It just seems like that in order to have a big concern here, I had to be really invested in what language Bun used. I guess the whole matter makes more sense if people are REALLY mad about something else and the choice of language is supposed to serve as a more respectable thing to be mad about.

Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite

#118

Earlier quoted context omitted.

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.

It hasn't gotten better in the past few years? Come on...

in some ways it remains exactly the same technology with the same critical weaknesses

Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite

#119

Earlier quoted context omitted.

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.

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

Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite

#120

Earlier quoted context omitted.

I don’t really understand this objection. For every tool that I use, am I supposed to divine the best underlying language for it and then determine whether or not it is written in that language? Don’t I have better things to do?

What is that tool in relation to the rest of your workshop though? If it's a simple hammer that you can swap out for $20 and you only use it once a month, who cares what kind of metal it's made out of, as long as it works. But if the $6,000 4-axis CNC machine that's at the heart of your machine shop and every minute of downtime on it costs you money, if it's starting to rust, no, you don't have better things to do th…

Yeah what if the tool is a JavaScript runner released for free?

What is being expressed here about Bun is using the language of due diligence but doesn’t seem to adhere to any of the sensibilities. Should we all be auditing our toolchains to understand internal decisions that each toolmaker undertakes? Maybe! DO WE? Absolutely not. The level of scrutiny bun is getting is *unusual*. They just did an unusual and dramatic thing, so it’s not surprising. But I just don’t believe that bun is being deprecated due to normal engineering discipline that we are constantly carrying and applying everywhere. That’s…just hard to buy.

Post reply on HN