The Goose Programming Language
A new systems programming language called Goose is drawing attention for its unconventional memory model: instead of a heap, it uses a small number of large “data stacks” and flat, pointer-free data layouts to achieve performance claims surpassing idiomatic C++ and safe Rust while remaining memory-safe. Commenters probe how well this approach handles real-world needs like hash tables, JSON parsing, concurrent work, embedded targets, and WebAssembly, and note that it favors workloads where data can be organized into regions with similar lifetimes. Many are intrigued by the design and early benchmarks but express unease that both the compiler and extensive documentation were heavily AI-assisted, raising questions about long-term maintainability, clarity of intent, and trust in the written materials.
Memory model and data structures
- Central idea: all long-lived, growable data lives in a small, statically determined set of “data stacks” (regions/arenas). Scope exit frees whole regions in O(1).
- Nested, variable-size data (trees, JSON, records, arrays of strings) can be stored contiguously without internal pointers; this enables direct memory mapping and very cheap (de)serialization.
- For cases that don’t grow/shrink nicely in stack order, the language supports fixed-capacity arrays, “cap” arrays, and pools/free-lists; more complex patterns can emulate custom allocators on top of a stack.
- There is confusion and debate about how dynamic arrays of dynamic arrays and arbitrarily many resizable values are handled; the design relies heavily on compile-time liveness analysis and on representing many “dynamic-sized but non-resizable” values instead of many resizable ones. Some details remain unclear to readers.
- The model assumes large 64‑bit virtual address spaces and lazy page commitment. Several commenters question how well this works on 32‑bit, constrained embedded, or some mobile configurations.
Performance, safety, and comparisons
- Goose claims to be faster than idiomatic C++ and safe Rust on many benchmarks by avoiding realloc, representing more data inline, and freeing whole regions at once.
- It compiles to C; “production” builds go through an optimizing C compiler, while a libtcc JIT is used for fast dev iterations.
- The author asserts: no “unsafe” escape hatch, no undefined behavior, memory safety by construction, and precise escape analysis of references.
- Skeptics argue that copying messages between isolated workers, and lack of user-visible atomics, will lose to hand-tuned Rust/C++ in some workloads (very large messages, specialized concurrent algorithms).
Concurrency model
- Threads (“workers”) have disjoint memories and communicate via typed queues with memcpy of flat values.
- No shared mutable state in the language; data races, locks, and atomics are pushed into the runtime, not user code.
- Some compare this to Dart isolates or Linda-like coordination; others wish for cheap CSP-style processes with typed channels.
Use cases and limitations
- Seen as a strong fit for data-oriented code, games, entity-component systems, parsers/serializers, and tightly packed trees.
- Probably a poor fit for kernels, environments requiring allocation randomization, or MCU/embedded targets without ample 64‑bit virtual space.
- Shared concurrent data structures across threads are not supported; you redesign around message passing.
AI-generated documentation and reception
- A major thread is about the AI-authored README and docs: some find them clear enough; many dislike the style, don’t trust correctness, and want human-written motivation, tradeoffs, and future direction.
- There are calls to add a concise TL;DR, explicit pros/cons on the front page, and less “marketing-like” phrasing.
- Despite doc complaints, several people experiment with the language and report good performance and memory usage on small ports from Rust.