Live data from Hacker News

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

twitter.com

101–110 of 188 posts

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

#101

Earlier quoted context omitted.

To upper-middle class people, their job is a religion. Investing in a programming language is a decision to gamble thousands of hours of your life for a programmer. At some point of projects shifting away from your language, your mortgage and your children's tuition will be affected.

I’m so glad as a Python developer none of this religious bullshit enters into the equation. Exactly why I left Scala behind.

Your comment is just as religious as any other advocate of a programming language. You're giving reasons why the programming language you chose is the right choice. Kind of like explaining why Yahweh is the one true god, and why you left other gods behind.

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

#102
post #72

Earlier quoted context omitted.

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

Did you miss the part where they said "it hasn't shipped"?

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

#103

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.

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.

I really think the actual problem is not the vibe coded aspect, nor questions about supply chain security. It is the apparently reckless and rushed nature of the rewrite which eroded user trust. In the span of about 2 weeks the narrative went from being an experimental branch to be being deployed as a canary ready for public testing. All the while the Jarred from Bun was posting here, promising blog posts and more transparency about what was going on. All that I can find is a single AI generated post (https://bun.com/bun-unsafe-audit) after people raised concerns about the quantity of unsafe calls in the Rust rewrite.

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.

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

#104

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.

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.

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

#105

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 a more apt analogy (or cliche) is canary in the coalmine.

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

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

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.

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

#107
post #66

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.

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.

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

#108
post #59

Earlier quoted context omitted.

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?

I think most people believe it unlikely that one million line of codes can be reviewed in one week, and the fact that tests pass does not imply good code. 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 think it is interesting, using your framing, to consider why people may or may not believe that one million lines of code could be reviewed.

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.

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

#109

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.

Also Rubygems, Packagist, PyPi

pip install pulls in what I've listed in my package list, plus their dependencies which are at most 2 levels deep. The dependency's dependencies are reviewable.

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.

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

#110

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…

That's like saying "It took me a month to hand-make this cupboard. If someone made a cupboard in just one day using a machine, do you think I'd trust it?".
Post reply on HN