Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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 rustby mekky16
- 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.by aaronsung
- The repo calls out the purpose and it's pretty good.by insanitybit
- Nice this is going to be a fun project to watch for 2 weeks before everyone forgets about it!by bradhe
- 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.
- 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?by ksec
- 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.
by Aurornis - 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.
by sisve - But according to Andrew Kelly, Bun was full of bad Zig practices. So why did they keep pushing forward with Zig?by jdw64
- 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.by Juncture0
- Because their ego got hurt that a big project decided to not use their "amazing" language.by romanovcode
- 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.by aureate
- 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 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
by dgellow - Compiling to a single binary for prod is the killer feature imo.by allthetime
- 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?by afavour
- > 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.
by dbalatero - Hard agree, I would never use a totally different piece of software to run prod vs dev or local.by ericyd
- As usual, most forks created out of community rupture eventually die.by pjmlp
- 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.
by TurdF3rguson - 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.
by kreco - Good thing there was no Bun community then.
- Valkey is going strong still. So is Jellyfin, and Gitea/Forgejo.by fishgoesblub
- 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...
by flohofwoe - 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.
by andai - yeah, no place for amateursby m00dy
- The discussion is also missing a key point. Bun had a patched version of Zig, this runtime uses upstream Zig.by rganesan
- > 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.
- 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.
by Skywalker13