mungobungo

4 ms·

1. 1.▲
   by mungobungo 4y ago

   Ahh great. “On Erlang, State and Crashes” is exactly answering my question. As for disks - in good old times when servers were pets, not cattle that was a good idea. But now when the servers are as ephemeral as actors, we need to approach i
2. 2.▲
   by mungobungo 4y ago

   Thank you, i was not aware of the Horde package. Definitely worth looking. I was also thinking what should happen in case of ‘electricity disappears’ scenario, but came to a conclusion that it is good old ‘save the state you care about’
3. 3.▲
   by mungobungo 4y ago

   What i had in mind is some kind of gen_fsm or gen_statemachine. For stateless applications it is pretty obvious how supervision trees can improve the reliability. Essentially the only ‘state’ there is request itself. Worst case scenario cli
4. 4.▲
   by mungobungo 4y ago

   Well, let’s assume we are talking about a webshop. Every user is represented as an actor, a cart might be a state. So cart as a state should be stored somewhere else, let’s say redis. And every single read/write operation would be a
5. 5.▲
   by mungobungo 4y ago

   Practical question here. How are Elixir/Erlang apps being deployed nowadays? My understanding is that BEAM is designed for long running setups where hot reload of the code makes sense, and reboots are not happening that often thanks to