Cruller: Bun's Zig Runtime, Continued on Zig 0.16
A new project called Cruller revives Bun’s abandoned Zig-based JavaScript runtime, aiming to turn a stripped‑down subset into an embeddable, production‑oriented engine for the Zig ecosystem rather than a full Bun replacement. Commenters debate whether this approach makes sense compared to simply using Node or JavaScriptCore directly, and question the risks of having different runtimes for development and production. The fork also prompts broader arguments over code quality in the original Bun Zig codebase, the ethics of pruning git history, and the long‑term viability of community forks after Bun’s move to a Rust rewrite under Anthropic.
Project scope and goals
- Cruller is described as extracting and updating the old Zig-based Bun runtime to Zig 0.16, focusing on a minimal JS runtime for deployment.
- It deliberately omits Bun features like package management, bundling, TypeScript transformation, and test runner.
- Goal: serve as a lightweight, embeddable JavaScript runtime for the Zig ecosystem rather than a full Bun replacement.
Relationship to Bun, Node, JavaScriptCore, Rust, Zig
- Cruller is not positioned as a competitor to current Bun (now in Rust), but as a supplement for production execution of code developed with Bun.
- It repurposes a subset of the Zig-era Bun code instead of following Bun’s Rust rewrite.
- Some question why not just use Node or directly embed JavaScriptCore, arguing the “middle man” adds maintenance risk.
- Proponents see value in a Zig wrapper and note compiling to a single binary as a major deployment benefit.
Fork viability and ecosystem politics
- Mixed views on forking: some predict it will fade quickly; others cite historical successful forks (compilers, databases, media projects, hosting tools).
- There is debate over whether this is “really” a fork; several insist that heavily reusing existing code makes it one, regardless of messaging.
- Some commenters tie Bun’s language switch to tensions around Zig’s stance on LLM-generated contributions, but specific motives are contested and not evidenced in the thread.
Git history and licensing
- Strong criticism of the fork’s squashed, orphan commit that discards upstream git history and authorship.
- Concerns include:
- Harder debugging (loss of
git blame/bisect context). - Weaker traceability for licensing/copyright.
- Harder debugging (loss of
- A minority say they rarely use history; many others argue it’s essential in larger/older codebases.
Development vs production runtime divergence
- Cruller’s model—develop on full Bun, deploy on a stripped-down runtime—raises worry.
- Several commenters would avoid using different runtimes for dev vs prod due to risk of subtle, production-only behavior differences.
LLM involvement
- One participant claims the project’s README, comments, and some commits appear LLM-generated; this is noted but not substantiated or resolved in the thread.