upvote
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.

reply
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.

reply
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.

reply
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

reply
[dead]
reply