Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitter.com

Post reply on HN
Print view View original

91–100 of 188 posts

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

#91

Post by thayne »

brabel wrote: post #66
conartist6 wrote: post #49

Earlier quoted context omitted.

see that's fine with me if they want to take a year or two of human time and do the rewrite properly this is a piece of software with no architecture, and whose owners have no regard or respect for architecture. I can virtually guarantee that on average every bug they fix will create one new bug, because that's what it's like to work on software with no intentional architecture

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.

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.

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

#92

Post by youre-wrong3 »

tmp10423288442 wrote: post #83
ibejoeb wrote: 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.

> A human is not reviewing every weld. 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.

> On civil engineering projects, I’m pretty sure a human reviews each weld.

Nope. It’s sampled.

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

#93

Post by dahs12 »

MuffinFlavored wrote: post #88
consumer451 wrote: post #2

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 isn't about users auditing Linux. The Bun developers don't audit "their own" (stolen) vibe code output. How would anyone know if it is secure?

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

#94

Post by adampunk »

thayne wrote: post #91
brabel wrote: 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.

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?

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

#95

Post by brabel »

soraminazuki wrote: post #73
brabel wrote: 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.

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 languages, so architecture-wise I would think the exact same thing would work fine. I am not sure whether the LLM actually wrote a transpiler which just followed the rules, or if it did the job itself, since that information is not public yet, as far as I know, but my guess is that the LLM wrote a transpiler to do the job, then reviewed/fixed compilation issues, then fixed tests. And I'm pretty sure some human interaction was part of that as well.

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

#97

Post by bastawhiz »

mentalgear wrote: post #14

While I'm certainly sceptical of pure LLM (re)-written software, I would have to assume in the case of the cyberattack vector that Anthropic used their new Mythos model to adequately test against. Maybe someone has more info of them mentioning that.

> to adequately test against

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.

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

#98

Post by bastawhiz »

sigmar wrote: post #72
insane_dreamer wrote: post #65

This makes a lot of sense. 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 no…

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

One week to four weeks doesn't make it better.

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

#99

Post by dbalatero »

brabel wrote: post #67
wiseowise wrote: post #50

Earlier quoted context omitted.

Claude Code isn’t a runtime that I use to execute my code with.

If you use it to write code for you, then it kind of is, indirectly.

That is quite the stretch you're making.

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

#100

Post by rglover »

pier25 wrote: post #86
giancarlostoro wrote: post #64

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.

> none of them seem to want to abandon npm which keeps getting exploited and hacked Do you know of a better alternative for JS/TS that has all the popular packages?

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.

Post reply on HN