It is, but code updates still happen. Nodes aren't all identical.
As these things change, the contracts have to be exchanged with every member of the cluster which would not only add significant communication overhead, it would also bypass those compile time guarantees.
That's before even considering things like hot deploys where the code is updated live, while running, mid-execution.
The contract enforcement becomes akin to the goals of WSDL, which added a ton of overhead with minimal benefit aside from making consuming APIs easier for statically typed languages because of generators.
Is the overhead worth the difference from...
Client (this message will fail on this server) -> don't send
to...
Client -> (this message failed)
Especially when talking about a cluster which you own...that benefit is questionable at best.
The feature I'm talking about is a compile-time constraint. The sole purpose of it is to make development and refactoring easier by providing immediate feedback to the developer when they change code in a way incompatible with its interface. It is not really about providing global run-time guarantees. Solving evolving messages through deployment is really a separate topic, and something you have to do whether you have compile time checks or not.
I wrote and maintain Dialyxir. I'm familiar with Dialyzer. What it can't do, is tell me whether any given pid can actually accept and process a message of a particular type. You can write a module interface to your actor that does this, which is what most people do. But it is not quite the same as typed channels. And whoever started this thread was complaining about the "issue" in Akka. Messages are inherently dynamic in this style of communication. Its not the only possible style in either language, but its a valid criticism of this particular approach.
