The Soul of Erlang and Elixir - Saša Jurić - GOTO 2019

Learning Resources Talks
,
1

Whether you’re developing a small web site or a large-scale distributed system, Erlang and Elixir are great tools for building server-side systems. Both languages can help you start quickly and deal with highly complex problems at a large scale.

This talk aims to explain what makes Erlang and Elixir suitable for such tasks. We’ll look past the syntax and the ecosystem, focusing instead on the concurrency model of these languages.

Combining a bit of high-level theory and a couple of demos, we’ll examine some important properties of Erlang/Elixir concurrency, with a special emphasis on why these properties are very relevant when building highly available systems.

The talk targets experienced backend developers, but no knowledge of Erlang or Elixir is required. You will walk away from the talk with a better understanding of what distinguishes Erlang and Elixir from the rest of the pack, and why these languages are very compelling choices to power your next software system.

74 Likes
2

I am only at 16 minutes right now but I am starting to send it to everyone I know. If that doesn’t convince people from BEAM/Erlang/Elixir, I don’t know what will. Thanks for the talk @sasajuric !

5 Likes
3

awesome talk, great work @sasajuric !

An excellent primer/intro to the BEAM and it’s properties…

2 Likes
4

I greatly enjoyed the talk, thank you @sasajuric

1 Like
5

I’ve watched a bunch of videos on this topic and that was the clearest and most concrete example I’ve seen yet. I was actually disappointed the video ended, it was that good. I like how it was just packed with actual examples, with little to no fluff, and the presenter talks fast and to the point (in a good way). It feels like you got 3 hours of information in ~40 minutes.

4 Likes
6

Thank you all for the positive feedback! It makes me very happy to learn you enjoyed it :slight_smile:

48 Likes
7

@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.

2 Likes
8

Yeah, the demo code would be nice. I liked the stats page with the live charts.

9

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 :smiley:

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 example_system folder.

12 Likes
10

Just say it’s not the most pretty and accept PRs :slight_smile:

1 Like
11

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)

12

Many, many, many thanks to have shared this code :smiley:

Screenshot%20from%202019-05-23%2023-04-02
Screenshot%20from%202019-05-23%2023-04-022279×1096 124 KB

This is so, so, so cool :sunglasses:

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 :wink:

5 Likes
13

@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 Likes
14

Bravo ! And Big thank you !

1 Like
15

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 :slight_smile:

14 Likes
16

For a self proclaimed “experienced backend developer” and “BEAM noob” this was an amazing talk. Thank you very much @sasajuric!!!

2 Likes
17

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 :frowning_face:

18
1 Like
19

I’m currently not convinced that any of these is mature enough to be used in production.

Challenge accepted :wink:

5 Likes
20

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 Likes