There seems to be some confusion here (including in the linked discussion?) about what this is. This is not continuing the development on the original Bun (Zig) codebase.

It is extracting a subset of that codebase for deployment purposes. The full version of Bun (presumably in Rust?) will continue to be used for actual development.

So it is not a replacement for Bun, but a supplement to it.

https://news.ycombinator.com/item?id=49018157

yeah, no place for amateurs

As usual, most forks created out of community rupture eventually die.

I don't know that there's ever been a high-profile fork of a product acquired by such a fat, mealy, and genuinely unspooling parent as Anthropic's acquisition of Bun before.

But by all means I would love to hear some examples of that.

I think there are quite a few high profile examples where the fork was successful (egcs comes to mind which eventually became the official gcc, also all the BSD flavours). And even when the fork ultimately isn't successful, it sometimes at least forces the original project to adapt (e.g. ffmpeg vs libav).

E.g. "it's difficult to make predicitions, especially about the future" ;)

PS: of course for this specific project I don't quite understand the reason. The original Bun was largely a line-by-line port of esbuild from Go to Zig, so it's not like the original codebase was a marvel of engineering to begin with...

But according to Andrew Kelly, Bun was full of bad Zig practices. So why did they keep pushing forward with Zig?

What makes Bun Bun is all the things that got removed from this project. Node is already powerful enough and well maintained. Why would anyone use this?

> The main design decision is to treat this as a runtime, not a general-purpose Bun replacement. A minimal launcher loads a pre-built entrypoint; features that require package installation, bundling, TypeScript transformation, or bun test are intentionally outside the scope.

The author is saying explicitly they don’t want to make a Bun replacement

Heroic effort, sifting through that code I mean, but frankly I would have started a new one from scratch, the only thing of value is the name/popularity of the original project.

I feel bad for Zig. The desperation to remain relevant now that Bun’s gone. There’s still Ghostty (which I love) and... I’m sure there’s a second thing :(

Why feel bad? If you’re using Zig to write a game or a system tool why should you care if Bun uses it or not? All this drama has very little impact on most users of Zig or its developers (some financial impact, but Andrew had already foreseen that as a risk and avoided depending on it)

libghostty is more impactful than Bun IMO. It doesn’t matter to most other developers that Bun was written in Zig, but that such a a good library is written in Zig could have an impact on whether other devs use Zig to write libraries, or if they consider Zig for their app when having libghostty as a dependency

TigerBeetle is also more important than Bun since Zig is a better match for their needs it was for Bun, and TigerBeetle team seems to be a better partner for the Zig foundation. The Bun/Oven team seemed to be an annoyance rather than a synergetic partner.

But in general, pre-1.0, I think any large project that uses it is just a bonus.

TigerBeetle is the other canonical example.

Spare us the concern trolling, Zig will be fine.