No. There's a certain amount of basic serialism in a single HTTP request. Go, Erlang, Haskell, a few others make it really easy to write handlers that may themselves be running on multiple cores, but the HTTP handling itself is essentially serialized by the fact that you have to get the request, then send the headers, then send the body, which itself probably has order constraints (such as HTML, which certainly does, at least unless you really go out of your way to write yourself a CSS framework that would render chunks of the HTML order-independent). Most of the required bits of handling a request, like header parsing, header generation, etc. have been made so efficient in the implementations that care about that that any attempt to multithread that would lose on coordination costs to a single-threaded implementation, I think... at least, I'd need to see a benchmark to the contrary before I'd believe in a win.

(You can play a lot of games in how a lot of requests are handled, even going to the HTTP2 extreme of interleaving responses to different requests on the underlying network stream, but what I said will be true on a per-request basis.)

I don't know about Go but Elixir/Erlang has a concurrency model that spreads one request workload over several cores.