The process id is not the only way to code the sending of a message in Erlang. You also can send a message to a named group if I remember right. Also, if you ar

The process id is not the only way to code the sending of a message in Erlang. You also can send a message to a named group if I remember right. Also, if you are using a supervisor tree (and for anything non-trivial you should), then the supervisor retains the process id. If that was not enough, as part of the Erlang runtime there is a process that handles binding and naming lookups, and it has the process id. Really don't see how this could happen. I consider bullet 2 to be a feature of Erlang, not a bug. If a module implements a behavior you know it implements those functions, there's no checking needed. Yes, it increases your attack surface, but outside apps should not be messaging Erlang processes directly. Bullet 3 seems like sugar. You can wrap the call in your own code that specifies a default timeout. I'm not saying your concepts are wrong, they are interesting and a more complete/accurate Actor model implementation in Erlang could be a good thing. However, the points you specifically made about Erlang do not seem to me to be needed adds to the language.