The Soul of Erlang and Elixir • Sasa Juric • GOTO 2019
GOTO Conferences16 HN recommenders · 2019–2024
384K views · talk · evergreen · Uploaded 2019-05-22
Sasa Juric explains what makes Erlang and Elixir suited to server-side systems, focusing on the BEAM concurrency model rather than syntax or ecosystem. He demonstrates processes, supervision, and fault tolerance.
It is HN's favorite pitch for Elixir and the BEAM, credited with convincing many people to adopt them.
53:22Ruby Conf 12 - Y Not- Adventures in Functional Programming by Jim Weirich
Confreaks
1:01:39"Simple Made Easy" - Rich Hickey (2011)
Strange Loop Conference
25:06"Making Impossible States Impossible" by Richard Feldman
elm-conf
1:31:06William Byrd on "The Most Beautiful Program Ever Written" [PWL NYC]
PapersWeLove
40:20"Testing Distributed Systems w/ Deterministic Simulation" by Will Wilson
Strange Loop Conference
31:44The Value of Values with Rich Hickey
InfoQ
46:09Why Isn't Functional Programming the Norm? – Richard Feldman
Metosin
1:03:29Maybe Not - Rich Hickey
ClojureTV
20 comments from Hacker News
I feel like this talk does a great job of answering that question - The Soul of Erlang and Elixir by Saša Jurić ( [VIDEO] )
> explore Go or Elixir I have never seen a good argument for using golang for business logic. If you are writing the actual server then sure, use golang. If you are writing some high-speed network interconnect, use golang. Some crazy caching system, sure use golang. The public WS endpoint, use golang. But if you need to access a DB with golang for anything more than, like, a session token, then you made the wrong choice and you need to go back and re-assess. Elixir is in the "germination phase" and I predict massive adoption in the next 5 years. It is a truly excellent platform, every fintech company I know at least has their toe in the water. Everyone I show this video to [1] just says "well, shit." [1] [VIDEO]
The Soul of Erlang and Elixir, by Sasa Juric video: [VIDEO] HN discussion: [LINK] Preventing the Collapse of Civilization, by Jonathan Blow video: [LINK] HN discussion: [LINK]
I replaced a python/uwsgi stateless stack with an elixir stateful system. Flipped it over and it worked flawlessly, and hasn't died once in several months of operation. Latencies are way down, and operation of it is simpler. Full deploy to the head node is one command, not an ansible script. I guess part of it is that I'm lazy and haven't learned supervisor strategies like kubernetes (the place I work doesn't deploy kubernetes anyways) This video is instrumental in giving me the confidence to do what I did: [VIDEO]
> [and particularly, videos] go out of their way to discuss how process management and IPC communication works After watching a bunch of videos on BEAM/erlang/elixir I came to the conclusion that it isn't a platform for computation, it's a platform for communication. The best video (by far) was The Soul of Erlang and Elixir • Saša Jurić [VIDEO] Two shallow benchmarks: [LINK] [LINK] (phoenix is at 175)
I would find a list of good talks much more useful. For example, 'The Soul of Erlang and Elixir' talk by Sasa Juric [1] really sold me on Elixir. [1] [VIDEO]
If you're interested in Erlang/Elixir, you might want to watch this video: [VIDEO] (GOTO 2019 • The Soul of Erlang and Elixir • Saša Jurić) It shows off the power of the BEAM VM -- and kind of makes you stand back and go "whoa.. how do they do that?"
That sounds like one of Saša Jurić's talks: GOTO 2019 • The Soul of Erlang and Elixir • Saša Jurić [VIDEO] [LINK] (also from Saša Jurić's book)
Almost no business application is written for performance at raw request speed. What Elixir brings is far more the that. Watch this if you want to understand why so many people fall in love with it. [VIDEO]
I feel like the post brushes past the best parts to line the learnings up with container concepts and k8s. The Erlang application/service should not be crashing. A crash happens in a process in a tree of supervisors and each supervisor can have strategies to recover if its child supervisor/process fails. Supervision in Erlang/BEAM is not just microservice infrastructure with restarts. It handles many types of failures knside the application and only if all mitigations repeatedly fail would we crash all the way up to the trunk of the tree and crash the application. If that happens the Erlang heart should be starting it back up or otherwise invoking some last-ditch mitigation. Or if you run Erlang in a container, that's when you'd have your infrastructural stuff restart it. Supervision in Erlang is much more granular and not about restarting the entire service. I think this gives a good view of Erlang resiliency: [VIDEO]
Love this! Bouncing between python and elixir projects, I have been wanting this for some time. I would love to see stress/performance testing results for this. I may take a stab at it myself; something like this simple, venerable demo from Saša Jurić[0] (starting around 8 mins) [0] [VIDEO]
There are entire languages built upon this model! Anything using the BEAM is a great example. Erlang, Elixir, Gleam, etc. The runtime acts as an event loop and if a specific program is hogging too much time on the CPU, it will get paused and thrown to the back of the execution stack. This is all transparent (relatively) for the developer. Here’s a video if you want to see an example: [VIDEO]
I can highly recommend Elixir in Action, 2nd ed. This talk by the same author is also a good introduction in video format: [VIDEO]
No, they're equivalent. It makes no difference whether I calculate in the current process, spawned a process, started a process via the Supervisor, Task.async, or what not. They are all equivalent in the sense that they use BEAM processes. An Elixir, Erlang, or any other developer using the BEAM VM (or at the very least myself since I don't want to generalize) doesn't make a semantic distinction between spawn and Task.async/3 because there is none. The significant differentiation is whether or not the caller is expecting a returned value, if not then Task.start_link can be used instead. I don't need to worry about function colouring because there is none. I also don't need to worry about async vs Task.run like in C# because in Elixir there is none. To be asynchronous in Elixir/Erlang/etc... is to be synchronous. To equate it to modern backends, we basically have a microservice but every service can directly call each other. I think I also might have been talking around you a bit, the BEAM VM sets itself apart from C#'s async/await or the TPL due to its implementation of the actor model. This video by Sasa Juric can explain better than I can the general overview of the BEAM: [1]. But a rough tl;dr, a BEAM process is to the BEAM, what an OS process is to the OS. We don't define a main function as the process supervisor in BEAM spawns processes we define instead and those are our "entrypoints." [1] [VIDEO]
Runs on the Erlang Virtual Machine, also known as the BEAM. Erlang was built for scalability and fault tolerance of telephone switches by Ericsson in the 80's. Give this a watch, "The Soul of Erlang and Elixir". Covers a lot of what's nice about the underlying platform. [VIDEO]
I recommend the talk The Soul of Erlang and Elixir by Sasa Juric. [VIDEO] The thing that Erlang amd Elixir have different is the BEAM VM and its support of concurrent processes at the VM level. So there are some things that they can do that Akka can't. For example, the schedule is preemptive and keeps processes alive even though there may be rogue processes pegging the CPU.
Sasa Juric makes this point in 'Elixir In Action' and some of his talks, where in other languages you need to pull in these other technologies near the start, whereas in Elixir you can use the built-in primitives until you start running into scaling problems. - [VIDEO]
From the author of this post, here's one of the best demos of Elixir, Erlang and modern distributed computing in general: "The Soul of Erlang and Elixir • Saša Jurić • GOTO 2019" - [VIDEO] When you feel sufficiently amazed by this demo, I also recommend the Elixir in Action book, by this same author, to get started with this incredible ecosystem and paradigm. --- It's hard to imagine a better platform than Erlang's for writing distributed and networked systems of any kind. I fell in love with Elixir in 2016 and have been using it full time since, first adopting as CTO in my previous company, now powering my new solo business. It's such a good language, with great community and stewardship, running on a rock solid platform that's so advanced compared to most popular languages today. Erlang was created 38 years ago, and it's good to see the ideas of Armstrong, Virding and Williams to be vindicated today. They simply were too far ahead of their time.
Picking Erlang for number crunching is a Bad Idea™. You can use NIFs in C or Rust though for expensive computations. If you play to its' strengths it outshines the competition eg WhatsApp and 99.999999999% of uptime (that is a few seconds of downtime per year). Horses for courses. [Edit] Zero snark intended. [VIDEO]
Check out this presentation :) "The Soul of Erlang and Elixir by Sasa Juric" Really one of the best presentations to show what you may get out of adopting Elixir. [VIDEO]