Nice article, and for an Elixir fan, provides a nice little snippet on something I've been having issues with but hadn't really put my finger on until I saw it:
"[...] and I really dislike that Elixir tries to hide immutability. That does make it slightly easier for beginners, but it’s a leaky abstraction. The immutability eventually bleeds through and then you have to think about it."
I don't think it necessarily tries to hide it (at all), but it does have some instances where something feels like a mutable structure. Those can be, at least for me, a bit confusing to reason about if you're expecting things both be and look immutable.
I suppose now that I know exactly what's weird, I should just go dig through the code and figure it out. Problem solved?
... One other thing, because I see this in the comments already, is that BEAM isn't the tool for every job-- but for some jobs, it is the only tool to do it well. Is the JVM faster at general tasks? Hell yes, but that's not the point, it's not even why BEAM is around.
It's about:
* Small concurrent workloads. Really long running CPU intensive tasks aren't going to be good.
* Low latency. Not just low, but with a very very small standard deviation. Your application's performance will be consistent.
* Fault tolerant.
The list goes on, and here's a nice summary of it (both bad and good):
There are times when I choose the JVM, there are times when I choose BEAM or MRI. I just try choose the right tool for the job, but some tools, make some jobs, very difficult.
cough ruby cough concurrency cough
Edit: One thing for people not familiar with BEAM, a "process" is not a Unix process, from the Elixir documentation:
"Processes in Elixir are extremely lightweight in terms of memory and CPU (unlike threads in many other programming languages). Because of this, it is not uncommon to have tens or even hundreds of thousands of processes running simultaneously."
Then again, there's NIF libs with Threads for those tasks which are long running and require computational performance. Last I checked all the really fast math libraries were written in C/Fortran/C++ not Java
"[...] and I really dislike that Elixir tries to hide immutability. That does make it slightly easier for beginners, but it’s a leaky abstraction. The immutability eventually bleeds through and then you have to think about it."
I don't think it necessarily tries to hide it (at all), but it does have some instances where something feels like a mutable structure. Those can be, at least for me, a bit confusing to reason about if you're expecting things both be and look immutable.
I suppose now that I know exactly what's weird, I should just go dig through the code and figure it out. Problem solved?
... One other thing, because I see this in the comments already, is that BEAM isn't the tool for every job-- but for some jobs, it is the only tool to do it well. Is the JVM faster at general tasks? Hell yes, but that's not the point, it's not even why BEAM is around.
It's about:
* Small concurrent workloads. Really long running CPU intensive tasks aren't going to be good.
* Low latency. Not just low, but with a very very small standard deviation. Your application's performance will be consistent.
* Fault tolerant.
The list goes on, and here's a nice summary of it (both bad and good):
http://blog.troutwine.us/2013/07/10/choose_erlang.html
There are times when I choose the JVM, there are times when I choose BEAM or MRI. I just try choose the right tool for the job, but some tools, make some jobs, very difficult.
cough ruby cough concurrency cough
Edit: One thing for people not familiar with BEAM, a "process" is not a Unix process, from the Elixir documentation:
"Processes in Elixir are extremely lightweight in terms of memory and CPU (unlike threads in many other programming languages). Because of this, it is not uncommon to have tens or even hundreds of thousands of processes running simultaneously."