4 ms·
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
by cyberpunk 7mo ago
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.
- myrak 7mo ago[dead]
- dnautics 7mo agoin 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.
- cyberpunk 7mo agoGenerally 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
- hrmtst93837 7mo ago[flagged]
- cyberpunk 7mo agoOh, 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.