If you are comparing to Go then just regular Haskell has all the same capabilities and more (lightweight threads and communication primitives, plus extra cool stuff like software transactional memory). Cloud Haskell is trying to put it more in the Erlang camp where you can distribute beyond a single process transparently, but I don't think it is well maintained or really production ready.

More specifically, thoughts comparing Akka, Erlang and Cloud Haskell, which are 3 different implementations of the actor model.

Some educated guesses here:

(1) Cloud Haskell is primarily designed for execution on distributed memory architectures where the messages pass over a network. So expect that the it would show high communication latency in the first PingPing benchmark.

(2) GHC Haskell processes are lightweight, i.e. maintained in the GHC Runtime Environment, and elsewhere in this discussion called fibres. So expect that it would have fast process creation and be able to sustain a large maximum number of processes (second benchmark).

(3) It's hard to speculate on throughput (third benchmark). The high communication latency may be hidden in a steady state by having multiple requests in the network. Haskell execution time is slower than many languages, but is probably comparable with Erlang and Scala.

> Haskell execution tome is slower than many languages, but is probably comparable with Erlang and Scala.

Do you have specifics on that matter ?

There are various multi-language benchmarks, e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/

Those benchmarks do not compare like-for-like. Often the Haskell versions try to solve the problems elegantly with high-level functional code at the expense of performance, e.g. see Mandelbrot.

GHC Haskell is an advanced optimising compiler that will produce considerably faster functional code than both Erlang and Java. For maximum performance, it is perfectly possible to write imperative array-oriented code in Haskell, in which case performance should be comparable to Java.

> GHC Haskell is…

Please consider all the things Phil Trinder likely knows about GHC ;-)

https://scholar.google.co.uk/citations?user=3Bs_EA0AAAAJ

My post was more for the benefit of other readers, who might have otherwise concluded that modern GHC is "slow". There are many ways to compare the 'execution time' of e.g. Java and Haskell. Idiomatic Haskell code may well be slower than (traditional) idiomatic Java code. But these days more and more functional code is written in Java/Scala/Clojure and the JVM does not optimise such code nearly as well as GHC.

> Idiomatic Haskell code may well be slower…

So it's a good thing that those "benchmarks do not compare like-for-like" because that allows the inclusion of idiomatic Haskell code?

I can certainly see merit in that idea. The problem is that it's often not clear what the idiomatic style for a particular language applied to a particular problem is. Many of the Haskell solutions also look quite old, predating for example the now standard Haskell "Vector" library.

It's a useful resource, but I think we should we wary of making very general remarks based on the results.

We should we wary of making very general remarks, period.

The benchmarks game is not restricted to "the idiomatic style" so it isn't a problem that "the idiomatic style" for a particular problem is often not clear.

> Many of the Haskell solutions also look quite old…

We would be very happy to accept new programs:

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

> We should we wary of making very general remarks, period.

Do you mean you agree? Do you mean the statement is possibly self-defeating? Do you mean you noticed the typo? Do you mean…?