Cons of concurrency and synchronization in elixir?

I have read some beginner books and so many articles about elixir, and everyone was appreciating the concurrency & synchronization in elixir. But in my thinking everything has some pros and cons, everyone talked about the pros, but no one really mentioned the cons of concurrency & synchronization in elixir.

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.

2 Likes

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.

4 Likes