A bigger problem is this: - Given a distributed Erlang system with two nodes, where both nodes are running the same release; - Given the same process (Erlang

A bigger problem is this: - Given a distributed Erlang system with two nodes, where both nodes are running the same release; - Given the same process (Erlang thread) on both nodes, running the same code (i.e. a GenServer backed by the same module) - Given a new version of the release is being applied You can't assume that the two processes will be upgraded at the same time. This means that messages sent between those processes may violate the types expected by one version or the other. Furthermore, in Erlang, any process can send a message to another process, so there is no way to enforce that the data a particular `receive` expression gets will even be a type defined in the code it is running. Furthermore, even on the same node, during an upgrade, some parts of the system are still running old code, while some parts are running new code, so it isn't even specifically about distribution. There is a whole area of type system research around session types, which are designed for more or less this use case, but from what I've seen, none of them handle the case of arbitrary messages, or the case where system upgrades are being rolled out and old code may receive messages from new code. I still think there is a place for a type system in Erlang/Elixir, but it would have to deliberately ignore process messaging at the very least, at least until a type theoretic solution is available.