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.
Not a fork, but a new project that takes a subset of the old Bun code to create something new, meant to complement Bun.
“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.”
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.
> Development would be done using the full Bun runtime, while production would use its lightweight fork, Cruller. I do not have the resources of the Oven team to develop and maintain a massive general-purpose runtime, so I want to focus on specific production requirements.
I don't know about others, but I don't think I would deviate my development runtime from my production runtime so significantly. The chance for behavior that only rears its head in production is too high for my liking.
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...
AI / LLM usage disclosure
AI was used as an engineering assistant for parts of the Zig 0.16 migration, build/debug investigation, and focused test work. The project scope, architecture decisions, review of changes, and build/test verification remain maintainer-directed. This is not a purely AI-generated project.
> Allocate all memory at startup. Don't allocate after initialization.
It's not compatible with bun. It's not compatible with most programs.
[deleted]
[dead]
[dead]
[dead]
[dead]
[dead]
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.
Forking an "embarassing project" is really something.
Edit: Huh? Downvote explanations are welcome. I wrote only what Andrew Kelley wrote.
The git history should have been retained. It's helpful for the files that came over.
There is no good reason to erase all of the history. They should have deleted the files they didn't want to keep in a new commit.
Similarly, a "fork" as we understand it in the context of software is this thing that, even though it's a modified copy, retains its extrinsic identity: "This software X was worked on in Y context, and is now being worked on in Z+ contexts". Same software, even if it gets a name change.
There's no newer upstream changes to merge with the fork
Why is the code like this? Usually git blame will show me either a commit message with extra context or a link to an issue thread.
When was this bug first introduced? Git bisect can track it down almost automatically.
If you're never looking at history you're missing out on a lot of the value Git provides. It's more then just a backup tool.
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/
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.
FTFY ;) I broadly agree, but it's important to note that, in practice, Git commits are hit and miss: they might save you a lot of time if they are well-structured and described properly, but they might also completely fail to give you anything of value (for the problem you're facing at the moment). Turning Git history into a broadly useful artifact requires a lot of discipline from everyone working on a codebase over its lifetime.
It's never totally useless, but it's often less helpful than it could be.
Recently, I turned to JJ for this exact reason: crafting a meaningful change history is much easier there, especially if you need to retrofit it after you're done with the implementation. jj's split, squash, and describe are a joy to work with, also because the interactive version lets you easily split or squash hunks (selected changes in the same file).
> 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.
But anyway, GCC was already an established and popular compiler at that time.
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.
Isn’t the main point of using zig to avoid having a runtime and garbage collection to begin with?
Take a look at the JavaScriptCore documentation to get a sense of what’s possible, it goes far beyond “piping the input”:
Bun provides the node standard library, I suppose, but you likely don't want it in a plugin system. Because the bulk of it is to deal with web requests, or to allow system-wide file/network/process access. So you're going to re-implement your own safe library anyway.
There's a middle ground between "raw C API" and "full Node-compatible runtime". It sounds like this project is attempting to use that middle ground: the Zig wrapper around JavaScriptCore, rather than the whole abandonware project.
As per another comment here:
> This is not continuing the development on the original Bun (Zig) codebase. It is extracting a subset of that codebase for deployment purposes.
The author is saying explicitly they don’t want to make a Bun replacement
[dead]
[deleted]
https://news.ycombinator.com/item?id=48966569
What failed?
I might be missing something, but where does it mention why specifically they're interested in having this be Zig and not Rust?
Sorry, not repo, the link.
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.
Have you heard "have you played guitar for 20 years, or have you played guitar 20 times for a year?" Time only helps with accumulating wisdom if you let it.
TL;DR: "never have encountered in 5 years" is a meaningless data point.
My professional career can legally drink beer since a few years back, yet I'm still regularly hitting "first times" on various things in my day job; I'm also frequently mind-blown reading about others' experiences in domains I never touched. Don't make those "5 years" into a badge to hide behind; use it as a springboard to reach higher.
In this case, try to actively think of uses for the commit history. It's already there; there's an expectation (admittedly, to various degrees depending on context) that it will be maintained. Try to maximize the value you get out of it. Underutilizing a tool you have access to may not be that much of a problem on average, but in some specific circumstances can make a difference between being able to complete a task at all or not. You shouldn't rely on luck to never land in a situation like that: familiarizing yourself with as many potential uses for a tool as possible gives you a better chance of handling it more easily.
EDIT: formatting, last paragraph.
On a large project it's probably the first tool I reach for when we find something we have reason to believe was a recently introduced bug. Specifically annotating (git blame) the relevant code and scanning for what lines have been recently modified.
I've worked in startups where there were only 2 backend devs and a frontend guy. There it was almost completely irrelevant and I spent a couple of years at a large software shop, early in my career, where bugs in production code was mostly someone else's problem.
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 in 2024, and those Wine changes are not going to be undone as they advance progress on Wine's own bug list and test suite. 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 even 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 for everyone else the changes they decided were necessary. Both avenues would fix the bug but from different ends.
(I understand Wine avoiding the flag solution: It's more to maintain just to help a single project, plus it introduces a conditional jump fail in the very active event handler and windowing subsystems affecting nearly every Wine user, and the development of Wine keeps moving, which could make a flag-based workaround redundant in the near future.)
I haven't opened my DAW in a few months. Last I knew, the problem is resolved for most users but not all, and there might have been a major breakthrough in April or May that still hasn't reached end users.
I don’t - Windows keeps a compatibility database for a reason. It seems inevitable that you’d need to maintain that too to keep apps working or drop support. The performance is a non-sequiter for a few reasons. Even in the hot path the conditional is going to get speculated away since the wine subsystem is uniquely instantiated per application. If you were really paranoid you could ship multiple binaries and select which ones to use dynamically at runtime. I suspect the bigger problem is one of maintenance - Microsoft does this with a huge budget and a huge team whose sole responsibility is maintaining that comparability. A community project is going to have to make more pragmatic choices.
In the worst/most paranoid case (xz) you might also want to know who planted a backdoor and where else they made commits to.
The most obvious use case for history is "roll back this entire CL, it's broken".
[deleted]