> Very often people regard the stack as a scarce, expensive resource, while the heap is plentiful and very cheap
Wait what, who says that? This has not been true for at least 10 years.
The Heap is great and extremely powerful, but with cache-misses becoming an ever larger issue, the locality of data in the Stack is a massive performance advantage.
One good example for this is Rust. Rust is fast and works almost exclusively via the Stack and copying data between contexts.
The default stack size in most OSes is tiny, and when programming in a low-level language (including Rust) it's important to keep large allocations off of the stack. That's why Rust has Box/Vec and the various APIs in `alloc`, and why the cross-thread primitives take ownership of their values.
You can "transfer" a 1 GiB `Vec` between threads without having to actually copy it, which is not true of stack-allocated values.
The relative scarcity/cost of the stack vs heap only gets more extreme as the machines get bigger. My desktop has 128 GiB of RAM, and `ulimit -s` reports a default thread size of 8 MiB. A typical rack-mounted server is going to have 1 TiB or more of RAM, and almost certainly the same stack size.
Could I make the stack size bigger on my machine? Sure, yes, but what would that get me when the entire world writes software with the assumption that any allocation over a few dozen MiB needs to be on the heap?
Wait what, who says that? This has not been true for at least 10 years.
The Heap is great and extremely powerful, but with cache-misses becoming an ever larger issue, the locality of data in the Stack is a massive performance advantage.
One good example for this is Rust. Rust is fast and works almost exclusively via the Stack and copying data between contexts.