Rust updates

[bearophile]

Walter Bright:

Thank you for your answers Walter, as you guess I am ignorant 
about segmented stacks.

> The trouble with segmented stacks are:
>
> 1. they have a significant runtime penalty

> Also, they do not save RAM, they save address space. RAM is not 
> committed until a stack memory page is actually used.

Regarding performance and memory used they say:
http://golang.org/doc/go_faq.html#goroutines

>The result, which we call goroutines, can be very cheap: unless 
>they spend a lot of time in long-running system calls, they cost 
>little more than the memory for the stack, which is just a few 
>kilobytes. To make the stacks small, Go's run-time uses 
>segmented stacks. A newly minted goroutine is given a few 
>kilobytes, which is almost always enough. When it isn't, the 
>run-time allocates (and frees) extension segments automatically. 
>The overhead averages about three cheap instructions per 
>function call. It is practical to create hundreds of thousands 
>of goroutines in the same address space. If goroutines were just 
>threads, system resources would run out at a much smaller 
>number.<


> Segmented stacks are useful for 32 bit address space. However, 
> they are not useful for 64 bit address spaces.

I think Go is meant to be used mostly on 64 bit servers.
Both the designers of Go and Rust are experienced people, and 
they plan to use their languages on 64 bit systems.


Here they say Go avoid many stack overflows, because stack are 
limited by the available virtual memory:
http://stackoverflow.com/questions/4226964/how-come-go-doesnt-have-stackoverflows


I think LLVM supports segmented stacks, the example given is on 
x86-64:
http://llvm.org/releases/3.0/docs/SegmentedStacks.html

Bye,
bearophile