In parallelism, processes 1 and 2 are able to execute at the same time and also operate completely independent of each other. This means that the steps involved in the concurrency example might end up delaying each other in some way (for example, if Task B is ready to begin right as Task A completes and is spitting back output).

We will talk in much greater detail about this, but the model behind Elixir makes it so that parallelism is the default state every time and is handled extremely efficiently. Also, you may notice that the definitions for concurrency and parallelism overlap each other a little bit; something that is concurrent is not necessarily parallel, but something that is parallel is necessarily concurrent!

In the Elixir world, if you're doing a lot of research, you may find that the two terms are used basically interchangeably, and even in this book we tend to stick to describing this problem as Elixir's concurrency model as opposed to Elixir's parallelism model. Part of this is related to community conventions and part of it is due to how these approaches and problems are described in a lot of other technologies. Ultimately, the important thing to note is that when we're talking about concurrency in Elixir, we're talking about its ability to do many things, all at the same time, and in an incredibly safe way that doesn't require us to implement crazy mutexes and semaphores and all kinds of other major headaches and nightmares!