The only con ai can think of is that concurrency is a lie. I mean, on many machines you will get concurrency, but in its nature, Erlang is parallel, not concurrent.

Other than that there isn’t much issues, maybe except the fact that many people think that throwing more processes at things will make things faster, which is obviously false.

In order to answer that question, I think we need to recap how Elixir/Erlang handles concurrency and synchronization: Isolated processes that communicate via messages, and general immutability of data.
If we leave ETS out of the equation for now, that means that nothing is shared between the processes.

When one uses multi-thread programming as a concurrency paradigm, the rules are different: Memory is shared, and one must ensure that this does not lead to trouble using semaphores or lock-free algorithms.

The disadvantage of Erlang’s approach is that someone has made a choice for you. You cannot easily share data between processes and you cannot easily implement your own lock-free algorithms.
So there are situations where it is not possible to achieve the same performance in Erlang as you can using multiple threads.

That being said. I think that in most cases the process-based model with messages being the way to exchange data between them, is vastly superior to threads.
The model has also been copied to many different languages and environments. Probably because it is much easier to work with, and because the drawbacks are few.

Obviously the con is when you absolutely positively need synchronization / barriers / semaphores / mutexes like in a normal DB engine.

Another con could be that the preemptive scheduling nature of the BEAM loses some CPU cycles to achieve the godlike responsiveness of the runtime. People working with lower-level languages, especially Rust lately, are efficiency fanatics and disagree with that tradeoff. (Although some that I have worked with admitted that the Erlang’s idea of processes with isolated mailboxes would kill 90% of the bugs they encountered in their code.)

I’m a big fan of cons included when there’s a bunch of pros. However, I was racking my brain a bit to think of practical cons with the approach in Elixir.

For me, efficiency is not necessarily a practical con because I wouldn’t say I was ever hindered by the parallelism of Elixir. But I can appreciate the approach it takes having an overhead and people considering that a con.

To me, maybe the biggest con is that parallel and synchronous code are something that can trip people up. It’s not this magical system that prevents coding or understanding errors. A person may think some code is parallel but then it converges into a synchronous choke point because they missed something.

Speed. Erlang (and elixir) are opinionated about how to achieve concurrency. Those opinions cost you processor speed. It’s not much, bit it’s real. Your elixir will never be as fast as go or java (but it will be faster than python or ruby).

For most people if they think they will need cpu speed are fooling themselves. It is no longer the 90s (or earlier) The bottleneck is usually somewhere else.

That’s frankly a selling point to me. I wouldn’t put Elixir in a competition versus Go or Java or Rust. However, Elixir does seem to be one of the fastest dynamic languages out there (and I mean top 10, if not 5 even).

So in its segment Elixir is quite impressive in terms of speed.

Could you clarify this? The terms ‘parallel’ and ‘concurrent’ are often confused and there is also some middle ground for which people disagree over whether it falls under one or the other.

To my knowledge, paralellism = doing the same task many times side-by-side (on slightly different data) whereas concurrency = doing different tasks at the same time.

That’s not the difference.

Concurrency: Interweaving the completion of multiple tasks, instead of completing one after the other. (Works on a single core machine)
Parallelism: Doing multiple tasks at the same time (needs multi core)

These two definitions I know under the terms multitasking (interweaving multiple tasks on a single core) and multithreading (doing multiple tasks at the same time) respectively.

EDIT: I stand corrected. The definition you mention seems indeed very common and probably is ubiquitous. I should have a talk with my parallel computing professor from back in the day, he did not explain it very well.

It is important to remember, that you need concurrency to make things parallel, but you do not need parallelisation for concurrency.