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.

Crystal's multi threading model will eventually be exactly the same as go's, not ruby's, but yes its not done yet.

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.

Hi Phil,

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

    p() ->
        erlang:hibernate(?MODULE, q, []).
    q() ->
        receive
            "hello" ->
                io:format("Hello")
        end.

RabbitMQ uses hibernation in many places to reduce memory usage when many resources are being managed by the server.

Thanks for the info. We're not ninja developers in any of the languages.

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.