Earlier quoted context omitted.
None of that makes any sense whatsoever.
Pretty simple: it shipped to the owner.
Aka: internal beta
Bun 1.4 Rust rewrite is not looking good?
101–110 of 153 posts
Re: Bun 1.4 Rust rewrite is not looking good?
#102Earlier 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!
Pretty sure that’s because of the backlash. So, sounds like a good thing people voiced their concerns
Re: Bun 1.4 Rust rewrite is not looking good?
#103Earlier quoted context omitted.
11k out of a million. I wish I had a project under 1% of "dead code".
there are linters that check for dead code (depending on your language / ecosystem), it should always be 0%
You cannot be serious, any person with actual professional software experience would laugh at that claim
Re: Bun 1.4 Rust rewrite is not looking good?
#104Earlier quoted context omitted.
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.
Who cares?
Re: Bun 1.4 Rust rewrite is not looking good?
#105Re: Bun 1.4 Rust rewrite is not looking good?
#106> 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…
>> The project has over 5k open pull requests, which is the largest number of pull requests I’ve seen.
> Terrible argument, and not really an argument at all.
Technically, maybe.
But when you consider for a moment that in this pile of slop some PRs were crafted by actual people who trusted Bun and Jarred... and whose trust has been flushed down the toilet by the Rust rewrite. Well, maybe that's the price of progress. Or maybe that's a grave mistake.
I'm not yet sure which is it.
Re: Bun 1.4 Rust rewrite is not looking good?
#107Earlier 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…
I wouldn't consider it particularly surprising that a big rewrite results in no new releases for a bit before the rewritten version is released.
Isn't supposed to be faster with LLMs?
Re: Bun 1.4 Rust rewrite is not looking good?
#108> 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…
All that sounds great. The promised of shipping for months that never came is a concern, comparatively speaking to history of the project and what is happening. But if we have user feedback suggest otherwise may be it is good.
For most, they are still waiting for official release so they could make their own judgment, the problem is that it is still not released. I guess we should just wait a little longer.
Re: Bun 1.4 Rust rewrite is not looking good?
#109Earlier quoted context omitted.
You have free will
Robert Sapolsky would disagree
I would assume Sapolsky understands how terms are defined by their context, and that someone saying “free will” in a forum discussion about software doesn’t literally imply the strictest, academic definition of the term.
But if not he can reach out
Re: Bun 1.4 Rust rewrite is not looking good?
#110I'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 app…
> 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
If you check the maintainer X, he's asking Claude for what features to implement next. Not only stabilizing isn't the priority, even the features implemented are random.