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 :/

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.