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

131–140 of 188 posts

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

#131

Post by lazzlazzlazz »

Zakis1 wrote: post #7
qsera wrote: post #3

I think it makes sense to stay away from large code bases built using LLMs until it is proven that it is possible to also maintain such code bases using LLMs or using reasonable human effort.

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.

Yeah, bizarre and sad. And, unsurprisingly, Hacker News seems sympathetic. They are getting very old.

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

#132

Post by buu700 »

Eufrat wrote: post #103
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.

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 tr…

Sounds about right. I think the response is a bit of an overreaction at this point, but an understandable and easily preventable one. It would have saved a lot of grief to have been more transparent and set clearer expectations: rather than yolo the experimental code into main, put it in a "v2" branch, publish an expected release timeline with 2.0.0 projected for ~Q4 2026 - Q1 2027, and announce a transition of 1.x to maintenance mode with only security fixes. The technical execution and release planning may or may not be excellent, but the political execution so far feels like an unforced error.

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

#133

Post by eichin »

consumer451 wrote: post #69
Cpoll wrote: post #63

Earlier quoted context omitted.

Trivia: The term is "bellwether," i.e. a wether (castrated sheep) wearing a bell, used to guide the flock.

I kept checking the thread for responses and finally realized it, but too late to edit. I will probably wake up in a few days from a nightmare about this misspelling on HN. Happens all the time, no joke. I think that in my mind, it was always some sort of weather related bell, like you ring it, when the weather changes. Hopefully the sheep reference will help me remember.

I'd suggest reading the Connie Willis novel by that name - no idea if it will actually help, it's just really good writing :-)

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

#134

Post by thayne »

adampunk wrote: post #94
thayne wrote: 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?

I'm not saying that bun shouldn't be written in rust. I'm saying that since it was originally written in zig, there were undoubtedly architecture and design decisions that were made that made sense in zig, but not so much in rust. When rewriting something in a different language, especially one significantly different than the original it is common to need to re-architect some things, and mechanically translating line by line from one language is probably going to result in some low quality code, even if the original was decent.

I think that using AI to translate bun from zig to rust might produce a good starting point. But it was done one file at a time, with minimal human review, and I'm skeptical that the result is quality maintainable code.

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

#135

Post by adampunk »

thayne wrote: post #134
adampunk wrote: post #94

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?

I'm not saying that bun shouldn't be written in rust. I'm saying that since it was originally written in zig, there were undoubtedly architecture and design decisions that were made that made sense in zig, but not so much in rust. When rewriting something in a different language, especially one significantly different than the original it is common to need to re-architect some things, and mechanically translating lin…

I don't want to say that skepticism is unwarranted, but I'm not sure we apply this level of scrutiny with any kind of defensible evenness. I just can't think of a single open source project I use where I'm aware of their refactor cadence and practice. I'm just...not checking in on their feature branches and stuff, and I think most people aren't. I couldn't tell you if the uv maintainers work at 3AM while high on drugs or at 9:30 AM wearing FORTRAN blue ties.

I dunno. I think my sense here is that the bun maintainers did something shocking and dramatic using AI and people are shocked and dramatized. They're not WRONG to be so. But I don't know that the shock comes out of any generalized duty of care we have toward open source tooling. I think the uncomfortable point that bun has been releasing for 6 months with smaller AI code edits hasn't really been reckoned with. If we were actually this invested in what was happening, the migration would've begun months ago when it was clear they were using agents to ship code faster than they were willing to review.

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

#136

Post by versecafe »

stephbook wrote: post #33
jakobnissen wrote: post #31

Earlier quoted context omitted.

But surely, whether or not the Internet mob moves on has no bearing on what actual lessons to learn from this saga. Will the vibe rewrite turn out to be a disaster or are LLMs already capable of writing human level code at this scale? That question is interesting no matter the level of attention this gets.

I'm believe projects that pin old versions or maintain their own shoddy fork will be left behind. Deprecation is fine.

maintaining a fork on the zig version works short term but does open some questions about longterm stability/approach and if features should be cut to make maintenance easier; ie Bun.Image, fetch("", {grpc: true}), Bun.redis since it never got finished, etc

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

#137

Post by soraminazuki »

brabel wrote: post #95
soraminazuki wrote: post #73

Earlier 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…

So now you've gone from making assumptions to making up wild stories territory. Well, the commit granularity isn't that of transpiler passes, and more importantly, it's completely irrelevant to how the majority of the code hasn't even been read by anyone.

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

#138

Post by [deleted] »

ibejoeb wrote: post #59
skeeter2020 wrote: post #52

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

[deleted]

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

#139

Post by queenkjuul »

I feel like all the replies have totally missed that this Rust port has (reportedly) thousands and thousands of "unsafe" statements and no human review; I'm no rust dev but that doesn't make me very confident, and probably won't consider Bun for new projects either

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

#140

Post by Eufrat »

buu700 wrote: post #132
Eufrat wrote: post #103

Earlier quoted context omitted.

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 tr…

Sounds about right. I think the response is a bit of an overreaction at this point, but an understandable and easily preventable one. It would have saved a lot of grief to have been more transparent and set clearer expectations: rather than yolo the experimental code into main, put it in a "v2" branch, publish an expected release timeline with 2.0.0 projected for ~Q4 2026 - Q1 2027, and announce a transition of 1.x t…

The other frustration is that the folks at Bun seem to entirely not get the problem they are creating for themselves.

One of the responses to this announcement was Jarred asking: “What issue did you run into with the Rust rewrite? If there’s something specific I’ll fix” Dude, this is a comms problem, not a technical problem. Refusing to accept that makes the situation worse and I think it is completely believable if Bun eventually dies over this because it’s clear the folks running the show don’t understand part of the process of winning customers is to build a community where Bun is just considered the obvious choice. I remember awhile back they also forked Zig to do some “optimization” that was pointed out by Zig maintainers to be worthless. There’s a pattern developing here and it’s not a good one.

Post reply on HN