This is confusing. By far the most words of any concern in this piece are dedicated to a root concern that Rust doesn't have a select/poll abstraction, and that idiomatic network code simply allocates a task per socket. But that's true of Golang as well; not just true but distinctively true, one of the first things you notice writing Go programs.
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?
While this confused me a bit too, there's definitely an epoll implementation in the golang syscall package which I'm guessing ESR was planning on using instead of net? Rust doesn't have such a thing in their std lib, although tokio seems perfect for this
Edit: Does "But that's true of Golang as well" refer to the one thread/socket model or not having epoll? I may have misinterpreted what you were saying...
It would be extremely janky to write a Golang network server coded directly to select/poll. You would lose most of the networking libraries for the transactions based directly on it.
(I know it's doable; I did it for a portscanner, where I needed fine grained timer control. But I had to forego the Go networking stack to do it.)
Au contraire: Go has a built-in 'select' keyword that lets you wait on a set of arbitrary (blocking) channel operations. Start up blocking I/O in goroutines, and select on channels that give you the results.
