As the parent illustrated, even with Go using nonblocking I/O, it's perceived benefits in that area isn't that great because Go still semantically has a thread-per-connection. So the performance characteristics of Go isn't simply async vs sync I/O.
One reason, not the only, or the most important. The primary advantage of non blocking IO is that the CPU isn't sitting idle while waiting for an IO operation to complete. We aren't wasting an entire core to write the response.
which are very cheap :)
I know, of course. If you reread my comment, you'll notice that it wasn't focusing on the particular syscall that the system uses.
> Using nonblocking IO will provide better performance because it will increase the number of concurrent requests it can serve.
Because of (a), (b), and/or (c), which I addressed in my comment above.
Are we willing to wait 6x longer for rust to catch up? Some people are, most people aren't.