> Do you refer to Erlang excelling in distributed concurrency, due to how its built to rely on the actor model? Or Erlang also excels in concurrency on a single machine?
Erlang has great concurrency also on a single machine. That is scales well to clusters is of course also good. And yes, it is the actor model that makes it work so well. That the individual processes are written in a (mostly) functional language is less important, I think. It could have been an imperative language and it wouldn't have made much difference, as long as process state was still isolated from other processes.
> Btw, what are some of those other things hampering Haskell's performance with parallel computing? Wouldn't the garbage collector mainly produce pauses instead of really destroying parallel performance?
Haskell's garbage collector is pretty slow when run on multiple cores, and when run on a single core it becomes a bottleneck to parallelism (and can also trash the caches of the other cores). I don't know all the specific technical details of GHCs GC, though.
Another problematic thing is laziness, which is operationally control flow plus side effects. Those are exactly the things that make efficient parallelism difficult.
> Although a concurrent garbage collector has recently been merged to the nightly GHC.
A concurrent GC is a different thing, that interleaves garbage collection with ordinary computation. That can be very useful, but it doesn't help with exploiting more cores.
Yep Erlang is fairly procedural as a language in a sense. I don't think being functional was ever a priority, more like a side-effect. I don't know how mailboxes and message passing would really work in a purely functional language anyway, could be awkward to work with them. Particularly with a functional (ML or what have you) type system (how to type mailboxes?).
> it doesn't help with exploiting more cores.
Yeah you're right, I believe the aim is to get rid of those garbage collection pauses for better concurrency (not parallelism).
From what I understand, GHC can do pre-emptive or cooperative scheduling. Pre-emptive being better for concurrency, just like Erlang does it.
> how mailboxes and message passing would really work in a purely functional language anyway, could be awkward to work with them.
It works really well and intuitively I would say, and even more; this is a common application to show the advantages of functional programming. Here is an article comparing sending messages asynchronously between threads in Elixir and Clojure (two common functional languages) https://bentomi.github.io/posts-output/2017-06-04-message-se...
Elixir and Clojure are not pure functional languages at all. They allow you to perform side effects freely, such as sending messages to different threads. They're not reflective of what the actor model would look like when implemented in a more purely functional language.
Moreover, I was mainly referring to using the actor model in a language with a static type system of functional languages (ML). What would be the type of the mailbox? The message? I believe even Facebook (Whatsapp) has struggled to find a solution to this question, they're developing a statically typed language on top of BEAM right now.
Erlang has great concurrency also on a single machine. That is scales well to clusters is of course also good. And yes, it is the actor model that makes it work so well. That the individual processes are written in a (mostly) functional language is less important, I think. It could have been an imperative language and it wouldn't have made much difference, as long as process state was still isolated from other processes.
> Btw, what are some of those other things hampering Haskell's performance with parallel computing? Wouldn't the garbage collector mainly produce pauses instead of really destroying parallel performance?
Haskell's garbage collector is pretty slow when run on multiple cores, and when run on a single core it becomes a bottleneck to parallelism (and can also trash the caches of the other cores). I don't know all the specific technical details of GHCs GC, though.
Another problematic thing is laziness, which is operationally control flow plus side effects. Those are exactly the things that make efficient parallelism difficult.
> Although a concurrent garbage collector has recently been merged to the nightly GHC.
A concurrent GC is a different thing, that interleaves garbage collection with ordinary computation. That can be very useful, but it doesn't help with exploiting more cores.