Do I need an academic background in concurrent/parallel/distributed programming to make full use of Elixir?

Do I need an academic background in concurrent/parallel/distributed programming to make full use of Elixir?
If so, any must reads you can point me to?

Thanks all!


But the post need more that 6 characters.

1 Like

If you’re just starting out checkout the talk The Soul of Erlang and Elixir by Sasa Juric

His book, elixir in action is great :slight_smile: but you could also follow the elixir-lang guide to start out with the language.


Thanks @chouzar !

1 Like

Sure! The key to elixir is understanding how reliability is achieved; so the language and virtual machine already come with concurrency and distribution primitives built in.

Parallelism is something that can definetly be done with elixir but I would say is not a common pattern (maybe someone here would like to correct me).

Another interesting point of view:

Where Osa talks how language primitives are structurally different, giving us the concurrency properties of the language :slight_smile:

1 Like

Great stuff @chouzar! I’m already watching Sasa Juric’s. I come from Ruby and I haven’t really done any concurrent programs in it, since as far as I know it doesn’t have true concurrency. I started learning about concurrency at the university until I had to drop out.

Oh! There are many ways of doing concurrency. I have no background with Ruby but the reason of why erlang/elixir concurrency is special is because of the time-sharing model of the Virtual Machine (basically, each process is treated “equally” by the VM and not limited to a specific architecture). I think this is touched on Sasa’s presentation.

Is a whole world out there; but I don’t have any formal studies on concurrency (skipped thread handling at uni, I was betting on more Hertz).

Too bad :frowning: but let me know if I can be of any help.

Most appreciated!

I would say that the thing about erlang/elixir concurrency is that the units of concurrency are organized along the lines of failure domains and as far as I know it is really the only system that does this (maybe kubernetes comes close). Definitely not go, or rust. God help you with C++ (I cut my teeth learning concurrency, recreationally coding on the BeOS in 1999 - this was basically the actor model in C++, didn’t know it at the time, until I entered the Elixir world decades later). Even most of the theoretical models of concurrency, around the actor system that get talked about by carl hewitt are presented in some sort of computational advantage light.

Anyways erlang/elixir makes it easy. Here’s a concurrent program:

spawn fn ->
1 Like

Could you elaborate more in what you mean by failure domains? :open_mouth:

I’ll give you a complex real world example. For work I’m writing software that monitors virtual machines and hosts. There’s a process modeling the host, a process modeling the vms, and a process for the communications channel. If the communications channel dies, there’s no reasonable state for the host or VM to be in, so those processes are torn down immediately and the whole system goes back into a mode where it attempts to reconnect.

I’ve unified the failure domains of the communication channel, the host monitoring, and the vm monitoring. In about four lines of elixir. This means I don’t have to write a ton of safety checks or watch out for invalid communications channel states, etc.

So I can bundle my concurrent things together into a single failure domain. But also a separate process monitoring a different host and vm is unaffected by the shenanigans of the failing host. That’s what makes erlang concurrency so powerful, they are almost totally separate concerns, except when you want them to be.

This makes testing way easier too (especially with the way elixir tests are set up). I can test conditions in isolation, and because my tests are run randomly and concurrently, I can be sure that the system as a whole is more robust, fault tolerant, and able to operate independently.


That sounds really cool! Thanks for sharing, however I’m still a bit lost on the concept of “failure domain”.

You mean like a “standard behaviour” to follow when any of the components (channel, monitoring) fail?

Do all component share the same behaviour? Or each one has its own set of rules?

A failure domain is a collection of things that can fail simultaneously from a single root cause. For example, a data center is a failure domain (there could be an earthquake or a data fiber cut); a rack is a failure domain, because the entire rack could lose power, a server blade is a failure domain because the CPU could catch fire, an OS process is a failure domain. Most languages stop there because panics will bring down the whole system; erlang and Elixir in most cases let you ‘panic’ your processes and just throw them out without impeding forward progress of your system, but with links and supervisor trees you can also very easily create custom failure domains that match real failure domains in your business logic/the real world.

To be the most effective at its job, each failure domain must have its own set of well considered rules to manage failures and restarts. And also here erlang and Elixir come built in with basic strategies that sensibly cover the most important cases and by being careful with init/1 you can make the rules highly effective and specified.


Thank you so much @ityonemo, I think I grasp the concept better now :smiley:.
Building a supervision strategy is an art of itself which still needs a lot of polish on my end.

I’m still learning it too! That’s probably why I’m so excited about it. But it’s important to read the docs (and play around with) the difference between :transient, :temporary, and :permanent, once you get there.

1 Like