Goose Programming Language: AI Wrote It, I Tried It

The Goose programming language is a new open-source systems language from Wouter van Oortmerssen, the person behind Lobster. It has no heap allocator, no garbage collector and no lifetime annotations, it is memory safe, and it compiles to a single C file. The README says the repo “was produced almost entirely with AI, from a human language design.” The latest release is v2026.3, from October 21, in a repo created August 30.

In this post I go over what Goose claims, what happened when I tried it for an hour, how the author makes an AI-written compiler checkable, and the catches in his own numbers. My verdict: do not put Goose in production, it is too young, but copy the workflow around it. Whether to trust code a model wrote is a question I face at Trellis every week, and this repo is the best worked answer I have seen.

What is the Goose programming language?

The pitch of the Goose programming language is one memory model. Every growable array lives on a “data stack” that the compiler assigns, and when the scope ends the memory is freed with one store. Nothing moves when an array grows, because each stack has a big reserved range of address space. The README calls this safe with “zero annotations”: the compiler works out what each reference is rooted in and rejects the ones that could outlive their owner.

The README lists the price itself under “What it costs you”. Recursive functions cannot keep growable data across a recursive call, arrays of variable-size elements iterate but do not index, and there are no escaping closures or function pointers. Mettons you run a normal web backend: Goose is not for you.

How was the compiler built with AI?

The author designed Goose years ago and ran out of time to build it, because he runs a game startup on Lobster. Once a model he calls Fable came out, he had it clone the structure of his Lobster compiler, then argued with it about every spot the design left open. The README credits “Claude Fable” with compiler implementation, benchmarking, and sample and doc writing. The commits are Wouter’s own, so I will not say how many lines the model typed. I can say src/ holds 61,518 lines of C++, because I ran wc -l on the master tarball.

What happened when I tried Goose for an hour?

First, it failed. I downloaded the v2026.3 Linux archive (11.3 MB), ran goose on a sample, and got include file 'stdint.h' not found. My sandbox had no libc headers at all. The README says Linux needs libc6-dev, so that one was on me.

I pointed GOOSE_CC at the clang that ships inside the Zig Python package (clang 22.1.8). goose toolchain found it, and the sieve sample built into a 278 KB executable. It found 664,579 primes up to 10,000,000 in 121.9 ms. One run, my sandbox CPU, so not a benchmark.

I wrote a function that builds a growable buffer, then returns a slice of it, which is the classic dangling reference:

fn longest_sku() -> u8[:] {
    var s: u8[>..] = [];
    s.append("B0-TEST-SKU");
    return s[0..4];
}

The compiler refused, with a call chain and this line:

error: returning a reference rooted in s, which dies with this function (§9.2)

That is one case, and catching the obvious bug is a low bar.

Last, something shaped like my work. I wrote a small program that parses A1,3;B2,5;C3,7 (SKU and units) into rows, each SKU a slice of the original text, nothing copied. First compile failed on expected a value of type i32, got i64 (narrowing and sign changes require an explicit as). When I over-corrected, I got a warning about a redundant cast. Three tries, then it printed three lines and total 15. The strict integer typing is friction.

I ran no C++ or Rust comparison, wrote nothing bigger than that, and tested only Linux.

How do you trust a compiler an AI wrote?

Three things in the repo carry the trust, and none of them is “the model is good.” First, CI. The workflow file runs the tests on Ubuntu, macOS and Windows, plus a separate Linux job that builds the compiler with AddressSanitizer and UndefinedBehaviorSanitizer and halts on the first error. Second, checksums: every implementation of a benchmark prints the same checksum lines and the harness verifies they agree, so a fast wrong answer does not make the table. Third, the compiler itself, which refuses unsafe references, as I saw.

adoption.md records sixteen compiler changes, each on its own branch, each implemented by its own agent, each measured the same way after. Not all were kept: one is marked “drop for now” and a few are “hold”. A loop that sometimes rejects its own work is one I believe more. Me, I eyeball the diff and run the happy path on my internal tools, even after checking ate half the budget of one of my pipelines, and I’d do better with a number per change and a verdict column.

Are the Goose benchmark numbers real?

They are the author’s numbers. results.md was generated on October 16 on one machine, an AMD Ryzen 9 9950X3D with Windows 11, best of 3 whole-process runs, and I found no independent reproduction. I did not rerun them. Suite figures and some rows, losers included:

Above 1.00 means Goose is faster. Against hand-built expert C++ the average win is 1.24x, and in lru it loses. The big headline number is against the C++ most people write first, with unique_ptr and unordered_map. Real comparison, different claim from “faster than C++.”

Then the drift. The README headline says 3.3x, 1.16x and 1.12x. The results file generated on October 16 says 3.51x, 1.24x and 1.13x. Same project, two sets of numbers. Docs go stale fast when an agent writes both them and the code.

What did the skeptics say about Goose?

The Hacker News discussion is the one place I link for this. One reader wrote “I can’t see a reason to use this and not C++.” Another asked for the README to be rewritten “without AI-isms,” saying the prose “is just awful to read.” A third, weinzierl, asked whether Goose is performance first or safety first, since the README says nothing on undefined behaviour. The author answered that Goose “has no ‘unsafe’ feature, and no undefined behavior, and is fully memory safe.”

That is a claim, not a proof, and I tested one dangling-slice case. The prose complaint is fair: the README does read like a model wrote it. About 1,800 stars and 68 forks as I write this, and a star is a click, not a code review.

Who should try Goose, and who should skip it?

If you write parsers or game code, or read a large file and build a tree out of it, spend an hour with it. If you ship a product on a normal stack, skip it for now: there is no package ecosystem to speak of, the README itself says “Goose is new,” and I found no independent audit. (Not Block’s agent also called goose.)

We do not use Goose at Trellis, and nothing I tried changes that. What I am taking is the shape of the repo: a person’s design, a plan with a number per change, checksums that must agree, and a verdict column that sometimes says no. Next I want to run that on one internal tool and count how many of the model’s changes I reject.