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.
Concrete example: yabridge is a tool to let Linux users run DAW plugins designed for Windows. Some changes to Wine (yabridge's main dependency) made yabridge stop working, and those Wine changes are not going to be undone as they advance progress on Wine's own bug list. When those changes were made, there wasn't a clear way to change the yabridge code to work with the modified Wine functions.
At the very least, if Wine and yabridge didn't keep a history of their code, you wouldn't be able to download and build Wine 9.21 staging, when yabridge worked.
Every few weeks, a new dev will find this problem and look into fixing it. By having a history, this dev can always look back on the working implementation. Maybe one day there will be a series of function calls in the new Wine codebase that gets the same behavior that worked before? Maybe Wine adds a flag for yabridge that reintroduces the old functionality but retains the changes they decided were necessary. Both avenues would fix the bug but from different ends.
I haven't opened my DAW in a few months, but last I knew, the problem is resolved for most users but not all.
A git commit gives you the reason for the change and the context of what other files were changed at the same time. I’ve found that invaluable.
The most obvious use case for history is "roll back this entire CL, it's broken".
Often "weird design" is there for historic reasons around stuff like backwards compatibility. If your project has a well managed commit log, you can find the notes of whoever implemented it, possibly even with their motivation for doing so.
At the very least, you can find out who wrote that code and ask them about it.
There's a tonne of data in git histories - this article was shared a few months back and is an awesome example of some things you can do with git history: https://piechowski.io/post/git-commands-before-reading-code/
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.
> 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.
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.
The author is saying explicitly they don’t want to make a Bun replacement
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.