Eh maybe. I work on a big, mature, production erlang system which has millions of processes per cluster and while the author is right in theory, these are quite extreme edge cases and i’ve never tripped over them.
Sure, if you design a shit system that depends on ETS for shares state there are dangers, so maybe don’t do that?
I’d still rather be writing this system in erlang than in another language, where the footguns are bigger.
Treating ETS as the only footgun misses a few ugly ones, because a bad mailbox backlog or a gen_server chain can turn local slowness into cluster-wide pain before anything actually crashes.
Erlang does make some failure modes less nasty. It also hides latency debt well enough that people thinks the model saved them right up until one overloaded process turns the whole system into a distributed whodunit.
Oh, I didn’t mean it’s the only one.
There are a bunch for sure! Turns out writing concurrent reliable distributed systems is really hard. I’ve not found anything else that makes them easier to deal with than BEAM though.
I’d switch if something better came along and happened to also be as battle hardened. I’ll be waiting a while i think.
in ten years of BEAM ive written a deadlock once. and zero times in prod.
id say its better to default to call instead of pushing people to use cast because it won't lock.
Generally agree, all the problems i’ve had with erlang have been related to full mailboxes or having one process type handling too many kinds of different messages etc.
These are manageable, but i really really stress and soak test my releases (max possible load / redline for 48+ hours) before they go out and since doing that things have been fairly fine, you can usually spot such issues in your metrics by doing that
[dead]