Aardappel

Haha, I thing "Bla" was probably one of my least successful designs! So elegant, but too weird? Anyway, glad you remember :)

No, I don't see how that would be. It will map process address space to physical memory just like other programs. Physical memory is already not guaranteed to look anything like your process address space, and that is not a problem (for caches, or anything else).

The runtime is not particularly complex, but making it run with no runtime would still take some doing :)

You'll have to explain what you mean exactly by "dynamically sized moves and struct members".

Haha small world :)

I guess Goose is closer to Rust and C/C++ in design, and removing it does introduce some parsing gotchas.

I guess people also differ by how much they are bothered by it :)

My other language, Lobster, has no semicolons at all :)

The function values are just compile time, not runtime. It has great support for higher order functions and other functional patterns (map/filter etc)

Sure, those cases could bite. I think all my benchmarks (and external benchmarks) are mostly single threaded.

Note that all this supposed copying overhead also has an upside: once the synchronisation has happened, every thread can now run at maximum speed doing single threaded memory allocation with no locking of any kind.

In C++, malloc/new in multithreaded programs needs to essentially go thru a mutex and can make allocation even more expensive than it already is. I am not sure if Rust does the same.

Since in Goose "allocation" is just a pointer bump, we cannot make that multi-threaded, hence the threading model followed from that.

And like a lot in Goose, you have to write your program to fit the language a bit. If you expect to do concurrency on top of a huge graph of constantly changing data that all threads must have immediate access to, it is probably not the language for you. But there are plenty of concurrency models that fit and are blazingly fast.

Thanks! There is certainly a big overlap with Rust in use cases.. I'll leave people to decide which they want to use :)

No, not yet. You can also change that amount if you want, just 2GB is a pretty optimal default.

I am not sure what issues could be caused by the sparsity. Like you say, all that matters is that in physical memory, we are only using what is actually in use.

Thanks! :)