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.
Yeah, this is one thing you should absolutely never, ever do as a responsible developer. It makes future debugging much more difficult (destroys git blame) and also is a huge dump on previous contributors who don't get credit for their work in the fork. If solenopsys is serious about the fork he should redo it. Throwing away history willy-nilly is such a giant red flag that I think he will have trouble attracting any contributors.
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.”
Wasn't the point of the Ship of Theseus precisely that establishing wether something is or isn't something else is at least complicated? Using it right after saying "X is still Y" kind of seems to make the opposite point.
The point here is that even though the water is murky about it's intrinsic identity, we know that it's still a particular ship with a particular back story, making at least it's extrinsic identity an immutable known. Fairly similar to how - most, if not all - complex living organisms continually gain and lose composing cells throughout their lives, yet their individual identities remain fixed: "I am X and this is my dog Y".
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.
I hate that people git squash merges into dev, it always adds an extra layer of unnecessary ceremony when fixing your original branch, as opposed to just pulling the latest back into your original branch, then fixing the one line or whatever that was affected after merge, and now your git history is incompatible, so you have to delete your local branches because they're pointless now. Git squash should be done before your PR if you want to nuke dumb commits, but I prefer to have it all, if you want to find the key commits, tag them!
Yeah, I'm okay with this particular case to some degree, since its a completely different project, I guess I'm frustrated that I keep seeing projects adopting git squash because some guy somewhere has really terrible commit messages.
You never run a git blame or git bisect to find out when and under which circumstances a regression or bug was introduced, and why this specific change was made? That might work for a while on a personal project, but is essential in a team project. It's not uncommon that by fixing a bug you also accidentially undo an actually intended change. Doing some software archeology in the git history and tracing back the steps that led to the bug/regression usually prevents that sort of thing. You'd also want to notify the person who introduced the bug (and if this is a good and honorable chap, they'll fix the bug themselves).
Simple but pretty common use case: If you're ever looking at some pre-existing code and thinking "I don't really get why it's written like this?", you can get a lot out of looking through the git blame/history.
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.
That actually is helpful, but it would require a git history that actually makes sense. I rarely encounter well thought out git histories. For me its often just dev ramblings or 10 word commit messages
If I can choose "badly maintained history" and "no history" I'll choose the former every time. That's even less of a problem when Claude can do a first pass for you.
Because there will be a reason why the code was changed that introduced the bug. If you fix the bug you might inadvertently break a different piece of functionality.
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.
I'm just going to answer this one candidly. Yes, you are doing something wrong. Immediately: the commit history is useful to understand the context in which a bug was introduced, because it's the best context to understand the _reason_ the mistake was maybe, which is a really good way to prevent regressions. But more generally: when an entire industry has arrived at an accepted practice, you the junior developer (sorry, 5 years is _nothing_: you need to be told this too) have a chance to pick up on it.
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.
You can of course choose alternate strategies. It comes up a lot when doing low level systems programming because the bugs can be non-trivial to repro and root cause (particularly for C/C++ where you have segfaults and whatnot). So it’s cheaper and faster to try a bisect to find the regression introduction as an additional clue in the root cause analysis (eg ownership rules changed or there were changes that looked correct regarding threading but when you hyper focus on it you realize what the problem is). Or you’re working on a high performance codebase and there was a performance regression - it can be faster to bisect than it is to try to find the issue with profiling tools (I had this and seen issues where profiling tools would never have told you the issue).
I would ignore it if I spotted it once. This is the second time, though, so I probably should point it out: 5 years is a very short time in terms of personal experience and development. While the whole industry moves very fast, it does so thanks to slow, grinding effort parallelized over hundreds of thousands of individuals. For an organization, 5 years is an era. For individuals, it's just 3-6 projects (+/- a few, depending on the context you work in).
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.
It depends on the size of the project (mostly in terms of number of active developers) and how close you are to the running code in production.
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.
Probably, because in my 20 year career I have encountered it plenty except back the first couple of years as a junior developer when I did not know my tools and did not know that I should do this.
> A git commit [ideally] gives you the reason for the change
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).
Fair. Though I find it works well when commits get squished at the PR level. That way you have a link to a (hopefully!) detailed overview of what happened, when and why.
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.
Diagnosing why a bug happened is interesting. Sometimes it points to a communication shortcoming that the project/organization should strive to improve on. Of course, if you're slinging code with a few buddies, it might not matter.
In the worst/most paranoid case (xz) you might also want to know who planted a backdoor and where else they made commits to.
Checking git history is one of the first things I do when I find unfamiliar code or when I'm debugging something. Git history contains a lot of context that helps speed up the rest of the process
You've truly never come across a single thing you've gone to "fix" only to have it break stuff and then explained why it needs to stay that way in a commit message?
There are several possible reasons for that, but I'll just say it's a very common use case. It's actually the one of the original use cases for SCSs. How else could you revert to a prior commit?
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.
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.
> My idea is to strip the system down as much as possible and leave only what is required for production.
> 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.
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 developer is quite clear about not wanting to make Bun. They want to make a reusable JavaScript runtime for Zig. How would you execute a Node runtime in Zig?
That’s about the most basic imaginable implementation. Typically you use JavaScript runtimes like this to provide a plugin-like system for your static build that allows sandboxed customisation at runtime.
Take a look at the JavaScriptCore documentation to get a sense of what’s possible, it goes far beyond “piping the input”:
But what does bun bring to the table in that scenario? Why not interface with javascriptcore directly and skip the (unmaintained) middle man?
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.
> But what does bun bring to the table in that scenario?
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 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
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
Please re-read my comment, I didn't mention anything about Rust. (IK they later switched to Rust. A year ago no LLMs were good at rust, similar to zig today, however its different story now)
I can see why that's the case, given that Rust is that much more popular than Zig. I wonder whether there's a difference between LLMs reading code and writing. If reading code is easier than writing it, then it makes sense that Claude was able to port from Zig to Rust with good results.
Aside from relative lack of examples, Zig also changes fundamentally from version to version.
LLMs are fundamentally pattern recognizers though. Bun is big with lots of repeated conventions - very straight forward to translate those conventions to others (zig to rust)
I’ve been building a toy game engine for learning and have had great success translating small C libs (collision detection and physics for instance) into zig, often in one shot.
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)..
You can point it out, but we should also mentioning that the author also points it out:
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.
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
> Bun stopped shipping a Zig-based runtime after 1.3.14 — the project moved on to a Rust rewrite. Cruller forks that last Zig-era Bun and ports it forward to Zig 0.16 instead of following Bun into its rewrite.
I might be missing something, but where does it mention why specifically they're interested in having this be Zig and not Rust?
> 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.
I think it's the other way around. Bun is being ported from Zig to Rust for no significant benefit, but just for the sake of using AI. Bun doesn't gain any significant performance improvements. The codebase is now filled with unsafe blocks, which undermines many of Rust's safety guarantees. On top of that, it hasn't undergone enough real-world testing to ensure it works correctly.
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.
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.
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.
Yeah, and of they want to only keep history for the subset thet are interested in there is always git filter-branch.
Yeah, this is one thing you should absolutely never, ever do as a responsible developer. It makes future debugging much more difficult (destroys git blame) and also is a huge dump on previous contributors who don't get credit for their work in the fork. If solenopsys is serious about the fork he should redo it. Throwing away history willy-nilly is such a giant red flag that I think he will have trouble attracting any contributors.
> in this fork
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.”
That's a fork.
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.
A new project based primarily on existing code is still a fork. Also Ship of Theseus.
Wasn't the point of the Ship of Theseus precisely that establishing wether something is or isn't something else is at least complicated? Using it right after saying "X is still Y" kind of seems to make the opposite point.
The point here is that even though the water is murky about it's intrinsic identity, we know that it's still a particular ship with a particular back story, making at least it's extrinsic identity an immutable known. Fairly similar to how - most, if not all - complex living organisms continually gain and lose composing cells throughout their lives, yet their individual identities remain fixed: "I am X and this is my dog Y".
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.
I hate that people git squash merges into dev, it always adds an extra layer of unnecessary ceremony when fixing your original branch, as opposed to just pulling the latest back into your original branch, then fixing the one line or whatever that was affected after merge, and now your git history is incompatible, so you have to delete your local branches because they're pointless now. Git squash should be done before your PR if you want to nuke dumb commits, but I prefer to have it all, if you want to find the key commits, tag them!
This doesn't apply here in this case since this is a continuation of the Zig based bun and the newer bun versions use Rust.
There's no newer upstream changes to merge with the fork
Yeah, I'm okay with this particular case to some degree, since its a completely different project, I guess I'm frustrated that I keep seeing projects adopting git squash because some guy somewhere has really terrible commit messages.
How is the history relevant? Honest question. 5 years in the field I never had a reason to check out the git history of any project I ever worked on.
You never run a git blame or git bisect to find out when and under which circumstances a regression or bug was introduced, and why this specific change was made? That might work for a while on a personal project, but is essential in a team project. It's not uncommon that by fixing a bug you also accidentially undo an actually intended change. Doing some software archeology in the git history and tracing back the steps that led to the bug/regression usually prevents that sort of thing. You'd also want to notify the person who introduced the bug (and if this is a good and honorable chap, they'll fix the bug themselves).
I look at history all the time.
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.
Simple but pretty common use case: If you're ever looking at some pre-existing code and thinking "I don't really get why it's written like this?", you can get a lot out of looking through the git blame/history.
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/
That actually is helpful, but it would require a git history that actually makes sense. I rarely encounter well thought out git histories. For me its often just dev ramblings or 10 word commit messages
If I can choose "badly maintained history" and "no history" I'll choose the former every time. That's even less of a problem when Claude can do a first pass for you.
Claude can smd
Bug is uncovered. Where was it first introduced? Why was the code changed? What did it do before the bug was introduced?
Why would that matter if a bug is uncovered? If you know there's a bug just fix it? Like what use does the bugs history have?
Because there will be a reason why the code was changed that introduced the bug. If you fix the bug you might inadvertently break a different piece of functionality.
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.
Guess I must be doing something wrong to never have encountered this issue in my 5 years.
I'm just going to answer this one candidly. Yes, you are doing something wrong. Immediately: the commit history is useful to understand the context in which a bug was introduced, because it's the best context to understand the _reason_ the mistake was maybe, which is a really good way to prevent regressions. But more generally: when an entire industry has arrived at an accepted practice, you the junior developer (sorry, 5 years is _nothing_: you need to be told this too) have a chance to pick up on it.
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.
You can of course choose alternate strategies. It comes up a lot when doing low level systems programming because the bugs can be non-trivial to repro and root cause (particularly for C/C++ where you have segfaults and whatnot). So it’s cheaper and faster to try a bisect to find the regression introduction as an additional clue in the root cause analysis (eg ownership rules changed or there were changes that looked correct regarding threading but when you hyper focus on it you realize what the problem is). Or you’re working on a high performance codebase and there was a performance regression - it can be faster to bisect than it is to try to find the issue with profiling tools (I had this and seen issues where profiling tools would never have told you the issue).
I would ignore it if I spotted it once. This is the second time, though, so I probably should point it out: 5 years is a very short time in terms of personal experience and development. While the whole industry moves very fast, it does so thanks to slow, grinding effort parallelized over hundreds of thousands of individuals. For an organization, 5 years is an era. For individuals, it's just 3-6 projects (+/- a few, depending on the context you work in).
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.
It depends on the size of the project (mostly in terms of number of active developers) and how close you are to the running code in production.
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.
As you get better at engineering and grow into a senior, you'll find this more valuable.
Probably, because in my 20 year career I have encountered it plenty except back the first couple of years as a junior developer when I did not know my tools and did not know that I should do this.
I'm tempted to suggest you have encountered the issue but your team mates are shielding you from the consequences (with or without their knowledge).
What teammates?
Well that would explain why you wouldn't need a git history.
You do you. But in my twenty years I’ve leaned on it countless times.
> A git commit [ideally] gives you the reason for the change
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).
Fair. Though I find it works well when commits get squished at the PR level. That way you have a link to a (hopefully!) detailed overview of what happened, when and why.
"Bug uncovered" doesn't mean "bug fixed."
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 understand Wine avoiding the flag solution
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.
Diagnosing why a bug happened is interesting. Sometimes it points to a communication shortcoming that the project/organization should strive to improve on. Of course, if you're slinging code with a few buddies, it might not matter.
In the worst/most paranoid case (xz) you might also want to know who planted a backdoor and where else they made commits to.
You can see what the code looked like before the bug was added, and in many cases, just change it back to how it used to be?
The most obvious use case for history is "roll back this entire CL, it's broken".
Chesterton's Fence.
Checking git history is one of the first things I do when I find unfamiliar code or when I'm debugging something. Git history contains a lot of context that helps speed up the rest of the process
Enables the best git command ever: git bisect
Yes! An incredible tool. You'll rarely need to use it, but when you do it's invaluable.
You've truly never come across a single thing you've gone to "fix" only to have it break stuff and then explained why it needs to stay that way in a commit message?
There are several possible reasons for that, but I'll just say it's a very common use case. It's actually the one of the original use cases for SCSs. How else could you revert to a prior commit?
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.
I still would want the history easy to reach because when I find weird code I almost always reach directly to git log.
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.
The discussion is also missing a key point. Bun had a patched version of Zig, this runtime uses upstream Zig.
yeah, no place for amateurs
> My idea is to strip the system down as much as possible and leave only what is required for production.
> 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.
Hard agree, I would never use a totally different piece of software to run prod vs dev or local.
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...
Same goes for io.js, which got so popular it actually got merged back into Node.js
egcs was almost 30 years ago, fwiw.
...strange, I remember the drama like it was just yesterday ;)
But anyway, GCC was already an established and popular compiler at that time.
Valkey is going strong still. So is Jellyfin, and Gitea/Forgejo.
Valkey made me forget redis existed in about a day. If I say redis now I actually mean valkey.
Why is valkey better?
They aren’t trying to sell me anything. Better multi-threading, better memory usage, open source, open governance. Redis went corporate.
mariadb
MariaDB feels more like the original devs sold the brand and kept business as usual with a new name, not a community fork.
Good thing there was no Bun community then.
What is the point of the comment?
I read it as "some forks are successful", and well, you need to fork to be a successful fork.
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 developer is quite clear about not wanting to make Bun. They want to make a reusable JavaScript runtime for Zig. How would you execute a Node runtime in Zig?
Spawning a process and piping the input? This does require having a node available at runtime though.
Isn’t the main point of using zig to avoid having a runtime and garbage collection to begin with?
That’s about the most basic imaginable implementation. Typically you use JavaScript runtimes like this to provide a plugin-like system for your static build that allows sandboxed customisation at runtime.
Take a look at the JavaScriptCore documentation to get a sense of what’s possible, it goes far beyond “piping the input”:
https://developer.apple.com/documentation/javascriptcore
But what does bun bring to the table in that scenario? Why not interface with javascriptcore directly and skip the (unmaintained) middle man?
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.
> But what does bun bring to the table in that scenario?
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.
Compiling to a single binary for prod is the killer feature imo.
> 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
[flagged]
But according to Andrew Kelly, Bun was full of bad Zig practices. So why did they keep pushing forward with Zig?
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.
The Zirgs they call them (I'm kidding)
https://en.wiktionary.org/wiki/zirgs
Because their ego got hurt that a big project decided to not use their "amazing" language.
No it's vice versa
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
Claude Code uses Bun written in Rust now
https://news.ycombinator.com/item?id=48966569
What failed?
Please re-read my comment, I didn't mention anything about Rust. (IK they later switched to Rust. A year ago no LLMs were good at rust, similar to zig today, however its different story now)
You wrote "port", perhaps you meant "maintain"?
What failed?
… failed to maintain it in Zig due to the LLM issues. You misread
Do you have a source for that?
I work with both Rust and Zig. Claude is much more efficient (~ magnitude in time) and correct (output actually compiles) with rust.
I can see why that's the case, given that Rust is that much more popular than Zig. I wonder whether there's a difference between LLMs reading code and writing. If reading code is easier than writing it, then it makes sense that Claude was able to port from Zig to Rust with good results.
Aside from relative lack of examples, Zig also changes fundamentally from version to version.
LLMs are fundamentally pattern recognizers though. Bun is big with lots of repeated conventions - very straight forward to translate those conventions to others (zig to rust)
I’ve been building a toy game engine for learning and have had great success translating small C libs (collision detection and physics for instance) into zig, often in one shot.
Why would Anthropic ever admit this?
They wouldn't. But I was curious why you were confident that Anthropic "blamed" on anything.
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)..
You can point it out, but we should also mentioning that the author also points it out:
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.
This got me thinking, What if you feed Bun's code into AI, and instead of Rewriting it in Rust, tell it to follow TigerStyle as much as possible?
This is one of the main points of TigerStyle:
> Allocate all memory at startup. Don't allocate after initialization.
It's not compatible with bun. It's not compatible with most programs.
The statement is weird, of course it is aiming at replacing bun, and it might not be a bad thing. Not sure what that clarification serves.
Nice this is going to be a fun project to watch for 2 weeks before everyone forgets about it!
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
The repo calls out the purpose and it's pretty good.
> Bun stopped shipping a Zig-based runtime after 1.3.14 — the project moved on to a Rust rewrite. Cruller forks that last Zig-era Bun and ports it forward to Zig 0.16 instead of following Bun into its rewrite.
I might be missing something, but where does it mention why specifically they're interested in having this be Zig and not Rust?
> 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.
Sorry, not repo, the link.
I think it's the other way around. Bun is being ported from Zig to Rust for no significant benefit, but just for the sake of using AI. Bun doesn't gain any significant performance improvements. The codebase is now filled with unsafe blocks, which undermines many of Rust's safety guarantees. On top of that, it hasn't undergone enough real-world testing to ensure it works correctly.
Does it work with WSL1? That’s all I care about.
Why wouldn't it?
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.
[dead]
[flagged]
[flagged]
[flagged]
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.
This is really clutching at straws to justify zigs existence.
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.
TigerBeetle is the other canonical example.
Spare us the concern trolling, Zig will be fine.
> The desperation to remain relevant now that Bun’s gone
Huh? Zig was never dependent on Bun for being relevant. Tigerbeetle, for example, is written in Zig.
I feel bad for C++. Oh wait, I don't.
Oh no, it tastes like Andrew Kelleys problem again!
Forking an "embarassing project" is really something.
Edit: Huh? Downvote explanations are welcome. I wrote only what Andrew Kelley wrote.
Andrew probably doesn’t control what the entire community does