Golang allocates a _goroutine_ per socket. Those goroutines are actually scheduled using epoll (https://golang.org/src/runtime/netpoll_epoll.go). Goroutines are _very_ light (8KB stack size) and don't incur nearly the same cost as a thread in a "context" switch. While for some (honestly very small) subset of problems they are still too large most people will never need to worry about them.
I have production systems which run several 100k goroutines at once with very little overhead.
Rust Core team member here. Out of the box, the Rust standard library only provides very basic networking support [1]. If you want to process requests in parallel, then yes you need to spawn an OS thread to process the request. We went with this model because we wanted to have the standard library be portable across all our supported platforms, and there isn't really a great standard for doing portable IO.
Instead, we're layering platform-specific code in external libraries. At the raw C-level bindings, we have libc [2] and winapi [3]. For higher level APIs, we've got Mio [4] which abstracts the system APIs, and now Tokio [5], which uses futures to simplify async operations.
We're just working our way up the stack. All of these are being developed by members of the various Rust teams, so they're as "official" as everything else we're doing.
And it's not right. Rust programs can use epoll directly or through abstractions like mio and tokio.
Thread-per-connection is the simplest way to do concurrent networking in Rust using only libstd, but it's not the way that most Rust programmers would actually use (at least, not for a production server handling a large number of connections).
That's curious, as I've always considered 2 pages (1 unallocated) the absolute lower bound for a thread stack size (1 page of actual, allocated memory for stack, 1 page unallocated as a guard page to detect overflow.)
If a goroutine calls into C, and the C code overflows or otherwise writes ‼Fun‼ onto the stack¹ … can it clobber an adjacent stack of another goroutine or other memory?
I have production systems which run several 100k goroutines at once with very little overhead.