Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

Erlang performance is not so bad - far better process spawn time, throughput very similar to Scala + akka, a bit worser than Golang one

For those who can’t download PDFs at work etc, here’s the conclusion (I’ve highlighted mentions of Erlang):

Conclusion
We have investigated programming language characteristics that support the engineering of multicore web servers. Crucially these languages must be able to support massive concurrency on multi- core machines with low communication and synchronisation over- heads. We have analysed 12 languages considering computation, coordination, compilation, and popularity, and selected three rep- resentative high-level languages for detailed analysis: Erlang, Go, and Scala/Akka (Section 2). We have designed three server bench- marks that analyse key performance characteristics of the languages, i.e. inter-process communication latency, process creation time, the maximum number of supported processes, and throughput (Sec- tion 3).
A summary of the recommendations based on this small set of benchmarks is as follows. For a server where minimising message latency is crucial, Go and Erlang are the best choice (Figure 3). Interestingly Akka significantly reduces communication latency in Scala (Figures 3(a) and 3(b)). Scala/Akka are capable of maintaining the largest number of dormant processes (∼11M processes in Figure 4(a)), while Erlang performs the best when processes are short lived and the goal is to ensure minimal spawn time, e.g. Erlang takes 58s to spawn 9M processes (Section 4.2). In server applications where up to 100,000 processes are frequently spawned, Erlang and Go minimise process creation time and scale smoothly (Figure 4(b)). Experiments with communicating pairs of processes show that Go provides the highest throughput independent of the number of cores and the number of process pairs (Figure 5).
Comparing the performance of complete case study servers im- plemented in each language would significantly reinforce these results, and one possibility is an Instant Messaging (IM) bench- mark [4]. It would also be interesting to study the performance overheads of providing fault tolerance and of recovering from faults, another key server capability. Finally we could compare the perfor- mance of server languages on distributed memory architectures, e.g. a cluster of multicores.

As Chris mentioned elsewhere, Phoenix pubsub is the only one of the pubsub implementations tested that supports being distributed.

In my opinion this isn’t a fair comparison; these are not “processes” they are Futures. Scala’s monad comprehensions can make your Future code look sequential, but is not sequential, and you cannot use traditional IO libraries at all outside of a dedicated thread-pool or you will block your entire scheduler.

This is one of the things that bugs me about C++ with ASIO libs–slip up and make one lousy call to the wrong standard function, and now you have a latent performance disaster that will not show up in any test but is just waiting to collapse throughput under a critical load.