Hacker News Reader

Comment by packetlost | Hacker News Reader

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

This isn't really true of Goose, 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.

Goose is almost, but not exactly the "allocate all your stuff at the beginning" the programming language. It's honestly the most exciting language I've seen in quite some time.

View on HN

> 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.

> Goose is honestly the most exciting language I've seen in quite some time.

I took a look at its home page [1] and I immediately see red flags:

- 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, and uses 1.9x, 1.3x and 1.2x less memory (results). These gains come from Goose's data layouts and memory model.

- push returns a reference to the new element, so a program can link elements while building the array. A vector<T> or Vec<T> may reallocate and cannot provide this guarantee. Stable references account for several benchmark gains.

You're suggesting a performance loss (as expected), but they're claiming a (rather incredible) performance gain?

And they're claiming their vector stable and doesn't reallocate, yet without a performance loss, which makes no sense... it's not a vector anymore. And if you want a non-vector then you can do that in C++ too.

The whole LLM vibe doesn't help inspire confidence either, but even ignoring that, the technical claims themselves are incredible and bizarre, and I'm only a few paragraphs in.

[1] https://aardappel.github.io/goose/

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.

That's great, but it doesn't explain anything I'm seeing. I'm just commenting on the (presentation of) the project. It's entirely possible they have something awesome that just isn't presented well, or that I'm just too dense to grasp the awesomeness of what's before me. Whatever it is, I'm just saying I can't make sense of what I'm being sold.

> You're suggesting a performance loss (as expected), but they're claiming a (rather incredible) performance gain?

I think part of the reason they’re getting higher performance is that they accept higher memory usage. Memory can be ‘freed’ later than in traditional languages, and the combined size of all stacks will be larger (maybe even much larger) than maximum memory usage.

The language likely also has limitations in that some constructs are hard or impossible to express (similar to how Rust has memory safety safer, but pays for it by having problems implemented doubly-linked lists)

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 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

Reply on news.ycombinator.com