Starting from the bottom up. The Erlang VM, the BEAM, is one OPS process which runs a number of threads, typically one per core. In many ways it is like an OS in that implements itself most of the typical OS things like processes, memory management, standard libraries, etc itself. So Erlang/Elixir processes are implemented in the BEAM itself and do not use OS processes or threads. This is how the BEAM can run literally millions of Erlang processes on one node (the maximum is somewhere around 150 million) as doing this using OS processes/threads would be impossible. To make it even more fun you can of course run multiple BEAMs on one machine as they are just OS processes.
The BEAM uses OS threads internally to do load balancing over all the cores. Each thread runs what is called a scheduler which manages processes, context switching, memory management, etc for that thread. All these schedulers are of course cooperating with each other and keep track of load to do load balancing internally almost automagically as it is something you seldom need to be aware of. It is just there.
It is a truly fantastic VM in all respects.
In many ways an Erlang process is very OS process like but much much much lighter. It is these process which can be viewed as actors as in many ways they behave in a very actor-like way, not in everything but in many things. Now Erlang/BEAM and hence Elixir were developed in a very pragmatic way: there was a problem we needed to solve and that was much more important than which theoretical model the solution was based on. It became functional and actor like because that worked!
I was talking with Carl Hewitt about this and he saw this as a strength of the actor model. You got there from both a theoretical POV and a pragmatic POV.
