The Goose Programming Language
https://aardappel.github.io/goose/Only on the Internet is this true, not in real life. I cannot and do not trust any of these things to do a proper job because they have not in any situation succeeded in any job I've given them. And no company I deal with claims otherwise
Apparently, this can actually assist the LLM:
https://silly.business/blog/we-should-revisit-literate-progr...
as discussed here previously:
> Nested data stays inline. A string, an array of strings, a record with variable-size fields and an array of those records are each one contiguous block with no pointer in it. A record that is 160 bytes and an allocation in C++ is 29 bytes and none in Goose.
I’m having trouble parsing that last sentence.
how to perform this copy without atomics?
do the workers run as threads or processes?
also you claim it's faster than rust and c++. but for certain kinds of software it's certainly (and substantially) slower, right?
Looking at the repo it seems like the N stacks generated by the compiler are placed at least 2gb apart in virtual memory, have you run into any cases where that has been overflowed during runtime? The compiler cannot know which of the stacks are going to be used more than others and in a large complex program with many stacks any one of them could fail. I imagine this being an issue depends on target application - if you know you are building a game that you know the exact size of your levels / entity counts beforehand you know this is fine but if you were doing data processing / parsing potentially malicious user input it may be a problem.
I'm also interested how the memory locality works. Here you have the bases of your stacks at a series of very sparse virtual memory intervals which will be mapped by the page table to some physical memory addresses, does having them be so sparse cause any issues?
There are some unique ideas here - lifetimes on references to growable+shrinkable stacks, "balancing" stacks in recursive functions - and I'm glad you were able to use coding agents to actually materialize them.
That is about where our similarities end, though, since I'm doing quite a lot of other stuff in the midst as well (much heavier type stuff, fully incremental, retargetable, reflection, integer range tracking, blah blah blah), and the more goals you have, the complexity blows up exponentially. I do think that the region based memory part alone is worthwhile to have as a language feature, so I applaud your pragmatism. I like your syntax for returning through call stacks, too.
There are other languages that do this, though. Did you look into any of the others? Or ones like Odin which give you the configurable bump allocators and scratch space as well? Mainly I'm curious about your opinions of prior art.
I like the XY language, what do you think? https://nsl.com/k/xy/xy.htm
Hows the compile time? Do you have a number or is it similar to another language?
I'm wondering what kind of architectural corners this forces the programmer into ... have you found any so far?
How are you deciding how many stacks to use?
Do you know if Goose is the first time something like this has been done?
(And why isn't it Amiga E?)
var words: u8[][>..] = [];
for i in 5 { words.push(str("word", i)); }
In C++ that is a vector<string>: one heap allocation for the vector,
one per string, a pointer and a capacity per element, and a walk over
all of them when it goes out of scope.
And these strings in Goose are 6 bytes, while the ones in C++ are apparently 16 to 24 bytes each.
The obvious downside is that resizing any string but the last requires moving everything down the stack.
With objects that never need resizing, you can of course have much simpler memory layouts.
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
For example, you can build up a tree of all variable sized nodes inside a single array.
Where it gets interesting is if you must arbitrarily delete tree nodes, and you can't structure it to do that in stack order. The language has various tools for this, like fixed arrays with capacity, or pools of either single elements or runs of elements.
In Rust parlance this would be the difference between a `Vec<Vec<T>>` (many `Vec`s, each can be resized) and a `Vec<Box<[T]>>` (many `Box`ed slices, each with a dynamic size, but none of them can be resized).
I bet you can exploit dynamically sized values to rebuild resizable values, with the downside however that you'll likely leak their memory until you exit the current scope.
That example implements a linked list of integers. I'm curious how you would do a linked list of strings
Goose has a built-in generic hash table called dictionary<K, V>, provided by its standard library.
https://aardappel.github.io/goose/docs/stdlib.html#dictionar...
> Keys and values are fixed-size
so not quite what I'm looking for
It's not entirely mad to do it this way, and I can see some benefits. For one, you might have multiple of these pools across the program for different data-types, which would make allocating to any one of them a cheaper operation. It is much more reference safe since you are only ever freeing stuff in a certain context and you can still never have dangling pointers. When you look at memory safe languages, they all default to this eventually. Like Rust in the advanced case will have you implementing your own allocator, lot's of games use this thing called ECS which is essentially a kind of allocator. Goose would just have it be more common.
I wonder if the name of the language was inspired by the way geese fly in formation, with trailing birds saving energy by flying inside the aerodynamic shadow of the leaders, and swapping in and out as needed. If so, a very nice metaphor for the memory management model.
I was also impressed by the documentation. As we know AI-generted docs tends to be rather mediocre, but the author has clearly invested time in making in readable such that the relevance and rationale of design decisions provide the context that a curious programmer needs to understand why things are implemented in a particular way.
I really appreciated the detailed samples, ranging from simple algorithmic theorems up to a small game. Again, I don't have the experience to rate the language vs others, but I was struck by readable the code was and how easy it was to follow task flow. Not having to think about classes is always a plus!
Anyway, I usually the the offering of a new language with dispassionate interest, as something to be aware of and but not get too invested in or familiar with until it gains enough popularity to have a good shot at longevity. Goose is the first language in a long time where I looked at it and immediately thought that I'd like to use it for its own sake.
The name is an animal because all my past PL designs are animals (I also made Lobster etc). Goose seemed like a fun name.
Still, for a large number of programs - like data-oriented applications - it’s probably a good fit. It might work ok with entity-component game systems as long as you reuse old memory…
If it is potentially completely unbounded, you need different solutions like a pool, or essentially reconstructing etc.
Seems any compiled language with automatic memory can make use of the techniques to obtain speed ups.
From what little I read in the literature I seem to recall that there were enough programs with quite a bit more memory usage that they decided this approach was a dead end.
Does anyone know anymore details?
Back then though, they couldn't lean on large 64-bit address spaces like Goose can. They implemented all of this with a chain of blocks of memory instead, and tracked most of it at runtime that Goose now does at compile time.
https://github.com/aardappel/goose/blob/master/docs/design/p...
That reminds me of Dart Isolates - https://dart.dev/language/isolates
The relative references and built in binary structure validation also enable direct memory mapping of data structures and immediate use of network data. "Parsing" file and network data is often 100x slower than it needs to be." - John Carmack
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)
Goose can store entire trees (of variable sized things) inside an array.
Apache modules worked like this (still do, presumably). Each request has a stack; allocations bump the stack pointer; when a request is finished, the stack pointer is reset. Incredibly efficient as long as you don't need to keep memory longer than a single request.
Looks like in Goose, each scope acts like an apache "request".
Check the features section (https://aardappel.github.io/goose/#features), which starts off with how memory works.
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).
Something that I'm interested in: How fast is the compilation speed on large programs compared to Zig, C, Go?
My ideal language is safer than Rust (no deadlocks / livelocks, no stack overflow from recursion), is optimized for cache locality, but compiles faster than Zig.
This seems like it's close to 2/3.
ps: Ah well, I could have searched before asking https://strlen.com/programming-languages/
super neat history !
Ported a couple of algorithms from my quite large commercial rust codebase and they were significantly faster in goose. Was wow'd, but the big gain was actually that goose just led the LLM to use more efficient (though admittedly slightly less rust-ideomatic but still safe) data structures, so porting them back kept nearly all of the gain (and in one case, even more).
The obvious 'no shit' comment is 'well your code just wasn't optimized', which is partially true, there was obviously a fair bit left on the table. What I find more interesting is that for darn near zero cost, having an an LLM explore in different languages led to a better outcome than me sitting here running perf and squeezing for cycles.
I'm sure that as I build up a cookbook for my codebase this will be less useful over time, but for now, this is going to be how I approach first order performance optimization.
Nice work, cool tool, plz de-ai the docs :D
Embassy (https://github.com/embassy-rs/embassy) uses this concept of no heap allocation and I find it really solid. Even if you write in C, most of the times you don't use heap. MISRA, the C coding standard for automotives, doesn't allow dynamic allocation!
But sounds great for 64-bit user space, with enough (48-bit, or more) virtual addressing available. Obviously one can hit some snags if for some reason quite large allocations has to be done, but maybe one has to rethink that too.
I'm starting to fall in love with this approach ;)
Where does Goose sit when classified along these dimensions?
Sure, performance is right there on the packaging but no word about UB in the README. I read "Goose has syntax familiar to C and Rust" as DX in the same ballpark, but is it a performance first or safety first language.
If it is the former it occupies the same crowded niche as C++ and its many cousins and will have a hard time.
If it's the latter it will have much more room to prosper. We don't have enough languages in the niche that Rust and Ada fill right now.
It is obviously has a lot of potential to be very fast.
It even does pretty good on DX. There is no borrow checker to fight. Algorithms that need indices in Rust are strongly typed references in Goose. Generally pleasant easy to read and write code.
The biggest thing against DX may be exactly where performance comes from: you need to think a bit on where to store your data :)
> Goose: my latest programming language. Safer, faster and less memory than Rust/C++ for algorithms where tightly packed, flat data structures matter.
> It can represent more kinds of data structures as flat, pointer-free bytes than any language I know.
https://xitter.cf/wvo/status/2107979660558766351
So one way to answer might be: how often do you reach for unsafe when using Rust? If you don't I guess Rust is safer. If you do… it gets trickier.
As for UB, I guess you could try looking through the spec and/or the reference? Like, the code is mostly generated by Claude after WvO wrote a specification. If it were anyone else I'd be worried, but given WvO's cv I actually suspect that means the spec leaves basically no ambiguity.
However, Goose compiles to C. Does that by definition mean UB sneaks in, or is there a "UB free" C subset? I don't write C, so I don't really know.
The complete omission of UB in the README could be one of two things. Either that the topic is not important or that it is considered a given and not worth mentioning.
Either way nice to see more options in this space.
Do you know a bit of an ETA / roadmap for certain features like the dynamically sized moves and struct members?
p.s. love potato and geese so feelin kinda biassed towards being excited about this :D
You'll have to explain what you mean exactly by "dynamically sized moves and struct members".
If the host needs to load several of these .wasm, compiled with goose, then it'll have to run them in separate (browser) instances too (or maybe that's how wasm works by default - not sure).
It just got me thinking - the languge is prepared to translate into javascript workers, because it's really single threaded by nature with communication between threads (or put in the dart languages term "isolates"), which makes them perfect for the browser, now the only question is the memory layout.
This was my first programming language. Good old times!
With the but part being the really interesting one.
I guess there would be some penalty to be paid here for smaller pages, but being mostly contigous might also help some.
That to be said, such language seems to require 64-bit virtual address space in order to function reasonably, right?
Also a .dll written in it might not be the best suited, for example if loaded in the middle of fragmented virtual address space it may need to find itself hard to allocate N contigious data stacks (do they absolutely have to be contiguous, what if they are simply ropes or deques or connected chunks ... obviously if some data structure requires to be contigous that would be a problem, but maybe this can be expressed somehow.... or maybe I'm overthinking here).
Super excited about this!
I’d love to see 1st class lightweight ‘processes’ and typed comms, like CSP. These light processes would be cheap to spawn in the thousands, with synchronous comms. So it’s possible to quickly use arbitrary networks rather than OS thread worker pools with queues. Maybe like:
fn produce(out: chan<i32>) { for i in 1000 { send(out, i); } }
fn consume(inp: chan<i32>) { for i in 1000 { print(recv(inp)); } }
fn main() { let c = chan<i32>();
par {
produce(c);
consume(c);
}
}Does this mean you have to know the name of the function calling you that's supposed to handle the error? What if you're a library and don't know that?
One idea that came up was this: you could define a particuda function name as the "landing pad" for handling particular error kinds. Then you "wrap" calls to the library in a function with this name. Here's a part from a larger worked example:
fn catch_io<F: fn()>() -> IoError {
F();
return IoError{ message: "", ok: true }
}
let err = catch_io() { c(); };
Mind you, this was just discussion, no experience with how well this would work in practice.
Rust does a similar thing. When a function returns a value, a location for it will be put in the callers stack frame. That means it automatically stack-allocates values when feasible. The downside in Rust is you need to know the size of the value at compile time whereas Goose can do it for arbitrarily sized values
Edit: I guess one would still miss Goose’s memory layout, which is (if I understand correctly) where it wins in performance.
In Goose, things grow in-place only, since they have a large amount of address space reserved.
I doubt this can work well in all cases. Sooner or later one needs proper heap.
There might be some decent design ideas there but if you can't be arsed to write them down in your own words but instead make me read AI generated slop I am out.
Mandatory initialization, strong typing, context free grammar, lots of good basics. If you get the C++ header converter to work so you can use most C++ libraries I could see this as a great C++ replacement.
https://www.motherjones.com/politics/2026/10/palmer-luckey-a...
Can't wait find out what terrible crimes against humanity Goose will cause.
I find it hard to invest any time in learning about a project if the surface symbols indicate it being a low effort project.
Yet, the author expects YOU to read all of what they didn't write. So I ain't reading all of that.
If anyone is interested, I'm fairly close to finalizing Slang and I'm considering open-sourcing it in the near future. What originally started as a simple register based lang for an embeddable VM turned into an insanely expressive meta?programming language. Full system Fω, expansive whole program reflection (you can reflect on absolutely anything), string memory & logic safety..
You can do stuff like this:
(fn answer () -> i64 0)
(defpass build-answer
(phase source)
(transform (lambda (f)
(fn-with f 'body '(let ((a (arr (42)))) (at a 0)))))
(safety (lambda (goal) (syntax (refl)))))
(run-pass build-answer answer)
(fnmut answer
(transform (lambda (f)
(if (memory-safe? (check-memory (current-program)))
f (syntax-error 'unproved-memory)))))
(defpass inspect-ssa
(phase ssa)
(transform (lambda (f)
(if (memory-safe? (check-memory (ssa-current-program)))
f (syntax-error 'unproved-ssa-memory))))
(proof (lambda (goal) (syntax (refl)))))
(run-pass inspect-ssa answer)
(answer)
(fn next ((i i64)) -> i64 (+ i 1))
(fncontract next
(ensures result (successor (Eq i64 result (+ (old i) 1)) auto)))
(fn read-second ((i i64)) -> i64
(let ((a (arr (0 42)))) (at a i)))
(fncontract read-second (requires (one (Eq i64 i 1))))
(let ((i (next 0)))
(with-proof ((one (Eq i64 i 1) (result-proof i successor)))
(print (read-second i))))
(var answer 0)
(asm (input rdi 20)
(input rsi 22)
(output rax answer)
(mov rdi rax)
(add rsi rax))
(print answer)
(macroop \ (a) (asm (mov a rax)))
(\ 42)
(print (llvm add 20 22))
(print (->i64 (llvm fused-multiply-add (f64) 6.0 7.0 0.0)))
(llvm fn sum32 ((x i32) (y i32)) -> i32
(block entry
(value answer (llvm add x y (declare (flags nsw))))
(llvm return answer)))
(print (->i64 (sum32 (the i32 20) (the i32 22))))
So now your safety and performance issues are in the LLM and whatever prose you feed it for it to generate slang. Have you gained anything?
(Not meant to detract from the language. It's just that this particular goal seems... strange).
Edit Man, two posting about Goose back to back. Carmack alone might be enough to read further.
Why Goose - https://aardappel.github.io/goose/#why-goose
And doc is the slop.
I could follow the link and read the thread and I don't have an X account.
You can also check out the language's website by googling "goose programming language", which should lead you to: https://aardappel.github.io/goose/index.html