4 ms·
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, i
by jlouis 4mo ago
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 4mo agoWhy, consider: mailbox → pattern matching → fully statically typed code. It's not unlike the standard HTTP-based API → routing and parsing → fully statically typed code.
- deleted 4mo ago[deleted]
- janderland 4mo agoMaybe 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 4mo agoIt'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.