This test is lacking some due diligence that I feel is skewing the results significantly (and, I assume, there are more that I haven't even noticed in Python/Ja

This test is lacking some due diligence that I feel is skewing the results significantly (and, I assume, there are more that I haven't even noticed in Python/Java). (While m1.medium only has one CPU, the network IO cost exists.) Erlang is automatically threaded by nature so it has some inherit scaling built-in (so the code benefits from threading as long as it runs correctly). The Go code is set up to spin up threads inside of ListenAndServe thus gaining the benefit of splitting up IO. The Haskell code has a thread specifically for garbage collection, thus utilizing the second core. The Node.js code could be using cluster (or threads/fibers more directly) but isn't for some reason. It also seems this was using the websocket npm (some unknown code running on the stack!). For a valid test the websocket code should be written in JavaScript directly in the test itself. Edit: Researched and Go actually uses ListenAndServe which creates threads on-the-fly but the m1.medium is bound to 1 CPU (it still benefits from threading due to IO).