[jlouis]

Statically typing the underlying message passing model used in Erlang is pretty hard, because the mailbox of a process can accept any type of message. And so, it cannot be statically typed in general, since anyone who holds a process id can shove a message into that mailbox.

In contrast, Go's message passing model works on typed channels. A channel has a type, and only accepts messages of the given type. The `receive` operator then acts as the merging data flow which solves the problem of receiving messages of different types. This is a design which amends itself far better to static typing.

Pattern matching isn't a substitute for static typing at all. The two features are entirely orthogonal indeed, and you definitely want static typing and pattern matching at the same time.

[nine_k]

Why, consider: mailbox → pattern matching → fully statically typed code.

It's not unlike the standard HTTP-based API → routing and parsing → fully statically typed code.

[janderland]

Maybe you’re implying that message passing makes compile-time validation of messages difficult? The types themselves are a solved problem, as long as you allow actors to fail when they receive a message they can’t handle.

[true_religion]

It's really not a problem to have actors fail like that so long as you're using structural types.

It in fact mimics what a lot of people are already doing with pattern matching.

So I don't think there is any real good reason to not allow enforcing static types, at least across your own part of the codebase anyways.