I'm a single core server, and I have a queue of tasks. I can process them one at a time. But say I don't want to work on one task at a time. I might decide to do some database operation and while I'm waiting for the response to come back, I might decide to do some work on a separate thread so I'm not idling. We now have concurrency. If I add more cores, and my program is coded to be able to take advantage of that, I have more workers to execute that queue and now we have parallelism! If I then go and add separate computers (nodes) and connect them over a network, we have created a distributed system which itself may be a concurrent, parallel system.
What Erlang and therefore Elixir gives you is a very sound mental model whereby your communication between nodes and separate workers is done via message passing between Erlang processes (read: not OS processes), and the receiving process may or may not be on the same computer as the sender. Those messages may also be synchronous or asynchronous, depending on what you're doing.
It also gives you a nice mental model for failure. Imagine I'm doing some super big indexing of some alphabetized data. It may make sense to subdivide that work along letter bounds, where some worker does A, another does B, ... etc. Suppose the worker for Q failed. What do you do? You may have to kill the entire job, but you might be able to get away with just repeating Q, or maybe even some subset of Q. But you as the worker that just failed are not in the best position to make that decision, so you fail and let your supervisor know, just like in a large organizational structure. That supervisor may decide the whole job is unrecoverable and fail and let ITS supervisor decide what to do. Erlang/Elixir gives you a toolkit to describe these operations via constructs called GenServers and Supervisors that you organize into what are called "supervision trees".
It also guarantees "fairness" between your jobs. Say you have the letter example, and whatever you're doing, the letter L s taking WAY more time than anyone else. To preserve overall system integrity, the Erlang VM will decide to say "hey man, you're gonna get a chance to finish but I'm gonna let M get some time for a bit and I'll come back to you." This is called "preemptive scheduling". This gives Erlang its "soft real time" properties.
All this to say, you're really setting yourself up to build more complicated systems if you need to. But even if you're not, and you have a typical CRUD app, things like preemptive scheduling are super powerful. Consider a web server. It may make sense to give each request its own process. If you have one that's taking too much time, the system will make sure you're not backing up completely by making sure the next request can run, for at least a little bit.
I'm kind of handwaving details here, but this is the general idea behind these types of systems. Erlang as originally designed was to handle telephony switches and such, and therefore had to handle many different callers all at the same time, on systems with not as much parallelism, and therefore being able to process jobs literally simultaneously, but they needed to ensure that the calls waiting to be connected could connect eventually.
They also designed around being able to hot upgrade your system. If I'm a telephone pole computer, there's no way they're gonna send a guy out to me to upgrade my system, and I want to make sure I can update the computer while it's still servicing the calls coming through it.
If you have a single core/threaded computer you can only schedule one task at a time and concurrency is an illusion.
What this functional language does is mask the complexity involved in SMP systems where state and data are subject to races via concurrent access. It also allows you to subscribe to the doomed philosophy of fail once, try again, try harder while ignoring the underlying cause. Trying the same thing over and over while failing has a name associated with it.
It implements a separate scheduler which superimposes it's rules over what ever OS kernel scheduling is in place. Sometimes you don't want that complexity.
It's functional. Who cares about functional as the _only_ model for a programming language?
Curious to know what the differences are vis-a-vis big data tools like Hadoop or Spark; as a user of those tools I recognized a lot of common failure patterns in the example above. Thanks!
I'm unfamiliar with Hadoop/Spark beyond knowing what they are and vaguely where they'd be used, but I imagine they tend on the "well we can just recalculate sub-jobs" failure models, instead optimizing developer speed over computational speed. Though that is wild speculation.
You wouldn't use Erlang/Elixir for doing calculation because that's just not what it's good at. But you might use it as something to manage jobs in a larger distributed system perhaps. Though my suspicion there is you may run into tooling impedance mismatches as you get deeper into the failure modes.
Sorry I can't speak more knowledgeably about that. I'm curious if any WhatsApp folks are around and can comment on if they ever made their Erlang systems talk with their Hadoop/Spark stuff and what that all looked like.
What Erlang and therefore Elixir gives you is a very sound mental model whereby your communication between nodes and separate workers is done via message passing between Erlang processes (read: not OS processes), and the receiving process may or may not be on the same computer as the sender. Those messages may also be synchronous or asynchronous, depending on what you're doing.
It also gives you a nice mental model for failure. Imagine I'm doing some super big indexing of some alphabetized data. It may make sense to subdivide that work along letter bounds, where some worker does A, another does B, ... etc. Suppose the worker for Q failed. What do you do? You may have to kill the entire job, but you might be able to get away with just repeating Q, or maybe even some subset of Q. But you as the worker that just failed are not in the best position to make that decision, so you fail and let your supervisor know, just like in a large organizational structure. That supervisor may decide the whole job is unrecoverable and fail and let ITS supervisor decide what to do. Erlang/Elixir gives you a toolkit to describe these operations via constructs called GenServers and Supervisors that you organize into what are called "supervision trees".
It also guarantees "fairness" between your jobs. Say you have the letter example, and whatever you're doing, the letter L s taking WAY more time than anyone else. To preserve overall system integrity, the Erlang VM will decide to say "hey man, you're gonna get a chance to finish but I'm gonna let M get some time for a bit and I'll come back to you." This is called "preemptive scheduling". This gives Erlang its "soft real time" properties.
All this to say, you're really setting yourself up to build more complicated systems if you need to. But even if you're not, and you have a typical CRUD app, things like preemptive scheduling are super powerful. Consider a web server. It may make sense to give each request its own process. If you have one that's taking too much time, the system will make sure you're not backing up completely by making sure the next request can run, for at least a little bit.
I'm kind of handwaving details here, but this is the general idea behind these types of systems. Erlang as originally designed was to handle telephony switches and such, and therefore had to handle many different callers all at the same time, on systems with not as much parallelism, and therefore being able to process jobs literally simultaneously, but they needed to ensure that the calls waiting to be connected could connect eventually.
They also designed around being able to hot upgrade your system. If I'm a telephone pole computer, there's no way they're gonna send a guy out to me to upgrade my system, and I want to make sure I can update the computer while it's still servicing the calls coming through it.