>If you get 5 MB of JSON in N different requests (N=number of cores) at the same time, I don't see go generating free CPU time out of thin air.
You don't, but the scheduler normally won't allow one thread to completely starve the cpu. Of course, its clear they should be using limits, however JVM, glibc threads scheduler or Go's green threads likely wouldn't allow a single thread to completely starve the CPU, eventually the scheduler will step in and divert resources to another thread.
Without limits in a threaded solution, you would see the latency increase, but you wouldn't see the application stop taking requests altogether.
However there are real benefits for having an event loop concurrency, so this shouldn't be taken as a reason one model is strictly better than another.
You don't, but the scheduler normally won't allow one thread to completely starve the cpu. Of course, its clear they should be using limits, however JVM, glibc threads scheduler or Go's green threads likely wouldn't allow a single thread to completely starve the CPU, eventually the scheduler will step in and divert resources to another thread.
Without limits in a threaded solution, you would see the latency increase, but you wouldn't see the application stop taking requests altogether.
However there are real benefits for having an event loop concurrency, so this shouldn't be taken as a reason one model is strictly better than another.