In Erlang how is using registered processes different from global variables in a traditional language?

Question

To me they seem to be the same thing, its just that registered processes are disguised by the terminology "actors".

Update:

I have since seen the error in my way of thinking. I guess as I am new to Erlang I was using actors in places where they did not belong at all (is there an anti-pattern name for this somewhere?)

Answer 1

I frequently see examples using process registration to simplify the example code (by avoiding another function parameter). This has the effect that newbies tend to use process registration a whole lot (monkey see, monkey do).

And they (newbies) tend to change the registration as part of normal operations. They tend to construct atoms to register as, and have other processes construct atoms to look up processes. When you do this, then you are having shared state concurrency (limited, but still bad).

The registry should be used for (okay, these are my own rules for when to use them):

• long-running services. Then it is as much global state as when you refer to a constant such as the speed of light.
• registering processes to aid debugging a running system, but those names should never be referenced by code, only by humans at the shell

The registered names should have a prefix (typically the application name), and the long-running applications should be in the OTP .app file.

Answer 2

Registered processes are global identifiers to a process id (Pid), which is itself a global way to address a process (it is just unknown beforehand).

However, saying that using a global identifier is the same as a global variable is conflating the issue a whole damn lot. It's similar to say something like 'URIs are global variables'. There are fundamental differences in terms of scope, mutability, encapsulation and isolation of data that makes them really different.

Note that the actor model is a general concept about concurrent computation. Erlang processes are only one of many potential way to implement an actor model. Scala, E, Axum and many other languages support programming with actors, but the implementations are pretty different.