--- title: The Goose Programming Language | daily.dev description: Goose is a new memory-safe systems language with no heap allocator, garbage collector, or lifetime annotations. Every dynamic value lives inline on... canonical: https://daily.dev/posts/the-goose-programming-language-tp0n7snqe twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The Goose Programming Language | daily.dev og:description: Goose is a new memory-safe systems language with no heap allocator, garbage collector, or lifetime annotations. Every dynamic value lives inline on... og:url: https://daily.dev/posts/the-goose-programming-language-tp0n7snqe og:image: https://api.daily.dev/og/posts/tP0N7SNQE.png og:image:alt: The Goose Programming Language og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The Goose Programming Language **[Hacker News](https://daily.dev/sources/hn)** · 20 min read · 3 upvotes · 0 comments ## Summary Goose is a new memory-safe systems language with no heap allocator, garbage collector, or lifetime annotations. Every dynamic value lives inline on compiler-managed data stacks, and memory frees when scope ends. Across sixteen benchmarks, Goose runs 3.3x faster than idiomatic C++, 1.16x faster than hand-optimized C++, and 1.12x faster than the best safe Rust, while using 1.9x, 1.3x, and 1.2x less memory respectively. It compiles to a single C file, has no garbage collector or reference counting, and uses relative references as narrow offsets instead of pointers. The compiler itself, about thirty thousand lines of C++, was built almost entirely with AI from Wouter van Oortmerssen's language design. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does Goose achieve memory safety without a garbage collector or lifetime annotations? Goose uses a static memory model of data stacks managed entirely by the compiler, with no heap allocator. Every dynamic value lives inline on a data stack, growth advances a bump pointer, and memory frees when its scope ends. The compiler infers each reference's 'root' variable and rejects references that could outlive their owner, requiring no lifetime syntax, aliasing rules, or unsafe blocks. _daily.dev surfaces language design deep dives like this for engineers evaluating memory-safety tradeoffs._ ### How much faster is Goose than C++ and Rust in benchmarks? Across sixteen benchmarks, Goose runs 3.3x faster than idiomatic C++, 1.16x faster than hand-optimized C++, and 1.12x faster than the best safe Rust implementations, while using 1.9x, 1.3x, and 1.2x less memory respectively. The gains are attributed to Goose's inline data layouts, narrow relative references, and variant-sized enums rather than any single optimization. _track emerging systems languages and their benchmark claims on daily.dev before picking your next stack._ ### Can Goose enums be smaller than Rust enums? Yes, Goose's variable-mode algebraic data types give each value the size of its own variant rather than padding to the largest variant's size. On the benchmark exercising this feature, variable-mode ADTs use 4x less memory and run at 2x the speed of a comparable Rust enum, at the cost of the array becoming sequential rather than indexable. _compare language-level memory tricks like enum layout on daily.dev when weighing Rust alternatives._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 202 comments across hackernews (as of 2026-10-25). **TL;DR:** Technical curiosity dominates, with deep back-and-forth on how Goose's stack-based memory model handles dynamically-sized data like strings and trees, alongside praise for the author's responsiveness and the language's safety/performance claims, tempered by skepticism about benchmark fairness and heavy AI-generated documentation. **Sentiment:** 30% positive · 45% mixed · 25% skeptical **The case for** - The author actively and thoroughly answered detailed technical questions throughout the thread. - Several commenters found the design clever, especially eliding reallocation via large reserved address spaces to get stable pointers. - People appreciated that references replace error-prone manual index/arena patterns used in Rust. - Multiple commenters expressed general excitement and said it looked like a fun, well-executed project worth following. **The pushback** - Commenters questioned whether the stack-based model can really handle arbitrary dynamically-sized collections (e.g., a hash table of variable-length strings) without essentially reimplementing a custom allocator. - Some argued the typed-reference approach is just the index-arena pattern already used in Rust, undercutting claimed benchmark advantages. - Several were skeptical of the 'hand-optimized C++' and Rust benchmark comparisons, noting missing reserve()/with_capacity() optimizations and that the real optimized files aren't public. - Many pushed back on the heavily AI-generated documentation, saying confusing phrasing and inflated/unclear example numbers make it hard to tell what's the author's original design versus AI output. - One reply called out that a linked benchmarking site mostly measures AI code-generation quality rather than true language performance. - A side controversy arose over implying an unrelated public figure endorsed the project based on an ambiguous tweet reference. **By community** - hackernews (mixed): Deep, technically engaged discussion mixing genuine enthusiasm for the memory model and the author's openness with persistent doubts about dynamic-size handling, benchmark rigor, and reliance on AI-written docs. **Hottest debate:** Whether Goose's fixed-stack memory model can genuinely represent arbitrary dynamically-sized data structures without secretly reimplementing a heap allocator. **Open questions** - How exactly does the compiler bound the number of stacks when dynamic arrays can be nested inside other dynamic arrays? - Are the published 'hand-optimized' C++ and Rust benchmarks truly representative, given the real optimized files aren't in the public repo? - Can Goose trigger undefined behavior, and if so would that be considered a bug given it compiles to C? - What concrete use cases or domains is Goose unsuitable for? **Highlights** > I'm curious, for someone more familiar with Goose: how do you represent an arbitrary number of dynamically sized values? If you have a fixed number of stacks, it seems like only a fixed number of values can change size at any given time. For instance, how would you represent a hash table where the values are strings and at random, the program inserts or deletes a random string? This doesn't seem like something you could easily represent. The only way I can think of is to keep a stack that holds all of your strings, and you periodically compact it. Edit: Maybe you could also have a separate stack for strings of various sizes. One each for strings less than 8, 16, ... bytes. But at that point you're basically implementing your own malloc by hand. Edit: Fwiw I do think Goose is very cool! I've had to hand-roll a lot of similar stuff in Rust before to speed up memory management > — [malisper on hackernews · 4 comments](https://news.ycombinator.com/item?id=50225039) > I'm not familiar with Goose, but based on some research and my understanding of how memory works: At compile time, Goose will analyze your program and determine a number of stacks, N, for it. N is the maximum number of "growable" items you can have in existence at any given point in time. Using virtual memory tricks, each stack can grow up to 2GB, but it uses a contiguous address space and only uses as much physical memory as it actually needs. For the program you're describing, I think you would end up with two stacks: one to parse the input and a second to print it. When you parse the input, Goose reads characters from the string one at a time and puts them onto the stack. Once it has hit the end of value, it will update the stack so it now represents the decoded JSON value (strings will just leave the characters in place, numbers will pop off the characters and push the number onto the stack). Goose repeats this until it has parsed the whole JSON, and now the whole JSON is on the stack. Then, when you print the JSON, Goose uses the second stack to build a string. Like the parsing approach, it iterates through each element of the JSON and pushes its string representation onto the stack. Once it's done, it resets the stack pointers to free the memory. This is really nice because allocating memory is just adding to the pointer, and freeing it is subtracting from the pointer. In contrast, Rust automatically inserts malloc() and free() calls throughout your code, which are much more expensive than pointer arithmetic. On top of that, freeing a vector of heap-allocated objects is O(n), whereas if done right in Goose, it would be O(1) > — [malisper on hackernews](https://news.ycombinator.com/item?id=50224786) > I'm sorry if I'm being dense here but I can't see how that would work? The spec on your GitHub says: "Two simultaneously-live resizable values never share a stack." So I surely can't have a dynamic array of dynamic arrays share a single stack? That's an unbounded number of resizeable values sharing a stack? You could make it work on a single stack but that would involve having non-contiguous memory for each inner array since you can add to any array in any order. The spec implies that we need one stack per element of the outer dynamic array which would let you have contiguous memory for each inner array, but you wouldn't know how many stacks you needed at compile time. > — [fancyfredbot on hackernews · 1 comments](https://news.ycombinator.com/item?id=50225460) > Without wanting to be snarky, are the "hand optimized" C++ benchmark files mentioned on the benchmark page available anywhere, as the ones in the "bench/cpp/" directory don't look that optimized to me? e.g. I see a general lack of reserve()s on strings and vectors (a few tests do use them a bit, like `graph` and `particles`), and there are several other things which I wouldn't personally call "optimized", so I assume those ones are the 'idiomatic' ones? Same goes for the Rust code: a lot of the code seems to be using Vec::new() and String::new(), instead of ::with_capacity() which would optimize the memory re-allocation (reducing it as the containers/strings grow). > — [pixelesque on hackernews · 1 comments](https://news.ycombinator.com/item?id=50225785) > As I said in my message, it would determine whether I use the project or not. I need to match it to my use cases, and if I find a match I need to know: is it matching because my use case falls in the domain of what the human collaborator wants from this project, or is my use case a hallucination that will go unsupported? You cannot tell either from the AI written docs. I'd rather OP gave a rambling post about some problem he has in gamedev that led him to think a new language was needed, why the constraints are different, and how this will improve X, Y, or Z in his own words. Then I can infer what this project is and where it is going. Right now, I have no clue. > — [adastra22 on hackernews · 2 comments](https://news.ycombinator.com/item?id=50226351) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50224300) · 148 points · 57 comments - [hackernews](https://news.ycombinator.com/item?id=50224100) · 171 points · 145 comments ## Similar posts on daily.dev - [cloud security, system engineering and compilers](https://daily.dev/posts/cloud-security-system-engineering-and-compilers-sxfl15jgp) · Lobsters · 1 upvotes · 0 comments - [The Lobster Programming Language — Wouter van Oortmerssen](https://daily.dev/posts/the-lobster-programming-language-wouter-van-oortmerssen-vurfrncz4) · Hacker News · 2 upvotes · 0 comments - [Memory-Safe Jule language emerges as C/C\+\+ alternative](https://daily.dev/posts/memory-safe-jule-language-emerges-as-c-c-alternative-fnarsynpz) · The New Stack · 31 upvotes · 12 comments - [Zig creator seeks 'uncompromising perfection' before blessing 1.0](https://daily.dev/posts/zig-creator-seeks-uncompromising-perfection-before-blessing-1-0-xjndfdjvj) · DEVCLASS · 28 upvotes · 13 comments --- Tags: [#performance](https://daily.dev/tags/performance), [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/the-goose-programming-language-tp0n7snqe) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The Goose Programming Language","url":"https://daily.dev/posts/the-goose-programming-language-tp0n7snqe","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-goose-programming-language-tp0n7snqe"},"datePublished":"2026-10-24T21:08:44.655Z","dateModified":"2026-10-25T00:11:03.145Z","description":"Goose is a new memory-safe systems language with no heap allocator, garbage collector, or lifetime annotations. Every dynamic value lives inline on...","image":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","thumbnailUrl":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/the-goose-programming-language-tp0n7snqe","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"performance,rust","timeRequired":"PT20M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"The Goose Programming Language"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/the-goose-programming-language-tp0n7snqe#faq","mainEntity":[{"@type":"Question","name":"How does Goose achieve memory safety without a garbage collector or lifetime annotations?","acceptedAnswer":{"@type":"Answer","text":"Goose uses a static memory model of data stacks managed entirely by the compiler, with no heap allocator. Every dynamic value lives inline on a data stack, growth advances a bump pointer, and memory frees when its scope ends. The compiler infers each reference's 'root' variable and rejects references that could outlive their owner, requiring no lifetime syntax, aliasing rules, or unsafe blocks. daily.dev surfaces language design deep dives like this for engineers evaluating memory-safety tradeoffs."}},{"@type":"Question","name":"How much faster is Goose than C++ and Rust in benchmarks?","acceptedAnswer":{"@type":"Answer","text":"Across sixteen benchmarks, Goose runs 3.3x faster than idiomatic C++, 1.16x faster than hand-optimized C++, and 1.12x faster than the best safe Rust implementations, while using 1.9x, 1.3x, and 1.2x less memory respectively. The gains are attributed to Goose's inline data layouts, narrow relative references, and variant-sized enums rather than any single optimization. track emerging systems languages and their benchmark claims on daily.dev before picking your next stack."}},{"@type":"Question","name":"Can Goose enums be smaller than Rust enums?","acceptedAnswer":{"@type":"Answer","text":"Yes, Goose's variable-mode algebraic data types give each value the size of its own variant rather than padding to the largest variant's size. On the benchmark exercising this feature, variable-mode ADTs use 4x less memory and run at 2x the speed of a comparable Rust enum, at the cost of the array becoming sequential rather than indexable. compare language-level memory tricks like enum layout on daily.dev when weighing Rust alternatives."}}]} ```