Hacker News Reader

Comment by locknitpicker | Hacker News Reader

> As I recall, they picked Deno over Bun during the whole vibecoding rewrite fiasco from six months ago, and there wasn't a ton of explanation given beyond the general vibe of "ai bad".

Your comment is baffling. Either you lost track of the story or you've opted to post a very simplistic take on the whole Bun fiasco. Bun's ill-advised rewrite had zero technical grounds and the radical drop in release cadence in spite of all the AI backing suggests the project's foundation lays on shaky ground.

View on HN

I don't think that's a good interpretation of what happened.

Bun's release cadence dropped because they had just ported to a new language and they weren't about to release that to their community without letting it settle in for a couple of months first - which they did, by running it in Claude Code on millions of computers.

> (...) they had just ported to a new language and they weren't about to release that to their community without letting it settle (...)

Nonsense. If that was remotely true we would have seen a wealth of maintenance releases immediately following the rewrite, along with feature work.

However, development completely stalled, even though they can throw ungodly amounts of AI compute at the problem.

Don't you notice an incongruence in your remarks?

Development stalled? Here are the stats on commits to Bun in the past six months:

(If it had stalled for a year then yeah, you'd have a point. I've seen projects stall for a year or more due to a rewrite.)

  +------------+--------------+
  | Week of    | Main commits |
  +------------+--------------+
  | 2026-04-13 |           88 |
  | 2026-04-20 |           95 |
  | 2026-04-27 |          200 |
  | 2026-05-04 |           25 |
  | 2026-05-11 |           50 |
  | 2026-05-18 |          148 |
  | 2026-05-25 |           77 |
  | 2026-06-01 |           70 |
  | 2026-06-08 |           37 |
  | 2026-06-15 |           60 |
  | 2026-06-22 |          153 |
  | 2026-06-29 |          102 |
  | 2026-07-06 |          137 |
  | 2026-07-13 |          213 |
  | 2026-07-20 |          210 |
  | 2026-07-27 |          185 |
  | 2026-08-03 |          164 |
  | 2026-08-10 |          316 |
  | 2026-08-17 |          284 |
  | 2026-08-24 |          196 |
  | 2026-08-31 |          157 |
  | 2026-09-07 |          119 |
  | 2026-09-14 |          154 |
  | 2026-09-21 |          123 |
  | 2026-09-28 |           68 |
  | 2026-10-05 |           21 |
  +------------+--------------+
  | Total      |        3,452 |
  +------------+--------------+

For context, the Rust rewrite started May 4th, landed on main May 14th, the last remaining Zig code was deleted June 24th, and the first stable Rust release was cut on August 19th. Prior to that people had to test the daily unstable releases.

I think it takes quite severe motivated reasoning to look at a project that ported from one language to another and shipped to millions of end users without incident (Claude Code users didn't even realize they were running the new version) and conclude it was a "fiasco".

The fiasco was that a lot of people were unhappy about it. I'd be interested in seeing a Venn diagram of people who complained about the Bun rewrite and people who don't like AI-assisted programming. I suspect the overlap is heavy.

Actually, to be fair, the real fiasco was project governance.

If I had built my own project on Bun specifically because it used Zed, and had my own custom Zed extensions, I would be justifiably angry that the project ditched Zed without any community input at all.

If that's your complaint than I think it's credible.

> Development stalled? Here are the stats on commits to Bun in the past six months

You know you're putting up bullshit metrics, not much different than counting lines of code touched by commits.

If you were forthcoming and showed relevant metrics such as release cadence (i.e., what projects declare to be relevant units of work to be delivered to their userbase) you'd be faced with the realization that since march (bun v1.13.14) Bun only managed to put together 4 meager releases:

* Bun v1.14.0 - Aug 20 (first release in 5 whopping months?)

* Bun v1.14.1 - Sep 4

* Bun v1.14.2 - Sep 5 (emergency regression fix)

* Bun v1.14.3 - Oct 10 (just a few hours ago)

This means in the last half year, following the rewrite the project barely managed to put together 3 patch releases. In semver terms this means no feature work, mind you.

Is this what you call productive.

https://github.com/oven-sh/bun/releases

Considering one of those releases was a full rewrite to a new language yes, I do consider that productive.

There were a ton of new features in 1.14.0 - most of the release notes were about new features, the Rust thing was a side note: https://bun.com/blog/bun-v1.4

> It adds Bun.Image, Bun.WebView, Bun.markdown, Bun.cron(), Bun.Terminal, bun run --parallel, bun test --parallel, bun audit fix, bun dedupe, and bun prune. And it rewrites Bun from Zig to Rust.

> Considering one of those releases was a full rewrite (...)

I'm not sure you're you're being serious. It feels you're desperately trying to be disingenuous to avoid addressing the elephant in the room.

Listen: this discussion is on how Bun's release cycle stalled due to the rewrite and after the rewrite.

I repeat: Bun 1.4 was released way back in August. Since the rewrite the project barely managed to release two patch releases,and one of them is a hotfix mere hours after the first patch release. Being able to put together at best two patch releases in two months, specially after a major rewrite that is renowned for failing to follow idiomatic Rust practices and in spite of a bottomless AI budget and a militant attitude towards AI, is a colossal red flag. There is no way around it.

Anthropic acquired Bun in December 2025, so there are two questions here: how much did velocity of feature releases change after the acquisition, and how much did they change after the port to Rust?

One potentially useful way to measure that is to use Bun's TypeScript API definitions as a proxy for "features".

We can look at when those landed on main (which should make them available in a canary release) and when they landed on an actual release.

Here's a table that counts features in that way:

  Month        Main  Released
  -----------  ----  -----------------
  2025-01        20  24 (1.1.43-1.2.2)
  2025-02         5  5 (1.2.3-4)
  2025-03        11  14 (1.2.5-8)
  2025-04        15  15 (1.2.9-11)
  2025-05        19  8 (1.2.12-15)
  2025-06         5  15 (1.2.16-17)
  2025-07         5  3 (1.2.18-19)
  2025-08        21  20 (1.2.20-21)
  2025-09        14  24 (1.2.22-23)
  2025-10         1  1 (1.3.0-1)
  2025-11         6  7 (1.3.2-3)
  2025-12 (A)    17  14 (1.3.4-5)
  2026-01        13  16 (1.3.6-8)
  2026-02         2  1 (1.3.9-10)
  2026-03         9  9 (1.3.11)
  2026-04         4  2 (1.3.12-13)
  2026-05 (R)     9  5 (1.3.14)
  2026-06         7  0 (none)
  2026-07         9  0 (none)
  2026-08        13  29 (1.4.0)
  2026-09         9  6 (1.4.1-2)
  2026-10 *       5  11 (1.4.3)

  Pre-acq      11.1  12.4
  Post-acq      9.0  8.4
  Rust          9.4  8.0

Full details of what feature was added when in this gist: https://gist.github.com/simonw/93709c3b3f70f5c703ddde91b9922... (plus the script to generate it)

Reply on news.ycombinator.com