Zig Declines to Collect Bun's Garbage

Level 1: The Raccoon’s Bin

Imagine a bakery replaces all its old hand-labeled storage boxes with new boxes that lock automatically so ingredients cannot spill. The old box maker says the real problem was that the bakers kept throwing things around, while the bakers say the new locks prevent costly mistakes. Then a raccoon jumps into the old-box pile and yells, “Don’t use my garbage!” It is funny because a sensible tool change has become a loud breakup in which everyone argues over who owns the mess.

Level 2: Zig, Rust, Bun

Bun is a toolchain for JavaScript and TypeScript. It includes a runtime, package manager, bundler, transpiler, and test runner. Much of its original native implementation used Zig, a systems programming language designed for explicit control, predictable behavior, and straightforward interoperability with C.

Rust is also a systems language, but it emphasizes compile-time ownership and borrowing rules. A simplified comparison is:

Concern	Zig tendency	Rust tendency
Cleanup	Explicit defer and allocator conventions	Automatic Drop tied to ownership
Aliasing	Programmer-managed pointer contracts	Borrow rules checked by the compiler
C interop	Direct and deliberately convenient	Possible, but placed behind unsafe boundaries
Hidden behavior	Minimized by language design	Some automatic behavior through traits and destruction
Memory safety	Checks plus explicit engineering discipline	Strong guarantees in safe code; manual proof in unsafe code

A use-after-free happens when code accesses memory after it has been released. A double-free releases the same allocation twice. A memory leak forgets to release something no longer needed. A garbage collector automatically finds unreachable managed objects, but it does not automatically understand every native pointer or operating-system resource attached to them.

Rewriting means implementing the same public behavior in a different language. It can improve safety and maintainability, but it is risky because years of edge cases are encoded in code that may lack documentation. Passing old tests is necessary evidence that behavior survived; it is not proof that every undocumented behavior, race, platform quirk, or security property survived. The safest migration story is therefore not “Rust good” or “Zig bad,” but “state the failure classes, identify which guarantees move into the compiler, and measure what remains.”

Level 3: Trash-Talk Ownership

The visible header says:

andrew kelly's thoughts on the Bun Rust Rewrite

It misspells Andrew Kelley, creator of Zig, then shows a raccoon guarding a trash bin containing a bag stamped with the Zig logo:

DON'T USE MY GARBAGE

The composition turns a technical and organizational breakup into territorial dumpster politics. “Garbage” simultaneously means the literal rubbish, alleged low-quality code, and the garbage collection involved in Bun’s JavaScript runtime. The raccoon is cast as both offended language designer and possessive custodian: Bun is leaving Zig, yet meme-Kelley objects as though somebody touched his favorite bag.

The actual July 2026 exchange was less simple and considerably more combustible. Bun’s announcement credited Zig with making the project possible, said the project’s unusual mixture of garbage-collected JavaScript values and manually managed native resources had produced recurring lifetime bugs, and presented Rust’s ownership and Drop mechanisms as stronger, earlier enforcement. The rewrite used a pre-release Claude model, roughly fifty automated workflows over eleven days, separate implementer and reviewer contexts, compiler errors as work queues, and Bun’s existing language-independent tests.

Kelley’s response did not argue that Bun must remain in Zig. He said the Zig organization was relieved to lose Bun as the language’s presumed showcase. His central technical claim was that Bun’s accumulated hacks, rushed feature work, and insufficient investment in eliminating debt mattered more than the language choice. He challenged whether the same test suite described as inadequate evidence for the Zig implementation could justify a massive mechanically generated Rust port, and disputed attributing every size or performance gain to Rust when other engineering work and linker settings changed too.

Both positions can be partly true:

• Rust can prevent important memory-lifetime mistakes that explicit manual conventions permit.
• Engineering practices still determine quality inside unsafe code, around FFI boundaries, and for every bug unrelated to ownership.
• A rewrite can create room for cleanup, while making it difficult to distinguish language benefits from cleanup performed during the rewrite.
• A mechanical port preserves behavior, which also means it can preserve architectural debt and old semantic defects.

The meme deletes those distinctions because language wars reward a cleaner narrative: Zig was unsafe, Rust saved Bun; or Bun wrote garbage, Zig was framed, and Rust inherited the bin. In reality, a programming language is neither an absolution nor a confession. It changes which errors are easy to express, which ones are rejected, and where the remaining proof burden lives.

The AI-assisted scale adds another fault line. Producing code at extraordinary speed is valuable for a mechanical migration, but lines per minute is a throughput metric, not a correctness metric. Asking separate instances of the same model to implement and adversarially review can expose mistakes because the prompts and contexts create different objectives. It does not create fully independent evidence: models may share training-induced blind spots, misunderstand the same undocumented invariant, or agree on a plausible but wrong translation. Compilation, tests, fuzzing, sanitizers, benchmarks, and expert review remain the parts that connect generated text to reality.

This was also an open-source identity dispute. Bun had become a highly visible Zig user, so its bugs affected perceptions of Zig even though Zig’s maintainers did not control Bun’s code. Bun had financially supported the Zig Software Foundation, then was acquired by Anthropic; technical direction, incentives, community norms, and reputation became entangled. Kelley’s response mixed technical objections with a candidly emotional account of that failed relationship. He later acknowledged that resentment shaped the post and apologized to Zig users who feared that leaving the language might make them a target. The raccoon image preserves only the funniest residue: after years of unwanted association, the public separation still looked like somebody shouting over custody of the trash.

Level 4: Three Memory Regimes

The trash joke hides a genuinely difficult runtime problem: Bun sits where three different ideas of object lifetime meet.

1. JavaScript values live in JavaScriptCore’s garbage-collected heap. A tracing collector keeps values reachable from known roots and eventually reclaims unreachable ones.
2. Native Zig or Rust values often use deterministic ownership: code decides exactly when buffers, sockets, file descriptors, and other resources are released.
3. C and C++ libraries behind an FFI boundary bring raw pointers, callbacks, and contracts that neither Zig nor Rust can infer from source types alone.

The dangerous cases cross those regimes. Native code may retain a pointer to a garbage-collected value without registering an appropriate root. A JavaScript callback may run re-entrantly and resize an array, rehash a table, close a handle, or detach a buffer while native code still assumes the old state exists. An asynchronous C API may keep a pointer after the Rust or Zig scope that created it has ended. Cleanup must occur exactly once—not before the last use, not after a second cleanup, and not “whenever the vibes are right.”

Zig makes allocation and cleanup explicit. defer schedules an expression for scope exit, while errdefer does so on an error path. This supports precise control and visible control flow, but ownership relationships are largely expressed through API design, documentation, conventions, and programmer discipline. If a pointer escapes through several functions or a callback, the compiler generally does not prove the complete lifetime story.

Rust moves more of that story into its type system. Its ownership discipline is related to affine types: a non-copyable value can be moved, but it cannot be silently duplicated and consumed twice. Borrows must obey aliasing and lifetime rules, and Drop performs deterministic cleanup when an owner leaves scope. In safe Rust, many use-after-free and double-free patterns become compiler errors rather than bugs waiting for a rare production interleaving.

That does not mean “Rust collected the garbage.” Rust normally has no tracing garbage collector. Drop follows lexical and ownership structure; a JavaScript collector follows reachability in a managed heap. Nor does a Rust rewrite make Bun entirely safe by syntax alone. Calling JavaScriptCore and C/C++ APIs requires unsafe contracts the borrow checker cannot verify. Raw pointers, callback lifetimes, shared native state, and GC handles still need human-designed invariants. Safe Rust can also leak memory, and no ownership system prevents an incorrect algorithm or a faithfully ported logic bug.

This is why tests and static guarantees answer different questions. The borrow checker rules out a class of invalid programs under safe-code assumptions. Tests sample behavior for selected inputs and environments. Sanitizers instrument executions to detect bad memory access. Fuzzers search unusual input sequences. FFI review checks the unprovable contracts at language boundaries. A runtime this complex needs the layers together; replacing one with “the test suite is huge” is how the trash acquires a production pager.