Goose Programming Language Explained: Memory Safety Without GC or Lifetimes

Goose is a new systems programming language from Wouter van Oortmerssen, the creator of Lobster and the Cube/Sauerbraten game engines, that claims memory safety without a garbage collector, a heap, or lifetime annotations. Instead of allocating objects on a heap, Goose keeps every dynamic value inline on one of a handful of compiler-managed data stacks, and the compiler proves at compile time that no reference can outlive the memory it points to. Van Oortmerssen announced it on X on October 7, 2026, and the project immediately climbed the front page of Hacker News twice.

I spent a few days reading the spec, the wiki, and the HN threads so you don't have to. Short version: the memory model is genuinely clever, the benchmark numbers are real but narrow, and the "faster than Rust" headline needs an asterisk the size of a billboard.

What is the Goose programming language?

Goose is a compiled systems language, syntactically close to C and Rust, that gets memory safety from static analysis of stack-allocated data instead of a garbage collector, reference counting, or Rust-style borrow checking with lifetimes. There's no unsafe keyword because there's no escape hatch to need one: every reference is checked at compile time against the scope it was "rooted" in, and the compiler rejects any reference that could escape its owner's lifetime.

The compiler itself is about 30,000 lines of C++ that transpiles Goose to C, which then gets linked against the existing C ecosystem. That's how it gets SDL3 for graphics and Box2D for physics in its standard library without reinventing either.

Here's the detail that got people's attention on Hacker News: the repo's commit history and the README both say the implementation was built almost entirely by Claude, from a human-authored language design. Van Oortmerssen designed Goose years ago, got sidetracked running a game studio on his earlier language Lobster, and only shipped Goose once an AI agent could do most of the implementation legwork. That's an unusual way to launch a programming language, and it shows up later in this post as the single biggest point of friction in the reception.

How does Goose handle memory without a GC, heap, or lifetimes?

Goose replaces the heap with "N data stacks," where N is a number the compiler works out per program. A program effectively has the native call stack, static data, and some fixed set of these data stacks. Growing a value is a pointer bump. Freeing a scope's memory is a single store back to where the stack pointer was before the scope started, even if that scope held a deeply nested structure with records and arrays inside it.

Three things make this work instead of just being a stack-allocator party trick:

• Values never move. Because nothing reallocates and nothing gets relocated by a collector, a reference taken into the middle of a growing array stays valid no matter how many more pushes happen after it. That's the opposite of a Vec in Rust or C++, where growth can invalidate every pointer you were holding.
• References are rooted, not lifetimed. The compiler infers which variable bounds a reference's target and specializes functions per root. You never write a lifetime annotation because the compiler derives the equivalent of one for you, silently, at every call site.
• Grow-only arrays (T[>..]) formalize the guarantee. Because they only ever grow in the current scope and never move, they're the one data structure in the language explicitly designed to be referenced into safely while you're still building it.

The tradeoff: Goose deliberately does not support moving a resizable value out of its original stack, and a struct can't have more than one resizable field. Those are real restrictions, not minor footnotes. If your data doesn't fit the "flat, tightly packed, grows-and-then-gets-dropped" shape Goose is built for, this model doesn't help you.

Is Goose actually faster than Rust?

On van Oortmerssen's own benchmark suite of 16 programs, Goose comes out ahead of the best safe Rust implementations by about 1.12x-1.19x in speed and uses roughly 1.2x-1.25x less memory, depending on compiler (MSVC vs clang). Against idiomatic C++ the gap is much bigger (Goose runs 3.3x-3.5x faster), and even against hand-optimized C++ it's still ahead by 1.16x-1.26x.

Where does that come from? Mostly from avoiding allocation entirely and packing data contiguously. The canonical example from the docs: an order record with a customer name and a list of items takes 29 bytes and zero allocations in Goose, versus roughly 160 bytes and at least one heap allocation in C++, and about 153 bytes in Rust. No malloc call, no pointer chasing, no cache miss walking a linked structure. That's where the speed comes from, not some exotic optimizer trick.

But (and this is the asterisk) commenters on the Hacker News thread pushed back hard on generalizing "1.12x faster than Rust" into "Goose is faster than Rust." The benchmark set is small and clearly weighted toward Goose's sweet spot: flat, bounded, read-and-discard data structures. Message-passing between Goose's isolated worker threads uses literal memcpy, and someone pointed out that's expensive once messages get large, a case where Rust's shared-memory-plus-atomics model would win outright. Van Oortmerssen didn't dispute this; he's on record saying for some kinds of software, Goose is "certainly and substantially" slower. So the honest claim is narrower than the headline: Goose wins on the kind of tight, allocation-heavy, short-lived data structures that show up in game engines and parsers, which happens to be exactly the kind of code its creator has spent two decades writing.

What did Hacker News actually think of Goose?

Reception split into two camps that talked past each other for a while:

• Technical skeptics questioned the stack model's limits. The sharpest question: if you nest one dynamically-sized array inside another, do you need an unbounded number of stacks? Van Oortmerssen's answer was that inner arrays have to be fixed-size, capacity-bounded, or pulled from a pool, which is a real constraint, not a solved problem, and pushes design decisions onto the programmer that Rust's allocator would otherwise handle for you.
• A separate, louder argument was about the AI-written documentation. Several commenters asked van Oortmerssen to rewrite the docs in his own words, arguing that AI-generated explanations state the "what" but lose the "why": the design rationale that only the human who made the tradeoff can actually explain. Defenders countered that ideas should be judged independent of who typed the explanation, and that the docs were perfectly readable either way.
• Nobody doubted the creator's credentials. Even the harshest critics conceded that van Oortmerssen (Lobster, Cube/Sauerbraten, Amiga E, TreeSheets, prior work on WebAssembly and FlatBuffers at Google) is one of a short list of people whose "I made a new language" claim is worth taking seriously on its face.

That last point matters more than it sounds. A random GitHub repo claiming to beat Rust gets ignored. This one got a two-day front-page HN argument because the person behind it has actually shipped compilers and runtimes that real software depends on.

Should you use Goose today?

No, not for anything real, and van Oortmerssen isn't claiming otherwise: the project's own status note just says "Goose is new." What exists right now: a working compiler that emits C, a language spec, a standard library with 14 modules (including SDL3-backed graphics and Box2D physics), 31 sample programs, and CI running on Windows, macOS, and Linux. That's a serious amount of infrastructure for a few weeks old project, which again traces back to the AI-assisted build process, but it's still a brand-new toolchain with one real-world user.

If you write the kind of code Goose is built for (game engines, parsers, simulation code with lots of short-lived, tightly packed records), it's worth watching. If you're choosing a language for a production service today, Rust's ecosystem, tooling, and multi-year track record still win by default. The interesting question isn't whether Goose beats Rust on 16 benchmarks. It's whether "memory safety via rooted references on bump-pointer stacks" turns out to be a genuinely new point in language design space, or a clever trick that only works for the specific class of problems its creator has been solving for twenty years. Six months of real-world code will answer that better than any benchmark suite can.

FAQ

What is the Goose programming language?

Goose is a compiled systems language by Wouter van Oortmerssen (creator of Lobster and Cube/Sauerbraten) that achieves memory safety at compile time without a garbage collector, heap allocator, or Rust-style lifetime annotations. It compiles to C and was announced on October 7, 2026.

How does Goose achieve memory safety without a garbage collector?

Goose allocates every dynamic value on one of a small, compiler-determined set of bump-pointer data stacks instead of a heap. The compiler statically infers which variable "roots" each reference and rejects any reference that could outlive its owner, so there's no runtime check, GC pause, or unsafe keyword needed.

Is Goose really faster than Rust?

On van Oortmerssen's 16-benchmark suite, Goose beats the best safe Rust implementations by about 1.12x-1.19x in speed and uses 20-25% less memory. That edge is real but narrow: it comes from avoiding heap allocation on flat, tightly packed data structures, and the creator himself admits Goose is substantially slower for other workloads, like large message-passing between threads.

Was the Goose compiler written by AI?

Yes, largely. Van Oortmerssen designed the language's rules and syntax by hand years ago, then had Claude implement most of the roughly 30,000-line C++ compiler. This became the biggest point of contention in the Hacker News discussion, with critics asking for human-written documentation to go with the human-designed language.

Can I use Goose for production software today?

Not yet. The project's own status notes describe it as "new": it has a working compiler, a standard library, and sample programs, but no significant real-world deployment, limited tooling, and a memory model with real restrictions (no moving resizable values, only one resizable field per struct).

How is Goose different from Rust's borrow checker?

Rust's borrow checker enforces lifetimes you write into the code with lifetime annotations and aliasing/exclusivity rules. Goose has no lifetime syntax at all: the compiler infers an equivalent rule automatically by tracking which scope "roots" each reference, at the cost of restricting what kinds of data structures (like nested dynamic arrays) you can build in the first place.

Who created the Goose programming language?

Wouter van Oortmerssen, known for the Lobster programming language, the Cube and Sauerbraten game engines, TreeSheets, and prior work on WebAssembly and FlatBuffers at Google. He designed Goose years before its 2026 release but didn't finish implementing it until AI tooling let him build the compiler faster.

Watch and read more

If you're tracking how AI tools are changing what one person can ship, check out TSRS, the Rust compiler rewritten with AI assistance or our rundown of Claude Opus 5's launch for more on where the AI-assisted-engineering trend is heading next.