[duped]

Go does this, as do most runtimes with stackful coroutines. Async Rust (kinda) does this where the async call stack is naturally segmented (although this doesn't get away from stack overflows in some cases because the polling call stack is not growable).

Growable stacks have been around for decades, it's far away from research language territory.

The real benefit is not to handle the worst case/OOM condition that a big enough callstack gives you. It's to make the default stack size much, much smaller for the common case where you don't need it at all (or want to shrink it later). Growable stacks use less memory on average than your typical embedded device because they can start in the dozens of bytes, instead of requiring kilo/mega bytes of stack space (allocated, not just reserved). It's kinda the only way you can make a runtime scale to millions of concurrent call stacks.

[steveklabnik]

Both Go and Rust removed segmented stacks, for the same reasons: they can really kill performance.

Go now copies stacks, and Rust only has segments if you deliberately box up a recursive call.

[duped]

Go stacks are still growable, no?

And hence the "kinda" in async Rust. While boxed futures can be thought of as a segmented stack the literal callstack is not, which can still give you a stack overflow with a bunch of nested poll() calls.

[steveklabnik]

> Go stacks are still growable, no?

Depends on what you specifically mean by "growable": when a goroutine runs out of stack space, a new one that's larger (iirc double sized) is created, the old one is copied into it, and then execution can resume.

I can see the argument both ways.

> which can still give you a stack overflow

For sure.