27 points bobbydigitales 1 hour ago 17 comments

MiroslavPokorny 48 minutes ago | parent

What does Goose change about memory management ?

kenferry 29 minutes ago | parent

A lot - title could probably use editing. The language has no heap, only stack memory, so the only deallocation is returning from a call stack frame.

yndoendo 5 minutes ago | parent

How big is the stack? Too often large data will blow the top and destroy adjacent stacks in multi-thread environments. Are memory barrier fences used to check against overflow?

zamalek 5 minutes ago | parent

If I am reading it correctly, the compiler creates N bump allocators per function - where N is (I'm guessing at this point) determined by liveness or similar.

backlands 37 minutes ago | parent

> Goose looks familiar like C or Rust, and is built on one idea: there is no heap

So it looks like it restricts the memory management to 100% scope based. I expect that makes a lot of designs for programs not translate to it as well as they fit in Rust or Java (for example). There are a bunch more constraining design choices they list further down:

> - Nothing ever moves

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

I'll have to look a bit deeper to decide if it's feasible to write many things in this language.

bobbydigitales 20 minutes ago | parent

What kinds of things do you think might not translate well?

tombert 17 minutes ago | parent

Not the OP, but I'm thinking about like closures?

Say you wanted to make a Node.js framework with callbacks that react to an event. The callback might be a closure that captured some of its surrounding variables. At that point, any of the captured variables are not trivially stack-allocated.

You might be able to do something similar to what Rust does with moving though.

skew-aberration 15 minutes ago | parent

You could predefine your event handlers within your context, then call 'enter framework' and pass your event handlers as arguments. this is continuation passing style

skew-aberration 17 minutes ago | parent

You could write everything if you refactor to continuation passing style

dadoum 35 minutes ago | parent

I am researching a similar idea but which allowed moves if the compiler was able to fix the resulting structure, but mine will probably stay a small side project for a long time.

finn888 13 minutes ago | parent

Faster than C++ is always a head-turner. Curious what "magic" enables that with memory safety.

wmf 6 minutes ago | parent

Usually strict aliasing.

tom_ 9 minutes ago | parent

So much Claude text. I'm sure this is great (I did a bunch of stuff with/to aardappel's lobster, years ago, and it was pretty tidy, and quite easy to work with), but: Claude's writing makes my brain melt.

It's a no from me. I'm sorry.

webprofusion 9 minutes ago | parent

I'm always fuzzy on this, so 116% faster or 16% faster? The benchmarks suggest 16%.

levkk 5 minutes ago | parent

116% would be 2x which will break the laws of physics. 16% is possible if you're not allocating heap memory, which I believe is the main selling point here.

tom_ 5 minutes ago | parent

Evergreen: https://randomascii.wordpress.com/2018/02/04/what-we-talk-ab...

(Feels like it should probably say "1.16x as fast" or "1.16x the throughput" - or something like that.)