I do assume using goroutines is slower than multiplexing though, but still plenty fast. Surely, the goroutine model is just an abstraction built on multiplexin

I do assume using goroutines is slower than multiplexing though, but still plenty fast. Surely, the goroutine model is just an abstraction built on multiplexing? As in, it uses the exact same syscalls that a multiplexing server written in C would use, except instead of storing state explicitly in a connection structure, it's stored implicitly in the goroutine's stack. The main (only?) real difference is code structure and thus the dispatch mechanism to where in the connection handling code processing should resume: In the goroutine, you're literally storing the instruction pointer and jumping straight to it. In the hand-written case, you'll probably go through some buffering code and an explicit state machine. Basically, Go and its goroutines save you reinventing the connection state capture and resuming code for every single protocol you implement - it comes for free as part of the language. (you can make C do similar things with makecontext/swapcontext plus some extra plumbing code of course) Performance wise it should be a pretty close call: resuming a goroutine will presumably cause a branch prediction miss (due to the change in function return pointer), whereas the multiplexed code will need to wind its way through the state machine logic - almost certainly also a branch prediction miss. CPU cache behaviour should likewise be similar (you're storing the same state either way).