This paper covers all the mainstream languages but I feel an "alternatives considered" section is missing. I would love to know what's the author's input on Swift server side, Elixir and Crystal.
For the benchmarks done in the paper, elixir should basically benchmark identically to erlang, since if there's any performance regression, it's a very thin wrapper.
I doubt crystal is mature enough in its multithreading model (which is still nascent, and IIRC not fully supported in the current rev, and inherited from ruby's in concept) to perform well at all in this. Erlang, Go and Akka were all conceived of specifically to handle multithreaded connections.
There were many languages that we would like to have considered. We do expect the performance of Elixir to be pretty similar to Erlang as it runs on the same VM (BEAM).
With regards the "alternatives considered", Section 2 outlines key characteristics of server languages, and Table 1 analyses a selection of languages against these characteristics.
We welcome others to report results for other languages using the benchmarks.
One thing you might find interesting - a small, crude experiment suggests that changing maxBlocking.erl to use process hibernation for those dormant processes could almost double the max number of processes Erlang can support.
I changed maxBlocking.erl's final few lines to read
Mainstream? It does not cover Java and C# and makes false assumptions on them. I have to assume that the detail selection group was not determined out of the 12 others but pre-defined. This paper is academic.
I doubt crystal is mature enough in its multithreading model (which is still nascent, and IIRC not fully supported in the current rev, and inherited from ruby's in concept) to perform well at all in this. Erlang, Go and Akka were all conceived of specifically to handle multithreaded connections.