9 ms·
Cruller: Bun's Zig Runtime, Continued on Zig 0.16
- holysantamaria 3mo agoWhat 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?
- dgellow 3mo ago> 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
- andai 3mo ago[flagged]
- allthetime 3mo agoCompiling to a single binary for prod is the killer feature imo.
- afavour 3mo agoThe 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?
- holysantamaria 3mo agoSpawning 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?
- afavour 3mo agoThat’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 https://developer.apple.com/documentation/javascriptcore
- tredre3 3mo agoBut 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.
- afavour 3mo ago> 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.
- Copenjin 3mo agoHeroic 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.
- pjmlp 3mo agoAs usual, most forks created out of community rupture eventually die.
- flohofwoe 3mo agoI 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...
- jonkoops 3mo agoSame goes for io.js, which got so popular it actually got merged back into Node.js
- loeg 3mo agoegcs was almost 30 years ago, fwiw.
- flohofwoe 3mo ago...strange, I remember the drama like it was just yesterday ;) But anyway, GCC was already an established and popular compiler at that time.
- TurdF3rguson 3mo agoI 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.
- kreco 3mo agoWhat 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.
- andai 3mo agoThere 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 https://news.ycombinator.com/item?id=49018157
- m00dy 3mo agoyeah, no place for amateurs
- ForHackernews 3mo ago> 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.
- rganesan 3mo agoThe discussion is also missing a key point. Bun had a patched version of Zig, this runtime uses upstream Zig.
- muppetman 3mo ago[flagged]
- kshri24 3mo ago> 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.
- pdpi 3mo agoTigerBeetle is the other canonical example.
- flohofwoe 3mo agoSpare us the concern trolling, Zig will be fine.
- audunw 3mo agoWhy 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.
- youre-wrong3 3mo agoThis is really clutching at straws to justify zigs existence.
- maleldil 3mo ago
- deleted 3mo ago[deleted]
- jdw64 3mo agoBut according to Andrew Kelly, Bun was full of bad Zig practices. So why did they keep pushing forward with Zig?
- romanovcode 3mo agoBecause their ego got hurt that a big project decided to not use their "amazing" language.
- virajk_31 3mo agoNo it's vice versa
- aureate 3mo agoIndeed 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.
- Juncture0 3mo agoIt 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.
- self_awareness 3mo agoOh 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.
- h506001 3mo agoAndrew probably doesn’t control what the entire community does
- vorticity 3mo ago[dead]
- djfobbz 3mo agoDoes it work with WSL1? That’s all I care about.
- Zambyte 3mo agoWhy wouldn't it?
- mekky16 3mo agoi 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
- insanitybit 3mo agoThe repo calls out the purpose and it's pretty good.
- abejfehr 3mo ago> 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?
- insanitybit 3mo ago> 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.
- aaronsung 3mo agoI 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.
- Skywalker13 3mo agoI 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.
- actionfromafar 3mo agoIf 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.
- jeltz 3mo agoI still would want the history easy to reach because when I find weird code I almost always reach directly to git log.
- jeltz 3mo agoYeah, and of they want to only keep history for the subset thet are interested in there is always git filter-branch.
- sevenzero 3mo agoHow 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.
- cpuguy83 3mo agoBug is uncovered. Where was it first introduced? Why was the code changed? What did it do before the bug was introduced?
- tangsoupgallery 3mo ago[flagged]
- theawesomekhan 3mo agoOne 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)..
- sisve 3mo agoYou 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.
- dbalatero 3mo ago> 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.
- ericyd 3mo agoHard agree, I would never use a totally different piece of software to run prod vs dev or local.
- ksec 3mo agoThis 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?
- Aurornis 3mo agoThis 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.
- bradhe 3mo agoNice this is going to be a fun project to watch for 2 weeks before everyone forgets about it!
- nextblock 3mo ago[flagged]
- up2isomorphism 3mo agoThe 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.
- deleted 3mo ago[deleted]