> Avoiding the heap ... will prevent you from working with substantial amounts of data

This isn't really true of Goose, but it's avoiding 'the heap' in the C sense, not in the OS allocated pages of memory sense. One is a programming abstraction provided by the other, but GP is only talking about the programming abstraction. I have never encountered a program that couldn't have memory be explicitly tied to lexical scope, but it can result in less efficient use of it in some cases.

[delayed]

Goose is a weird language. It uses a pile of pre-allocated datastacks, enforces lexical lifetimes for all data, and has first-class syntactic support for capped, growable, and shrinkable arrays. It also spits out a pile of C that gets all the optimization benefits of <insert C compiler of choices>.

Goose in particular excites me because I have done similar design work over the years.

I just want to point out that the author of Goose has plenty of technical cred, having authored flatbuffers and lots of other cool stuff.

[delayed]

[delayed]

It might be worthwhile to balance these positive claims against the language's own stated limitations [1].

Also, I took a closer look at the actual benchmark results [2]. For memory usage, at least, the median and mode would show Goose using slightly more memory than the well optimized C++ and Rust. It looks like the mean is skewed in Goose's favor by a couple of benchmarks where it does extremely well due to its variable-length enums.

[1]: https://aardappel.github.io/goose/docs/tutorial.html#18-limi...

[2]: https://aardappel.github.io/goose/bench/results.html