Erlang is a subset of Actors.
Erlang is weaker than Actors.
See https://guitarvydas.github.io/2021/01/22/superposition.html
Actors provides superposition.
Erlang provides superposition, as long as the software components do not use CALL/RETURN to communicate with one another.
Isolation is the idea that a software component be encapsulated in terms of:
Isolation is vital to superposition.
UNIX® pipes provide isolation.
Threads and processes provide isolation.
OOP provides encapsulation but not isolation. OOP encapsulates data only and hurts encapsulation of control-flow.[1]
Docker provides isolation.
Erlang provides processes, hence, Erlang provides isolation.
(Isolation could be performed more efficiently using closures and /CC (current continuations)).
https://guitarvydas.github.io/2020/12/09/Isolation.html
Prohibiting state is not necessary when isolation exists.
Erlang provides isolation and, mostly prohibits state through the use of FP (functional programming) techniques.
Actors do not prohibit state.
I conclude that Erlang is buzzword-compliant but is a subset of Actors.
CALL/RETURN uses underlying hardware to modify a global variable.
That variable is The Stack.
I discuss this issue in my essay "The ALGOL Bottleneck" https://guitarvydas.github.io/2020/12/25/The-ALGOL-Bottleneck.html and in my essay Call Return Spaghetti https://guitarvydas.github.io/2020/12/09/CALL-RETURN-Spaghetti.html.
The use of CALL/RETURN hurts the ability to provide isolation.
Actors inhibit the use of CALL/RETURN.
Erlang inhibits the use of CALL/RETURN at the component level. [Erlang appears to allow CALL/RETURN within a component].
Hierarchy is to message-passing as structured programming is to assembler programming.
Actors allow, but do not encourage, hierarchy of components.
Erlang allows hierarchy of components as long as CALL/RETURN is not used.
Erlang is a subset of Actors, in that Erlang allows a mixture of CALL/RETURN-less and CALL/RETURN-full programming, whereas Actors prescribes only CALL/RETURN-less programming.
Non-hierarchical message-passing - flat message-passing - has been associated with the apparent failure of message-passing in general.
Explicit naming of a target routine introduces dependencies.
For example, most current PLs (Programming Language) invoke routines through direct calling, e.g.
f(x)
(here, the function f() is CALLed by directly naming the function f() that is to be used).
Actors indirectly name targets by use of a pid (process id).
Erlang does the same.
[Using a PID results in knowledge of the target and results in dependencies (IMO "bad"). Furthermore, using PIDs at runtime causes dynamic dependencies which is akin to self-modifying code ("very bad")].
Actors imply concurrency.
Erlang implements concurrency using processes.
See Rob Pike's talk - Concurrency Is Not Parallelism https://www.youtube.com/watch?v=oV9rvDllKEg.
Actors and Erlang allow construction of Software Components using the concurrent paradigm.
Hence, Actor and Erlang programs can be run in parallel.
I don't know if Erlang (and BEAM) provides parallelism "out of the box".
https://guitarvydas.github.io/2021/01/22/One-In-How-Many-Out.html
Isolated software components can be composed to form a system (e.g. an app).
Actors and Erlang provide isolation, so they support composition of components.
[1] Inheritance is a good way to organize data. Inheritance, with overrides, is a bad way to organize control flow (e.g. code).