Cruller: Bun's Zig Runtime, Continued on Zig 0.16 • Hacker News Board

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#81

Post by klibertp » Thu, Jul 23, 2026, 2:08 PM UTC

afavour wrote: post #52

sevenzero wrote: post #50

Earlier quoted context omitted.

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.

> 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).

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#82

Post by dbalatero » Thu, Jul 23, 2026, 2:18 PM UTC

> 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.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#83

Post by ksec » Thu, Jul 23, 2026, 2:27 PM UTC

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?

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#84

Post by h506001 » Thu, Jul 23, 2026, 2:38 PM UTC

self_awareness wrote: post #29

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

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#85

Post by giancarlostoro » Thu, Jul 23, 2026, 2:42 PM UTC

Skywalker13 wrote: post #37

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.

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!

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#86

Post by simonw » Thu, Jul 23, 2026, 2:43 PM UTC

sevenzero wrote: post #48

Skywalker13 wrote: post #37

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.

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.

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.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#87

Post by afavour » Thu, Jul 23, 2026, 2:47 PM UTC

klibertp wrote: post #81

afavour wrote: post #52

Earlier quoted context omitted.

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.

> 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…

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.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#88

Post by VBprogrammer » Thu, Jul 23, 2026, 2:47 PM UTC

sevenzero wrote: post #59

afavour wrote: post #52

Earlier quoted context omitted.

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.

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.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#89

Post by gandreani » Thu, Jul 23, 2026, 2:54 PM UTC

giancarlostoro wrote: post #85

Skywalker13 wrote: post #37

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.

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…

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

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#90

Post by giancarlostoro » Thu, Jul 23, 2026, 2:56 PM UTC

gandreani wrote: post #89

giancarlostoro wrote: post #85

Earlier quoted context omitted.

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…

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.