Imagine you're organizing a warehouse where every item must go on a shelf, never the floor. Traditional systems languages give you a warehouse floor (the heap) and let you scatter boxes anywhere — then charge you for a cleanup crew (garbage collector) or force you to label every box with an expiry date (lifetime annotations). Goose says: no floor. Every box goes on a shelf, the compiler decides which shelf before you open for business, and clearing a shelf is flipping one sign. That constraint — absurd-sounding at first — turns out to buy you speed, safety, and simplicity simultaneously. The core claim is architectural: replace the heap with N compiler-assigned data stacks, where N is determined statically. Each stack is a large virtual-memory reservation with a bump pointer. At most one growable value lives atop each stack at any time, so growth never relocates anything and never checks capacity. Freeing a million-element structure is literally one store instruction to reset the bump pointer. The compiler proves all of this at compile time; the runtime tracks only the bump pointers. The performance numbers are striking but need careful reading. Across sixteen benchmarks, Goose claims 3.3x the speed of idiomatic C++, 1.16x hand-optimized C++, and 1.12x the best safe Rust, on 1.9x, 1.3x, and 1.2x less memory respectively. These are the project's own benchmarks, not a community suite — though the authors note they include losses. The gains trace directly to the memory model: nested data stays inline (a record that's 160 bytes with one allocation in C++ is 29 bytes and zero allocations in Goose), variable-mode ADTs give each enum variant its own size rather than padding to the largest, and references into growing arrays remain valid because nothing ever moves. The type system does real work here without burdening the programmer. Every reference has a static root — the variable that bounds its target's lifetime — inferred by the compiler. No lifetime syntax, no aliasing or exclusivity rules, no unsafe keyword. When a check fails, the error names the reference's root and its destination, which is a better diagnostic story than most Rust lifetime errors. The tradeoff is that the model is more restrictive: you can't build arbitrary graph structures on a heap that doesn't exist. Relative references (1, 2, or 4-byte offsets instead of 8-byte pointers) give you trees and linked structures within arrays, and the resulting data is position-independent — your data structure is already its serialization format. The concurrency model is equally opinionated: threads share nothing. Each worker compiles as a separate program with its own memory, and flat values cross typed queues via memcpy. Data races, locks, atomics, and memory orderings simply don't exist in the language. This is the Erlang approach applied at the systems level — powerful for message-passing workloads, but it remains to be seen how it handles problems that genuinely need shared mutable state. Goose compiles to a single C file, so it runs anywhere a C compiler does, and the bundled TinyCC backend can compile and run a program in-process with no build step. The honest read: this is an impressive research artifact with a genuinely novel memory model that produces real performance results. But it's a single-author language with its own benchmark suite, no independent replication, no large-scale production deployment, and fundamental restrictions (no heap means no arbitrary graphs, sequential-only access for variable-size array elements) that may limit applicability. The 3.3x-over-idiomatic-C++ number is eye-catching but benchmarks against idiomatic code often reflect the benchmark's coding style as much as the language. The 1.16x-over-hand-optimized-C++ is the number that matters, and it's real but modest. What Goose demonstrates convincingly is that the stack-only memory model is not just viable but competitive — and that's a genuine contribution to how we think about systems language design.
