|
I imagine similar to the use cases for Erlang. Erlang can be a polarizing language, but what it's designed to do, it does exceptionally well, in fact, maybe the best. And that's not concurrency, multicore programming, or distribution. That was all a consequence of the main goal, which was fault tolerance. If you're a Swedish telecom company, you don't want a little bug in the code, that happens during someone's phone call, to knock out a switch, which takes down 50k phone calls, only for some guy to have to trek out into the middle of the forest to restart the computer running everything. So the model they came up with was high isolation, via processes(no OS processes, but super tiny, like a few hundred bytes processes, all managed by the VM), and distribution(can't have reliability if one node can knock out the system). The other unique part is the supervision trees that manage those processes. Let's say you have a chat server. You may have a process per device connected to the server, a supervisor for each chat room(group of processes), and a supervisor for all the chat rooms(supervisor of supervisors). Supervisors are themselves processes, but with a specific job. If your phone's connection/process on the server has some issue, it'll just crash, that's the erlang philosphy "let it crash". You as the user likely can't fix it. The code can't magically fix itself. But presumably through testing we know that initial connections with a clean state are stable, so let it crash, your phone reconnects. Then it crashes again. Reconnects. Crashes again. (This isn't the ideal state obviously, but a worst case for demonstration). Eventually that'll trigger some limit, where the chat group supervisor will notice, somethings wrong here, there's some state that's in a mess, it's time to crash so we can get a fresh try at this. So it'll crash. Usually the first phone reconnection would have been enough to fix it and the group supervisor wouldn't need to restart, but for demonstration purposes we'll say it does, and let's pretend when it comes back up it crashes again. This will propagate up, until enough restarts have fixed the state of the system to the point where it's stable again. I believe Erlang was the first system to achieve nine 9s of reliability, which is 31.56 milliseconds of downtime a year. Not saying this lib will get you that, but that's the spiel for Erlang. |