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.