[exabrial]

I'm curious, which Java servers are creating a new Thread per request?

Tomcat uses acceptors threads and a request executor pool. And, if available on your platform (which it probably is), it defaults to using non-blocking IO instead of polling.

EDIT: It looks like he does acknowledge the executor threads are pooled. His main criticism is that "too many blocked threads are bad for a scheduler". But if Tomcat is using the NIO connector this doesn't apply, because your executor threads won't block on IO. And typically the pool size is limited to something manageable by a modern CPU (200 or so)

[ww520]

It does seem the author has way outdated information or set up the benchmark to tilt the balance in certain way.

A more comprehensive benchmark is done here. https://www.techempower.com/benchmarks/#section=data-r14&hw=...

[blinkingled]

Yeah that perplexed me as well. There's no reason you can't get a modern Java app server to do async io coupled with thread pools and achieve performance close to Go. Maybe Go's coroutines vs Java native threads may give Go a little advantage but it shouldn't be a great difference for sanely designed applications.

[pjmlp]

Netty would be one possible option, but he selectively left out everything that could jeopardize Go's victory.

[exabrial]

Yah, the Netty model is more in-line with Go's programming model.