the stack is just a bump allocator. the unique thing about stack-only languages is lifetime management, not really how they allocate.

A stack only language that called into malloc to service allocations would not be very interesting.

Most stack oriented languages also have a heap.

This is actually what first drew me to zig. Most people talk about error handling, but the explicit allocator handling and making choosing an allocator a deliberate consideration has pushed me to better coding habits in general. I don't think it is possible or practical to completely abandon heap-allocated memory, but explicitly choosing between allocation types and styles that most precisely fit a job has great potential for meeting that spirit.

I don't think we can get rid of heap memory, but I do think we can get rid of a shared heap.

Isn't a shared heap pretty much the difference between multithreading and multiprocessing? Won't it turn every form of thread synchronization into a remote procedure call?

You can definitely avoid heap-allocated memory; early versions of Fortran could not do dynamic memory allocation at all. You basically had to preallocate giant arrays and build your own memory manager. It was sheer hell but it worked.

To me the value of zig's approach is in being able to control the allocations that happen in (library) code. When you call a C function, all kinds of heap allocations may happen between the callee and malloc, even if the return value of the call is in caller-allocated memory. With zig, you can pass a local (arena) allocator instead and avoid uncontrolled global allocations.

Avoiding the heap entirely isn't required and will prevent you from working with substantial amounts of data. The real key is to allocate all the memory you need up front and use that large block for a long duration.

> 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

Embedded programming has taught me that almost anything can be a stack-only language if you want it to be, even C++. :)

If your takeaway from this was "wow malloc has so much overhead" then you may want to notice the part where they benchmark against glibc malloc and glibc is somewhere between 20-150x faster than their implementation. And that's fine, this exposition is basically what you would learn in an undergraduate systems programming course, but production allocators are able to significantly cut down the amount of work needed to grab an allocation, especially for small ones that occur frequently.

> where they benchmark against glibc malloc and glibc is somewhere between 20-150x faster than their implementation

Where are you seeing that?

> the complexity and over-head of the malloc abstraction is precisely what made me very intrigued by "stack-only" languages, such a recently published Goose.

Goose's stacks have quite some complexity themselves. They preallocate a ton of memory. The compiler has to magically match your code to each stack. You are not allowed to have nested growing types (e.g. creating an adjacency list is not so easy). And after all for some usecases you still end up using an allocator (Goose's linked list example ends up building a pool allocator for the linked list nodes!)

In my opinion pools are the best concept for unmanaged code.