3 ms·

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

by dvt 1mo ago

> 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 largest number of pull requests I’ve seen. Terrible argument, and not really an argument at all. > The biggest worry is, of course, the code itself. I agree, so look at the code and point out what's wrong with it. Insofar as Andrew Kelley is concerned, it's obvious he has an axe to grind and is salty about Bun embarassing Zig (which he freely admits). Not sure why you'd invoke an unreliable narrator as some sort of final nail in the coffin.

tipiirai 1mo ago
Unused code is one issue. A project called Buz[1] found over 11,000 lines of dead code from the Rust port. [1]: https://github.com/jazzzooo/buz https://github.com/jazzzooo/buz
- unified101 1mo ago
  11k out of a million. I wish I had a project under 1% of "dead code".
  - verdverm 1mo ago
    there are linters that check for dead code (depending on your language / ecosystem), it should always be 0%
    - jibal 1mo ago
      The dead code was removed from the pre-Rust Zig version. The OP has no credibility. P.S. Nor does new user parenting my comments.
      - unified101 1mo ago
        Flag the article and move on.
    - dminik 1mo ago
      I mean, how do you check that your frontend code (possibly not even managed by your team) is calling and needs all of your backend endpoints? I'm sure it can be done, and it probably should, but saying it should always be 0% is not very pragmatic.
      - myvoiceismypass 1mo ago
        Dead code likely means chunks of code not used by other chunks of code, which should be easy to determine statically in most modern languages. Whether an exposed endpoint is being hit (used) or not as an API is more of a test-code-coverage thing, different from the concept of "dead code".
        dminik 1mo ago
        True, but Bun actually has a similar problem. It's creating bindings to a JS runtime. If the JS glue code then no longer uses it, the code is still marked as alive because it's registered with the runtime.
      - touisteur 1mo ago
        In a previous life I managed to deliver a system with (basic-block) coverage measurement compiled in (gcov) but instead of the mess of files gcov generates, the whole coverage structure was streamed to a remote server (it compressed very well). Once that was in place it was an amazing telemetry tool. Later on used Intel Processor Trace in a similar fashion for even finer (mc-dc) coverage. Coverage tools are very useful, if a bit hard to use...
    - dgellow 1mo ago
      You cannot be serious, any person with actual professional software experience would laugh at that claim
- dvt 1mo ago
  First of all, I'd need to see a diff on that. It's insane to make that kind of claim without backing it up. Second of all, dead code (as in truly dead code: like an if statement that is guaranteed to never be true), is optimized away by the compiler. So even if we had all this dead code, it is not an issue that would ever impact the final product. Third of all, the Bun runtime consists of over a million lines of code, so that figure (again, even if true) is insignificant.
  - aureate 1mo ago
    > It's insane to make that kind of claim without backing it up. A bizarre accusation. It's a fork of Bun that says they removed the dead code. All you have to do to see the diffs is look at its history. Most of the commits are code removal. It's a fork of Zig bun, though, not Rust, so hardly relevant to the AI argument.
- aureate 1mo ago
  That was 11,000 lines of dead code removed from pre-rust Bun. In a million lines of vibed Rust Bun I'd be astonished if there was a mere 11,000 unused LoC. Noticing unused code isn't a strength of LLMs in my experience.
- jibal 1mo ago
  Congrats on completely undermining your own argument and credibility. Did you not even read your link? > Buz is an early-stage experimental fork of pre-Rust Bun.... Over 11,000 lines of dead code removed from upstream Bun.
frail_figure 1mo ago
> 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 point out what's wrong with it. It's not being shipped. Hope that helps.
- re-thc 1mo ago
  > The article answers this. hint: they're not shipping. They're shipping though. Claude Code and many others use it. There's just not been a "public" release.
  - aureate 1mo ago
    In other words, it hasn't shipped. The bun rewrite is looked to as proof that this sort of full-throttle vibecoding is the future of software development, at least for large porting projects like this one, and for many people on this site that is a high stakes question. To prove that, a proper release is needed, and the Bun community needs to adopt it. There's a huge partisan eagerness to declare the Claude Code release or anecdotal experiences on the canary as victory, but the viability of 1.4 hasn't been demonstrated until it has been released and adopted by the bulk of the community. There isn't actually any hurry on that. Nobody needs Bun 1.4 tomorrow. It's Jarred that keeps saying it'll be released tomorrow, while the code churns at an astonishing rate (see below). People with a skeptical outlook will inevitably suspect that he doesn't have confidence in the release and is struggling to acquire it. Github insights for the last week: > Excluding merges, 57 authors have pushed 349 commits to main and 6892 commits to all branches. > On main, 2026 files have changed and there have been 189,502 additions and 133,836 deletions
    - re-thc 1mo ago
      > The bun rewrite is looked to as proof that this sort of full-throttle vibecoding is the future of software development To who? You? > To prove that, a proper release is needed For who? Who is trying to prove what? > It's Jarred that keeps saying it'll be released tomorrow There's no official blog... he's just rambling on x? > Github insights for the last week That's the problem with the rest of your post. Bun is no longer VC-fueled open source project. It got sold to Anthropic. > There's a huge partisan eagerness to declare the Claude Code release Hence there isn't. The Claude Code release is for its own use.
locknitpicker 1mo ago
> Apart from pro-AI or anti-AI posturing how have the last few months not looked good for Bun, exactly? The blog post states quite clearly that Bun stopped posting any release. During the Zig/pre-Rust days, Bun was posting s new release each 2-3 weeks. Since then, Bun's Rust migration is correlated with a complete stop of Bun's release cadence.
- cyanydeez 1mo ago
  that could just be de rigeur enshittification.
dimbletimbers 1mo ago
Legitimately curious, are you using the 1.4 canary release in a production environment?
egorfine 1mo ago
>> 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.
ksec 1mo ago
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.
- hiccuphippo 1mo ago
  I say let them cook. Rushed software is not good, neither for the user nor the developers. I say the same for Zig 1.0 What I'd like to see in the meantime is what are the biggest blockers to the release. Maybe Bun has a milestone list somewhere, I couldn't find it.

by dvt 1mo ago

tipiirai 1mo ago

Unused code is one issue. A project called Buz[1] found over 11,000 lines of dead code from the Rust port. [1]: https://github.com/jazzzooo/buz https://github.com/jazzzooo/buz

unified101 1mo ago
11k out of a million. I wish I had a project under 1% of "dead code".
- verdverm 1mo ago
  there are linters that check for dead code (depending on your language / ecosystem), it should always be 0%
  - jibal 1mo ago
    The dead code was removed from the pre-Rust Zig version. The OP has no credibility. P.S. Nor does new user parenting my comments.
    - unified101 1mo ago
      Flag the article and move on.
  - dminik 1mo ago
    I mean, how do you check that your frontend code (possibly not even managed by your team) is calling and needs all of your backend endpoints? I'm sure it can be done, and it probably should, but saying it should always be 0% is not very pragmatic.
    - myvoiceismypass 1mo ago
      Dead code likely means chunks of code not used by other chunks of code, which should be easy to determine statically in most modern languages. Whether an exposed endpoint is being hit (used) or not as an API is more of a test-code-coverage thing, different from the concept of "dead code".
      - dminik 1mo ago
        True, but Bun actually has a similar problem. It's creating bindings to a JS runtime. If the JS glue code then no longer uses it, the code is still marked as alive because it's registered with the runtime.
    - touisteur 1mo ago
      In a previous life I managed to deliver a system with (basic-block) coverage measurement compiled in (gcov) but instead of the mess of files gcov generates, the whole coverage structure was streamed to a remote server (it compressed very well). Once that was in place it was an amazing telemetry tool. Later on used Intel Processor Trace in a similar fashion for even finer (mc-dc) coverage. Coverage tools are very useful, if a bit hard to use...
  - dgellow 1mo ago
    You cannot be serious, any person with actual professional software experience would laugh at that claim
dvt 1mo ago
First of all, I'd need to see a diff on that. It's insane to make that kind of claim without backing it up. Second of all, dead code (as in truly dead code: like an if statement that is guaranteed to never be true), is optimized away by the compiler. So even if we had all this dead code, it is not an issue that would ever impact the final product. Third of all, the Bun runtime consists of over a million lines of code, so that figure (again, even if true) is insignificant.
- aureate 1mo ago
  > It's insane to make that kind of claim without backing it up. A bizarre accusation. It's a fork of Bun that says they removed the dead code. All you have to do to see the diffs is look at its history. Most of the commits are code removal. It's a fork of Zig bun, though, not Rust, so hardly relevant to the AI argument.
aureate 1mo ago
That was 11,000 lines of dead code removed from pre-rust Bun. In a million lines of vibed Rust Bun I'd be astonished if there was a mere 11,000 unused LoC. Noticing unused code isn't a strength of LLMs in my experience.
jibal 1mo ago
Congrats on completely undermining your own argument and credibility. Did you not even read your link? > Buz is an early-stage experimental fork of pre-Rust Bun.... Over 11,000 lines of dead code removed from upstream Bun.

frail_figure 1mo ago

> 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 point out what's wrong with it. It's not being shipped. Hope that helps.

re-thc 1mo ago
> The article answers this. hint: they're not shipping. They're shipping though. Claude Code and many others use it. There's just not been a "public" release.
- aureate 1mo ago
  In other words, it hasn't shipped. The bun rewrite is looked to as proof that this sort of full-throttle vibecoding is the future of software development, at least for large porting projects like this one, and for many people on this site that is a high stakes question. To prove that, a proper release is needed, and the Bun community needs to adopt it. There's a huge partisan eagerness to declare the Claude Code release or anecdotal experiences on the canary as victory, but the viability of 1.4 hasn't been demonstrated until it has been released and adopted by the bulk of the community. There isn't actually any hurry on that. Nobody needs Bun 1.4 tomorrow. It's Jarred that keeps saying it'll be released tomorrow, while the code churns at an astonishing rate (see below). People with a skeptical outlook will inevitably suspect that he doesn't have confidence in the release and is struggling to acquire it. Github insights for the last week: > Excluding merges, 57 authors have pushed 349 commits to main and 6892 commits to all branches. > On main, 2026 files have changed and there have been 189,502 additions and 133,836 deletions
  - re-thc 1mo ago
    > The bun rewrite is looked to as proof that this sort of full-throttle vibecoding is the future of software development To who? You? > To prove that, a proper release is needed For who? Who is trying to prove what? > It's Jarred that keeps saying it'll be released tomorrow There's no official blog... he's just rambling on x? > Github insights for the last week That's the problem with the rest of your post. Bun is no longer VC-fueled open source project. It got sold to Anthropic. > There's a huge partisan eagerness to declare the Claude Code release Hence there isn't. The Claude Code release is for its own use.

locknitpicker 1mo ago

> Apart from pro-AI or anti-AI posturing how have the last few months not looked good for Bun, exactly? The blog post states quite clearly that Bun stopped posting any release. During the Zig/pre-Rust days, Bun was posting s new release each 2-3 weeks. Since then, Bun's Rust migration is correlated with a complete stop of Bun's release cadence.

cyanydeez 1mo ago
that could just be de rigeur enshittification.

dimbletimbers 1mo ago

Legitimately curious, are you using the 1.4 canary release in a production environment?

egorfine 1mo ago

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

ksec 1mo ago

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.

hiccuphippo 1mo ago
I say let them cook. Rushed software is not good, neither for the user nor the developers. I say the same for Zig 1.0 What I'd like to see in the meantime is what are the biggest blockers to the release. Maybe Bun has a milestone list somewhere, I couldn't find it.