Hacker News Reader

Comment by locknitpicker | Hacker News Reader

> 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

View on HN

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