I don't think he ever said such a thing. Do you have the source of this claim?
Some back story:
"Through the years, there were some attempts to build type systems on top of Erlang. One such attempt happened back in 1997, conducted by Simon Marlow, one of the lead developers of the Glasgow Haskell Compiler, and Philip Wadler, who worked on Haskell's design and has contributed to the theory behind monads (Read the paper on said type system). Joe Armstrong later commented on the paper:
One day Phil phoned me up and announced that a) Erlang needed a type system, b) he had written a small prototype of a type system and c) he had a one year’s sabbatical and was going to write a type system for Erlang and “were we interested?” Answer —“Yes.”
Phil Wadler and Simon Marlow worked on a type system for over a year and the results were published in [20]. The results of the project were somewhat disappointing. To start with, only a subset of the language was type-checkable, the major omission being the lack of process types and of type checking inter-process messages."
Q: "Erlang is currently a dynamically typed language. Are you saying you would like some static type as optional typing or both, or would you change the nature of Erlang to static typing?"
A: "No, I wouldn't change it, but I would like subdomains where it is statically typed. You could actually encapsulate parts in statically typed."
So it sounds like he stands by dynamic as the correct choice for Erlang, although not all of the time.
And I think that speaks to the current state of type system research on communicating processes, not to any fundamental inability thereof. Session types are a recent approach (though one that I don't think goes far enough; give me full-duplex channels!)
Erlang APIs are designed around the availability of dynamic pattern matching on messages, but static message typing is definitely feasible. The only feature of Erlang that stands out me as fundamentally incompatible with static typing is "live upgrade". And although this feature might be critical in the context for which it was designed (Ericcson telecom switches), it appears that very few Erlang-based deployments use live upgrade; the most common practice is to restart services.
I'm not that up on static typing, but it would seem to me that static typing would be difficult with different versioned nodes on dist as well as hot upgrade.
While a lot of users avoid hot load and restart/replace nodes instead, I don't think many restart/replace the whole cluster.
Yeah, would really love to see a static type system that tackled this directly - ie. handling versioned nodes in a cluster and ensuring deployments happen safety. I think it would be possible, but it would require some careful thought and design.
If you follow the philosophy of Erlang, you can take shortcuts to strongly thinking about it.
On the server side: what happens if a process geta a message it doesn't handle? Either it will crash (and be restarted by supervision, hopefully), it will receive and discard it (possibly logging it), or it will ignore it and leave it in the message queue (not great for long term memory use).
On the client side: what happens if the process sends a message that is ignored or crashes the receiver? The client will timeout, and won't know if the work was done or not; best to bubble up the error, perhaps by crashing (and maybe restarting by supervision).
If you're ok with these 'worst cases', you don't have to proactively deep think. The proper deployment strategy is clear: deploy servers that handle new messages first, then deploy clients that send new messages, but if you mess the order, you'll be within your failure model. It gets more tricky when there's a difference in data types and a piece of data could be used by old code, then new code, then old code, of course.
Of course, the actual worst cases are more fun, but less likely to happen. You could find a bug that crashes BEAM or something; I don't think that would be easily found by sending a unexpected message, but maybe (depends on what you do with unexpected messages).
But if your static typing just says yeah I dunno, it could crash, I don't think you've gained much from the exercise. I'm probably biased against static typing, but if it can model the system and provide useful insights that are accurate on the system, that sounds helpful; if it can't model the system though...
You're absolutely right: with Erlang you have to spend a great deal of effort planning for, implementing, and testing code that can work correctly across nodes with different versions of the code and/or versions of Erlang itself.
I think the open question is whether strong, _static_ type system can handle it at all.
Well, yes, that's the primary tool, but from my now-fuzzy memories working on Riak at Basho, I recall there being subtle and not-so-subtle risks and complexities to manage.
I believe the specifics were in regards to hot code reloading. Robert Virding (one of the creators of Erlang). This may be the specific quote you are remembering.
"I just want to confirm what has already been mentioned a number of times in this thread: the reason for not having static typing in Erlang was the absolute need for doing dynamic code upgrades of running systems. This was an absolute requirement and if we couldn’t do it then our language/system wasn’t interesting. There aren’t many systems using it today as most try to do rolling upgrades but we didn’t have that option back then so we had to be able to upgrade a running system. Remember we are talking late 80’s early 90’s here."
There is more to his comment and the thread that's worth reading:
There has been a lot of research and implementation work around gradual typing since erlang was initially conceived.
Using a type-system as a linter (with a few escape hatches whenever dynamic behavior is needed and without any impact on runtime) is still a great step forward as opposed to no types at all.
