Thank you all for the positive feedback! It makes me very happy to learn you enjoyed it
@sasajuric any chance you provide the related example code from the presentation in a repo?
When I first introduced Elixir to the company I am part of about 1.5yrs ago a big part of my research into solutions/languages was around what made sense for our engineering team from a team size, company need, where we want to be in 4yrs perspective. The last part of your presentation really hit at what I perceived as huge benefits then and now.
Thanks for all the contributions you give to the community.
Yeah, the demo code would be nice. I liked the stats page with the live charts.
I was secretive about it because I don’t think the code is pretty, so I wouldn’t suggest it as an inspiration on how to write production Elixir
That said, in case you want to take a look at the code, the repo is already publicly available here. The main site is in the
Just say it’s not the most pretty and accept PRs
Nice and dense talk @sasajuric, seeing how one debugs a live BEAM system is such a pleasure every time!
PS. I noticed that in your vscode that you didn’t have coloring for atoms. Perhaps it was a new installation just for your demo, but in case you or anyone else cares how to add those I’ll just point you to this gist https://gist.github.com/bottlenecked/50bd2c2c655a8de8c7b250751dd4d7dd (make sure you have an Elixir plugin like vscode-elixir-ls installed and then add the extra configuration to your settings.json)
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
@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.
Bravo ! And Big thank you !
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
For a self proclaimed “experienced backend developer” and “BEAM noob” this was an amazing talk. Thank you very much @sasajuric!!!
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
I’m currently not convinced that any of these is mature enough to be used in production.
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.
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.
Just wanted to stop lurking for a moment and add to the chorus – incredible talk, well done.
Superb talk and demo Saša, I sent to all my friends which I’d like to infect with Erlang/Elixir.
Hi, I the dashboard in demo and the other modules are available on GH? or can you please make them available? its a great source to learn
Sorry found it https://github.com/sasa1977/demo_system thanks