3 ms·
I think the practitioner angle is what makes interesting. Too many BEAM advocacy posts are theoretical. I would push back on the "shared state with locks vs is
by joshsegall 7mo ago
I think the practitioner angle is what makes interesting. Too many BEAM advocacy posts are theoretical.
I would push back on the "shared state with locks vs isolated state with message passing" framing. Both approaches model concurrency as execution that needs coordination. Switching from locks to mailboxes changes the syntax of failure, not the structure. A mailbox is still a shared mutable queue between sender and receiver, and actors still deadlock through circular messages.
- stingraycharles 7mo agoStateless vs stateful concurrency management is very different, though; I can roll back / replay a mail box, while this isn’t possible with shared locks. It’s a much cleaner architecture in general if you want to scale out, but it has more overhead.
- IsTom 7mo ago> actors still deadlock through circular messages I've rarely seen naked sends/receives in Erlang, you mostly go through OTP behaviors. And if you happen to use them and get stuck (without "after" clause), the fact you can just attach a console to a running system and inspect processes' states makes it much easier to debug.
- cess11 7mo agoWith OTP you can trivially decide whether you want your sender to block or not, and how you do your decoupling if you decide it shouldn't. In practice you'll likely push stuff through Oban, Phoenix PubSub or some other convenience library that gives you some opinions and best practices. It really lowers the bar for building concurrent systems.