Live data from Hacker News

Bun 1.4 Rust rewrite is not looking good?

tipiirai.com

91–100 of 153 posts

Re: Bun 1.4 Rust rewrite is not looking good?

#91
post #86

Lots of people are apparently happily using the canary version in prod. Anthropic has been using it for ages now, as has Prisma. Why not release 1.4 (or 2.0 or whatever) then? It won't get picked up by lots of tooling and won't get allowed in many "no pre-release in prod" shops until then. It had plenty of issues before (many thousands of open issues) so a few thousand more is hardly a big deal...

TFA shows that they are working on releasing it. If you actually want an answer to your question, ask Jarred ... you won't get it here.

No, the article shows that Jarred is claiming to be working on releasing it. And maybe he is, but he's also not provided reasons for the repeated delays, so for all we know he's goofing off drinking pina colladas while Claude is running the show and Tweeting on his behalf.

Re: Bun 1.4 Rust rewrite is not looking good?

#92
post #70

Earlier quoted context omitted.

People _really_ don't want there to be success stories for llms and they will go through all lengths to discredit and disparage folks successfully exploring the space.

It is yet to be determined whether or not the bun rewrite is a success, though.

What are the standards for determining that?

The most obvious benefit Rust can give them is being safe from memory leaks. This is hardly controversial: it has been a Zig design choice that memory leaks are the developer/user's responsibility. They have already demonstrated to have fixed several of those [0].

Marketing-wise, it has been an obvious success. Dunno if that matters.

[0] https://bun.com/blog/bun-in-rust

Re: Bun 1.4 Rust rewrite is not looking good?

#93
I think the rewrite will end up being more expensive (for the same quality) because AI was used.

At the same time this specific rewrite is being used to drive the narrative that reading the code is counterproductive.

If they had delivered their promises, they might have convincingly delivered that argument.

...but the cost keeps going up and up and up and up! If it was only the token costs it might still be economically viable, but I'm imagining that when you add in the pro-rated salaries of the human engineers this would start to look like a financial blunder even if it released today.

It's true that I don't want a success story told about a failure, because then replicating the "success" would likely produce lots more bad outcomes

Re: Bun 1.4 Rust rewrite is not looking good?

#94
post #4

> The last three months have not looked good for Bun. Apart from pro-AI or anti-AI posturing how have the last few months not looked good for Bun, exactly? I use it daily and I've seen basically zero regressions. I get it, you don't like AI or you like Zig over Rust, or whatever. I just haven't seen any serious argument that Bun has somehow become worse software. > The project has over 5k open pull requests, which is…

> how have the last few months not looked good for Bun, exactly? The article answers this. hint: they're not shipping. > I get it, you don't like AI or you like Zig over Rust, or whatever The article doesn't argue for either of these. hint: it's arguing that the team is not shipping. > Terrible argument, and not really an argument at all. It's an argument for the devs not shipping > I agree, so look at the code and p…

I guess Claude too gets stuck on "wait! Let me think this through..." eventually.

Re: Bun 1.4 Rust rewrite is not looking good?

#95
post #4

> The last three months have not looked good for Bun. Apart from pro-AI or anti-AI posturing how have the last few months not looked good for Bun, exactly? I use it daily and I've seen basically zero regressions. I get it, you don't like AI or you like Zig over Rust, or whatever. I just haven't seen any serious argument that Bun has somehow become worse software. > The project has over 5k open pull requests, which is…

> how have the last few months not looked good for Bun, exactly? The article answers this. hint: they're not shipping. > I get it, you don't like AI or you like Zig over Rust, or whatever The article doesn't argue for either of these. hint: it's arguing that the team is not shipping. > Terrible argument, and not really an argument at all. It's an argument for the devs not shipping > I agree, so look at the code and p…

Chris Newman fan?

You should have lead with “What is it now?”

Re: Bun 1.4 Rust rewrite is not looking good?

#96
post #92
post #70

Earlier quoted context omitted.

It is yet to be determined whether or not the bun rewrite is a success, though.

What are the standards for determining that? The most obvious benefit Rust can give them is being safe from memory leaks. This is hardly controversial: it has been a Zig design choice that memory leaks are the developer/user's responsibility. They have already demonstrated to have fixed several of those [0]. Marketing-wise, it has been an obvious success. Dunno if that matters. [0] https://bun.com/blog/bun-in-rust

Rust also doesn't prevent memory leaks: you can create memory leaks through reference cycles just fine in rust.

Re: Bun 1.4 Rust rewrite is not looking good?

#97
I'm really skeptical about this rewrite I chose to adopt bun about a year ago, and I've honestly lost count of the number of issues i've submitted and the amount of time i've wasted dealing with them. If I had to make the choice again, I would probably stick with node and pnpm for serious projects We're constantly being sold on promises of -XX% ram usage, but in practice, it's often builds randomly failing for no apparent reason, memory leaks bringing applications down, and instability that ends up costing far more in engineering time than the resources saved That's why i'm worried that bun 1.4 could end up being a step backwards, once again putting into question the small amount of stability we've managed to achieve so far

But I still strongly believe the project makes a lot of sense, and I genuinely think these issues can be solved by 2028, if the project keeps its focus on stability instead of another SDK for SQL, web sockets, image compression, or whatever comes next

Re: Bun 1.4 Rust rewrite is not looking good?

#98

Earlier quoted context omitted.

> What are you talking about? I think GP was pointing out how bun's release cadence stalled and the project is going nowhere at the moment. https://github.com/oven-sh/bun/releases The project was pretty healthy up to 1.13.14, but since may they stopped shipping anything. That's quite odd for a project that just went through a major rewrite and is lauded as being developed primarily by LLM coding assistants. Personall…

So they are being more cautious and spending more time on polish after a never been done before historical massive rewrite...? Stop the press! They are not shipping as fast they used to! Omg!

> So they are being more cautious and spending more time on polish after a never been done before historical massive rewrite...?

That's not credible at all. I mean, after a major release there are tons of low-priority low-hanging fruit issues that can be quickly sorted out. That's the nature of a release process.

However, Bun stopped releasing anything. Even after lauding it's AI push,which can easily chomp through small tickets.

It's been a couple of months since the major push. I repeat: the release cadence of a mature, stable codebase as the Zig one was at 2-3 weeks. A messy rust rewrite packed with unsafe code, which is prime ground for small bugfixes and correctness fixes, led the project to grind to a halt.

No one looks good in the picture.

Re: Bun 1.4 Rust rewrite is not looking good?

#100
post #88

Earlier quoted context omitted.

People _really_ don't want there to be success stories for llms and they will go through all lengths to discredit and disparage folks successfully exploring the space.

It isn't LLMs in general, from what I can tell. It was how this port was done and communicated.

It was communicated fine, can you be more specific ?
Post reply on HN