Walter Bright:
Yes, and that's why your analysis of Rust's stack usage is inadequate in demonstrating it is safer.
There I was not talking about Rust, but about more constrained systems (where maybe Rust someday will run, but it will need some changes).
In desktop PCs usually there is plenty of RAM to grow a stack for lot of time, safely. So I think Go and Rust programs have a low risk of stack overflows if you run them on normal PCs.
You can't have an undetected stack overflow if you use guard pages.
They don't care about this much. For those high integrity systems they remove stack overflows from happening, sizing the stack with a careful static analysis, because for those software usages a stack overflow is dangerous :-) Their main problem is not detecting it, it's avoiding it. And for other systems a stack overflow can be a nuisance/problem.
I'll add that segmented stacks are a compiler feature, not a language feature. A D compiler could support segmented stacks without changing the language, provided calling C functions still works.
I see.
But I see no point.
I have never asked for having a segmented stack in D. But both Go and Rust developers are smart people, running code mostly on 64 bit systems, and both have designed their languages in recent years with segmented stacks. So perhaps you could go read their motivations. My guess is that Rust programs can allocate lot of stuff on the stack, and just like a heap a larger input data causes a larger stack to be used. Having an extensible stack probably avoids stack from exhausting too much easily on normal PCs. But parallelism could be another cause (that you already answered).
Bye, bearophile
