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.
> Cruller is not intended to replace Bun for development. It is a minimal, specialized runtime for executing production code.
> In any case, I do not want to throw away such a large codebase that has taken several years to build. It makes more sense to turn it into a convenient embeddable library that can be used throughout the Zig ecosystem.
This seems pretty sensible to me. It's nice if the Zig ecosystem has an embeddable JS runtime.
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...
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.
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.
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
> Cruller is not intended to replace Bun for development. It is a minimal, specialized runtime for executing production code.
> In any case, I do not want to throw away such a large codebase that has taken several years to build. It makes more sense to turn it into a convenient embeddable library that can be used throughout the Zig ecosystem.
This seems pretty sensible to me. It's nice if the Zig ecosystem has an embeddable JS runtime.
yeah, no place for amateurs
As usual, most forks created out of community rupture eventually die.
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...
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.
But according to Andrew Kelly, Bun was full of bad Zig practices. So why did they keep pushing forward with Zig?
Because their ego got hurt that a big project decided to not use their "amazing" language.
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.