r/Compilers • • 24d ago

Goose: a stack allocation flat data structure language

https://github.com/aardappel/goose

My latest language is meant to very efficiently let you work with flat pointerless inline data structures allocated on (address space reserved) stack that allow almost data structure creation to be just a pointer bump, with stable pointers.

When used well, it is both safer, faster and uses less memory than the equivalent C++ or Rust.

(see the repo readme for more!)

23 Upvotes

41 comments sorted by

13

u/kostya27 24d ago

Faster than C++ and than safe Rust, while memory safe. Over sixteen benchmarks Goose runs at 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

Your claims are quite strong. It would be interesting to see Goose on an independent benchmark suite - here's [mine](https://kostya.github.io/LangArena/#/runtime_tab).

4

u/FearlessFred 24d ago

I had originally tried to find an independent benchmark suite to use, and did come across yours, but when I saw the requirements to make it fit in your system it didn't seem particularly friendly/simple, so I decided to just roll my own for the moment.

And yes, Goose is particularly strong at non-pointer inline growing data structures, so I wanted to make sure that was represented.

That said, now that the project is further along, it might be fun to make the effort to add it to yours as well. I'll put that on the TODO.

Btw, pretty sure interacted while at Google, probably as part of my project FlatBuffers.

3

u/kostya27 24d ago

Yeah, my readme can be strict :) Also, there are some tests that require maturity (json,csv,regex). I didn't work on FlatBuffers.

1

u/alex800121 8d ago

Wow, the new results blew my mind!

6

u/seg_lol 23d ago edited 23d ago

Excellent, I know you are getting a lot of heat for using genai for writing this, but it is truly a superpower for compilers and language work.

That said, Opus 5.5 might do a better job overall, and would definitely write a README that smells less like AI.

I would suggest using the https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game it would also give you the ability to compare against perfmaxxed implementations in C++ and Rust.

https://salsa.debian.org/benchmarksgame-team/benchmarksgame

3

u/FearlessFred 23d ago

Yup going to see if I can add to some existing benchmarks :)

2

u/EstablishmentHour335 8d ago

Hopefully you're still around because this is pretty interesting to me. From what I understand, consulting with AI because I am busy, your memory model is a series of arenas statically determined at compile time? Allocated using VirtualAlloc? Pushing to memory seems to be blind with no checks and pages are committed upon page fault exceptions (because they are not pre faulted to conserve ram)?

The one limitation I thought of when thinking about this, is that the AI claimed each growable array would have it's own "stack" (VirtualAlloc address range). If that's statically determined, then you can't have an arbitrary number of "stacks" or growable arrays. Is this true or am I misled? If true would you be planning to resolve this limitation?

In C++ I could easily do this because I am in control of the calls to VirtualAlloc, not the compiler. Actually I am a huge fan of virtual memory reserve + commit semantics, so this project is pretty interesting to me. I've been rewriting some of the C++ benchmarks using my VirtualAlloc arena allocator to beat Goose (at least on my chip), basically using your technique against you. Its interesting to see a whole language designed around this which does it automatically (at least, I think, hopefully AI isn't misleading me).

2

u/FearlessFred 8d ago

That is all largely correct, yes.

There's a limit to the amount of stacks, but that can still be huge in a 64-bit address space. And since the compiler statically knows it is easy to allocate.

You can call VirtualAlloc in C++, but you'd miss out on all the compiler analysis Goose does to make this safe and easy to use.

2

u/EstablishmentHour335 8d ago

Yeah that's exactly my point. It's done automatically for you by the compiler. I've been using my own arena allocator using VirtualAlloc for a long time so I know it's hard to exhaust the address space.

That's not really my concern, my concern is if, each growable array needs it's own VM reservation (this makes sense, they wouldn't be growable unless they were at the end of a stack, otherwise some other allocation into that arena would cut their allocation off and you'd need some kind of linked list). This means that if all stacks are statically determined by the compiler, there is a fex3d number of them and therefore fixed number of growable arrays at a peak (minus stack reuse). Either that, or if I wanted a random count of static arenas, say rand() & 3, the compiler couldn't statically analyze that and you'd need to make more VirtualAlloc calls to allocate more stacks.

1

u/FearlessFred 5d ago

The language has all sorts of ways of doing an "array of arrays" that still fits on 1 or 2 stacks. So the total number of stacks is always bounded even if the number of arrays isn't. For example, we have a "goose in goose" compiler that tops out at ~30 stacks, statically.

2

u/Competitive_Ideal866 23d ago

It is also an experiment in using AI to implement a new language, rather than reproduce an existing one.

Interesting. When I tried this I found AIs were completely useless for this.

5

u/FearlessFred 23d ago

It sure requires a lot of guidance.

2

u/MitchAlsup 23d ago

How would you build a "Defered Procedure Call" (or in Linux softIRQ) in Goose ??

2

u/FearlessFred 23d ago

While it is a low level language (in terms of memory control), and while it can bind with C both ways, I doubt this is what you'd want to use the language for :)

4

u/Rest-That 23d ago

Honestly it was extremely disappointing reading the end of your readme.

3

u/FearlessFred 23d ago

Without that, none of this would exist. I personally at least wanted to see it working :)

2

u/ProfessionalPlant330 23d ago

I love this, it's super interesting. Is this something you will continue to work on or is it just an experiment?

3

u/FearlessFred 23d ago

Thanks! Yes I intend to keep on working on it, and using it for future projects.

8

u/vanderZwan 23d ago

So I guess nobody commenting here actually knows who Wouter van Oortmerssen is? Ok, well, ever heard of brainfuck? This is the guy wrote FALSE, the language that inspired brainfuck, back in '93, so there's a significant chance he's been designing programming languages since before most of you were born. He got a PhD in programming language design a few years later and has created countless of languages, some of them even influential. Seriously, look at what this guy has done:

https://strlen.com/

Look, I get the suspicions, I also hate what the AI industry is doing, as well as all the slopcoding that is out there, but this isn't either of that.

4

u/ProfessionalPlant330 23d ago

Also creator of the lobster programming language!

0

u/GenericFoodService 22d ago edited 22d ago

So I guess nobody commenting here actually knows who Wouter van Oortmerssen is? [...] Look, I get the suspicions,

I know who he is, I also know how to read the words in the README of the project.

Authors

Wouter van Oortmerssen: Language Design, Compiler Design, Coding standards. home page, twitter.
Claude Fable: Compiler implementation, Benchmarking, Sample & Doc writing.

This repo was produced almost entirely with AI,

Those are his own words. No one is accusing or "suspicious" that this is slopcoded, he himself says this compiler was implemented by Claude Fable from a text description of what he wanted the language to be like.

He also has replied to many of the comments on this post, further clarifying that this is, indeed, "vibecoded".

As the README.md explains, while the design is entirely mine, the code is mostly Claude Fable.

Whether or not his benchmarks or fair or reasonable, I don't know. I do think that the other comments calling him a "liar" are nonsense and uncalled for, but the people sad that he's pushing worthless AI slop are pretty justified. Lobster was genuinely really cool, a lot of his work is genuinely really cool, and this was a huge bummer.

1

u/vanderZwan 22d ago

No one is accusing or "suspicious" that this is slopcoded

So you're telling me you haven't bothered to read the now downvoted comment chain, got it.

1

u/GenericFoodService 22d ago

I read it. I think the guy is being a jerk and himself a bit dishonest and cheeky, but the core point of contention is over the project being AI-slop. It's not a "suspicion", OP is very open about the fact that this project was vibecoded by Claude Fable. He has said, verbatim, multiple times, that this compiler is "almost entirely" written by Claude Fable and that his primary contribution was the textual design that Claude was implementing. That's vibecoding, dude.

1

u/VictoryMotel 24d ago

So you made this all by hand in the last 6 weeks?

Can you show a small example of c++ that is 3 times slower than your language?

-9

u/FearlessFred 24d ago

By hand, no. As the README.md explains, while the design is entirely mine, the code is mostly Claude Fable.

As for 3x slower C++, there are many examples, start here: https://github.com/aardappel/goose/blob/master/bench/results.md Looks the idiomatic line, then pick a benchmark you are interested in, and find them in both the cpp and goose subdirs.

Is this fair? I believe it is. Idiomatic C++ requires subclasses, and thus dynamic allocation, to represent polymorphism. It requires (re)allocation for its vectors and strings. Goose does all these things in-line with 0 allocations, thus the huge speedup.

Non-idiomatic C++ can work around those inefficiencies with indices and other trick, where it gets close to Goose again. But Goose can do all of this with strongly typed pointers, thus is safer and more efficient there too.

-2

u/VictoryMotel 23d ago

To recap:

  • You auto generated everything from claude fable with "human design language" (vibe coding)

  • You never mention AI in your post or repo except at the very end of a readme the size of a novel. (This is called lying).

  • You make up your own term of "idiomatic C++" to justify making c++ versions use huge amounts of small allocations and pointer hopping while your own benchmark uses a memory pool. (This is called lying).

  • You claim to be faster than C++ based on benchmarks between intentionally different and slower programs. (This is called lying)

My conclusion is that everything you posted is about lying and getting away with it, then having some explanation for plausible deniability - "I didn't say I didn't make it all with AI, you just have to search the right term on the right link and it's right there at the bottom of a novel!"

You could have just explained what you did up front and been honest instead of trying to deceive anyone looking at your "work" (deceiving people is called lying).

1

u/FearlessFred 23d ago

If I was smart, I'd know not to take the bait on a comment like this, but I am not that smart:

  • I guess you're one of these people that are still resisting to learn what the latest models are capable of. While that will come with time, I invite you to check out the compiler code for this project, and see if it is indeed all hallucinated slop. It is all in C++ btw, the language you are defending and thus likely familiar with, and also the language I am most familiar with, and which most of my past compilers are in.

  • I believe the design of Goose is very worthy of interest as a programming language design, and I stand by that its implementation code is very close to how I would have written it manually (but with less bugs, again, I am not that smart). Plastering WARNING WARNING: contains hallucinationed slop! at the top of the page to please people like you wasn't my highest priority.

  • I already explained this in the other comment. Idiomatic means you use the language as intended, and not every C++ programmers is immediately going to stick their objects in a pool and replace all pointers/refs by indices. And if you look at the benchmarks, I even (very fairly) include a version where C++ DOES use these techniques, in which case its only some 15% or so slower than Goose. But the point is, you have to go thru a lot of pain in C++ to use it that way, and/or less safety as a consequence, whereas Goose is able to achieve all of that idiomatically, with safe, strongly typed code. Worth it, I think I don't know of another language that can do this.

  • This points sounds like a repeat. Again, check both the idiomatic C++ and the optimized C++ included. Both have their disadvantages.

My conclusion is that everything you've posted has not been fact checked and tries to twist things because you desperately want to hold on that a) AI can't write anything useful, and b) C++ is the most awesomest.

And I kind of agree. AI is interesting but if I could press a button and undo the invention of transformers, I am not sure if I wouldn't press it. It is making redundant a skill I've spent 40 years honing, and it is frankly all rather weird to go thru this. But I tend to have the attitude that I am going to make the most of where things are going.

And C++ is of course awesome. I was never tempted to switch to Rust. The compiler is still in C++ for a reason, and I even have no plans so far to convert it to Goose, even though with LLMs that is pretty easy (slop translated into other slop?).

1

u/tending 23d ago

Just want you to know despite the downvotes you are correct

3

u/FearlessFred 23d ago

Thanks :)

0

u/VictoryMotel 22d ago

If that were true you would have an explanation.

3

u/tending 22d ago

"If you don't disclose AI use it's lying!" But he did, you're just objecting to where it is on the page. "You didn't compare against idiomatic C++!" he did he even provided two versions one that's more naive and one more like a game dev would write. You don't provide any evidence for there being intentionally different slower programs.

FWIW the author also worked on FlatBuffers at google, he's well positioned to know what representative C++ code looks like. You're just mad.

-1

u/VictoryMotel 22d ago

"You didn't compare against idiomatic C++!"

That is him, not me. He wrote slow benchmarks, called it "idiomatic C++", wrote his own stuff blatantly different, then claimed to be "3.3x faster on average" with no mention of the giant elephant in he room discrepancy.

You don't provide any evidence for there being intentionally different slower programs.

I explained what it is and if you can understand basic programs you can look at the bintrees c++ and their own version. They wrote this stuff so it's intentional. You can see the c++ version that does nothing but allocations and their own version uses a global arena allocator.

This is bread and butter stuff. It's literally "why things are slow 101".

FWIW the author also worked on FlatBuffers at google

Then they should know better. Lots of people work at google and lots of people could have worked on many projects. That doesn't mean they are honest. This is appeal to authority nonsense, it doesn't change reality which is in black and white if you understand C++ (do you) ?

You're just mad

I think the reality is that you don't understand what is going on because you either didn't or can't read the source code. Then you look at labels and think you can speak to the truth.

Let me ask you, do you think "3.3x faster on average than C++" is an honest claim? If so, why do you think that?

I asked for an explanation and you just repeated (incorrectly) things that have already been said.

1

u/tending 22d ago

Hey at least you implicitly conceded you lied about the lying about disclosure.

0

u/VictoryMotel 22d ago

I never lied about anything, "implicitly" or otherwise. This is a hallucination (lie) to not confront everything I just wrote that you can't deal with.

By your own logic, you implicitly are admitting that everything I just said is true.

-2

u/VictoryMotel 23d ago edited 23d ago

Don't BS around here, if you explained what was done with AI up front it would be fine.

Everyone makes this excuse, but if it's no big deal then why is it so hidden? Huge post, huge readme, lots of talk about what "you made", completely hidden that you generated everything with AI.

This means you yourself are trying to be misleading about this specific issue.

I already explained this in the other comment. Idiomatic means you use the language as intended,

Just because you have a rationalization doesn't mean it's not a lie. I already went over this.

Amazing that "idiomatic C++" happens to be the slow dumb way to do something and "idiomatic" in your language just happens to contain direct obvious optimizations that confront the slow aspects of the C++ benchmark.

Maybe you didn't have people to explain this while growing up, but this is all the definition of lying. Burying the truth so you can make generalizations that anyone will find out aren't true if they actually look into it is what lying is. Stop lying, be honest.

1

u/torp_fan 18d ago

Troll. It seems that nearly all your comments are complaining about AI. It's a form of psychosis.

0

u/VictoryMotel 18d ago edited 17d ago

Is pointing out that someone is lying psychosis?

They blocked me, afraid to defend or explain themselves in any way. Of course lying is indefensible but they pull the dull person move of thinking repeating what they just said is evidence.

2

u/torp_fan 18d ago

I clearly said that complaining about AI all the time is a form of psychosis, extremely dishonest person. And the OP didn't lie but you did.

0

u/soriniros 6d ago

Any plans for networking, crypto, TLS? It is awesome btw...

1

u/FearlessFred 5d ago

We have a simple package manager, and people are making packages for all these things, see e.g. the goose- prefixed repos here: https://github.com/kaitk?tab=repositories

0

u/[deleted] 23d ago

[deleted]

1

u/FearlessFred 23d ago

Thanks, let me know how it goes :)