It's true goroutines waiting on the network are going to sit on a few KB (small stack, buffer, user-mode sched bookkeeping), and if you multiply that out by a m

It's true goroutines waiting on the network are going to sit on a few KB (small stack, buffer, user-mode sched bookkeeping), and if you multiply that out by a million or something you're talking gigs. But I think much of the appeal of the standard Go way, and similar approaches in other languages, is you can write more or less as if you were doing simple synch I/O, and the runtime work that other folks have done gives you something decent with AIO, small stacks, user-space thread switching, etc. without you having to think much about it. I think the author says something similar put differently in the first paragraph. Something like rakoo's trick is interesting, with the caveat zzzcpan added that it takes at least a tiny buf, not zero-len, but if you don't actually hit this wall I'd charge forward the regular way.