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!
No
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 
but you could also follow the elixir-lang guide to start out with the language.
6 Likes
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
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 
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 ->
Process.sleep(100)
IO.puts("later")
end
IO.puts("seeya")
1 Like
Could you elaborate more in what you mean by failure domains? 
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.
2 Likes
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.
3 Likes
Thank you so much @ityonemo, I think I grasp the concept better now 
.
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
