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.
Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
101–110 of 188 posts
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#102Earlier 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.
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#103I 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.
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
#104I 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.
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
#105I 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.
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#106Earlier 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?
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#107Earlier 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.
Re: Electrobun 2.0 will be decoupled from Bun due to the Rust rewrite
#108Earlier 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 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
#109Earlier 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
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
#110This 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…