Many, many, many thanks to have shared this code 
This is so, so, so cool 
This will be my favorite demo to show in person to others that I will try to advocate for Elixir.. It will have a special place on my laptop 
Exadra37
6
egze
@sasajuric great talk! Can you say a few words or point me to some discussions about what the issue is with nodes? You said in the talk that there are problems with them.
2
odemeringo
sasajuric
Author of Elixir In Action
I responded to that question on the reddit thread, here’s a copy-paste of my answer:
I feel that there are a couple of shortcomings.
First, in my opinion distributed BEAM is mostly intended to run on a network which is fast and more reliable (such as local network). While in theory it can also work on a less reliable/slower network (e.g. geographically dispersed machines connected via Internet), in practice you might experience more frequent netsplits which could cause various problems, such as worse performance or less consistency.
Another issue, which should be fixed in Erlang/OTP 22, is the fact that sending large messages via distributed BEAM might also cause netsplits. Prior to OTP 22, people usually solved this by using a side-mechanism (e.g. HTTP requests) to send large messages.
Finally, I’ve seen various reports that the practical size limit of a BEAM cluster is in the range of 50-100 nodes. The reason for this is that BEAM cluster establishes a fully connected mesh (each node maintains a TCP connection to all other nodes), so at some size this starts to cause problems. As far as I know, the OTP team is working to improve this, but as of OTP 22 it is still not done.
Most importantly, I feel that the ecosystem is lacking easy-to-use, reliable, thoroughly tested, higher-level abstractions. There are various initiatives/explorations available, such as swarm, hoarde, or lasp/partisan, but I’m currently not convinced that any of these is mature enough to be used in production. That said, I think I saw a few mentions of people using some of these libs in production, so take my statement with a grain of salt 
14
eaverdeja
For a self proclaimed “experienced backend developer” and “BEAM noob” this was an amazing talk. Thank you very much @sasajuric!!!
2
Fl4m3Ph03n1x
Incredible talk! As someone who has read your book I already knew some of the things you mentioned but I still learned a lot and really enjoyed the demo.
Also, can someone tell me where I can read more information about mix system.upgrade ? I wasn’t able to find anything 
0
derekkraan
I’m currently not convinced that any of these is mature enough to be used in production.
Challenge accepted
5
sasajuric
Author of Elixir In Action
I should note that this task is very hacky (I think I said so in the talk too), which just recompiles the two modules, copies them over, and reloads them in the running node. If you want to do live upgrades properly, then take a look at distillery guides here.
That said, the whole demo, including this hacky upgrade, is a simplified simulation of a few situations I’ve experienced in production systems. In some cases I did indeed recompile the module locally, and brought it to production in this hacky way (without the mix task though). But you really need to understand your system to know when you can do this safely, and it’s otherwise not a recommended approach for doing live upgrades.
5
otuv
I have long been skeptical about the diluted use of the word focus.
This is what it is and what it brings you.
All the stuff you need and none of that which is not relevant regarding the subject. Not even the stuff that is closely related. The result is that your brain actually get it because it has fewer bits to puzzle.
How did he fix that bug? Who cares. That is not the point.
Thank you!
0