Erlang's parallelism is not parallelism

Yep, you are right that I am missing out on the fact that there is different types of parallelism in the post. But it was getting too big of a post already :/

You can also classify parallelism. An example is to compare that you annotate parallel execution on the data structure (this is a parallel array) or on the control-flow (when operating on this array, do it in parallel). Another is if the parallel distinction is largely dynamic (worker pool) or static (we know we have 16 cores so the optimal communication structure assuming a double torus pairing configuration is ...). Yet another is to look at the data themselves. Are they a flat array or a nested tree structure (Nested Data Level parallelism is cool btw). And finally, to stop all the examples, we could look at declaratively making the code parallel and doing so explicitly yourself from primitives (think rolling your own database versus writing queries in SQL for an existing one - and hope the query optimizer can help).

The main point is that Erlang has taken a choice here. And that choice only covers some uses of what people may want to do. For the other things, people tend to use Erlang as a controller and then write their FPGA code and run it separately. This is what the original telephony switches were doing with Erlang.

Parallelism is an algorithms problem: given n processors, design an algorithm that runs faster as n increases.

Concurrency is a systems problem: design a system that safely runs n separate but interacting contexts of execution. Erlang's solution to concurrency--no communication between processes other than asymmetric message passing, no shared state other than the process registry--is a great solution to concurrency in terms of safety and distributon across multiple hosts, but it provides limited help to parallelism.

Erlang's reputation as a great language for concurrent programming on multicore processors is largely by accident--it has a great concurrency model for networks of distributed machines, and almost any concurrency model is better than mutexes and threads, but on multicore machines, Erlang wins only by default.

"I'm dubious that Haskell is better for writing distributed concurrent systems,... Rather than bashing erlang like this, I'd have gotten a lot more out of an article that described how Haskell approached the problem,"

I'm not sure exactly where you saw the claim that Haskell is better at writing distributed concurrent systems. The Haskell distributed concurrency story is basically that there isn't one. There's a very early stab at adapting Erlang-style concurrency as a library, but there's nothing that I know of that is shipping and standardized that is a solution to that problem, and there's certainly nothing like Erlang, where a certain type of reliability informs the design of the language from top-to-bottom.

Someday I look forward to a Haskell that has stolen (ahem) Erlang's OTP but we're a ways away from that.

Also, clearly explaining Erlang's origins as focused on reliability, rather than "concurrency", is doing Erlang a favor, not criticizing it. I think more people would put up with its quirks if they realized that at least some of them come from this strong focus on a use case usually ignored by mainstream languages, rather than seeing it as an attempt at a mainstream language with a strong concurrency focus. (Some of its quirks are just bad, though.)

I think you got this article entirely wrong.

Jlouis (the author) is an advanced Erlang user who does know the language very well. He wrote etorrent, an Erlang bitorrent client in Erlang (which was also compared with combinatorrent, his Haskell version).

The article isn't about bashing Erlang, but changing the perspective under which it is observed. Namely, the language isn't about parallelism, but parallelism is a nice-to-have feature made possible by the concurrency constructs of the language, which themselves come from a need for fault-tolerance. I would certainly say he is right and I support this way of explaining things.

I'm a somewhat advanced Erlang user, and I enjoyed the article.

I am not sure where you got that competition with Haskell aspect, but I don't think it was ever the point.

"I'm not sure who's running around saying Erlang provides parallelism."

I'll say it does. beam.smp spins up multiple threads and I see them using more than one core regularly on my machines.

A thorough read would mention the semantic difference between them, the granularity of parallelism, some of the intent behind the concurrency/parallelism constructs, implications of performance when trying to do parallelism in Erlang, general parallel execution theory and strategies related to it.