A proper language comparison...

[bearophile]

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