I don't understand why the git history has been pruned in this fork.
According to the first commit in this fork:
> Squashed as a single orphan commit — the original oven-sh/bun history
isn't relevant to this stripped fork and its shallow clone doesn't
push cleanly to a fresh remote.
IMHO it's always a bad decision to do that. Here, all commit authors are lost. The original history is always relevant.
If I'm taking a project in a completely different direction, with different people, I might not care about commit history very much. But I worry more from a licensing standpoint. Unless a project has a strict copyright re-assignment policy (uncommon) where all contributors sign over their copyright (not just contribute their "patch" under the designated license), the copyrYight history is lost or at best muddled.
Now, in practical terms, one can always go back to the original repo and find it. But if I was doing this in a corporate $DAYJOB, I'd keep the history just to be sure.
One thing to point out is all the author's comments seem LLM generated and so does the README and the latest commit to the branch (large explanation in a comment and then change)..
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.
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
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.
i dont see the point of this to be honest, if rust is actually better for bun why are you people just hating on it for no reason? a software doesnt have to be written in your favourite language for it to work.
bun was a sloppy project is zig and still sloppy in rust
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.
Indeed it's surprising, given the zig compiler famously causes all developers who use it to merge into a single organism with a combined nervous system.
It seems you misunderstand what happened to Bun: Anthropic has burned some investor money for a PR stunt -- our LLM can port this -- and also to punish Zig which dared to ban LLM contributions by taking away a significant project from the ecosystem. It worked, Rust didn't dare to enact a similar ban.
Anthropic tried hard to port using their LLMs but their models were not trained on enough zig corpus hence failed and they blamed it on Zig's principles
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.
You don't need to "justify" Zig's existence. It exists, and people like it, and that's enough. IMHO, I wouldn't use it, but there are valid use cases, even if it's "just" a nicer C.
Back when Bun was announced I was so excited for it. I was onboarding on a large node TypeScript project at the time and the build time and resource usage were killing me. Deno’s compatibility hacks and rough edges with node made it a non-starter.
I thought Bun’s promise of full node compatibility with better devex was a dream come true. Then “1.0” was announced and the first simple script I tried segfaulted Bun. The second threw a random error because the http server didn’t implement some stream api. I knew then that Bun was in the league of Vlang. Over promise and under delivery. Just ship “1.0” anyway for marketing and VC reasons. I haven’t touched it since. 2 people I trust that spent time looking at its code and both said to stay away.
Deno had the quality, but missed on the compat because (initially at least) it had an original and more ambitious vision. At least I’d give them that. Bun promised compat in exchange of any ambitious vision but it offers nothing. It runs on hype and hyperbole.
According to the first commit in this fork:
> Squashed as a single orphan commit — the original oven-sh/bun history isn't relevant to this stripped fork and its shallow clone doesn't push cleanly to a fresh remote.
IMHO it's always a bad decision to do that. Here, all commit authors are lost. The original history is always relevant.
Now, in practical terms, one can always go back to the original repo and find it. But if I was doing this in a corporate $DAYJOB, I'd keep the history just to be sure.
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
> 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.
The author is saying explicitly they don’t want to make a Bun replacement
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 read it as "some forks are successful", and well, you need to fork to be a successful fork.
But by all means I would love to hear some examples of that.
https://news.ycombinator.com/item?id=48966569
What failed?
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.
I thought Bun’s promise of full node compatibility with better devex was a dream come true. Then “1.0” was announced and the first simple script I tried segfaulted Bun. The second threw a random error because the http server didn’t implement some stream api. I knew then that Bun was in the league of Vlang. Over promise and under delivery. Just ship “1.0” anyway for marketing and VC reasons. I haven’t touched it since. 2 people I trust that spent time looking at its code and both said to stay away.
Deno had the quality, but missed on the compat because (initially at least) it had an original and more ambitious vision. At least I’d give them that. Bun promised compat in exchange of any ambitious vision but it offers nothing. It runs on hype and hyperbole.
Huh? Zig was never dependent on Bun for being relevant. Tigerbeetle, for example, is written in Zig.
Forking an "embarassing project" is really something.
Edit: Huh? Downvote explanations are welcome. I wrote only what Andrew Kelley wrote.