The Soul of Erlang and Elixir • Sasa Juric • GOTO 2019 on HackerTube: recommended by 16 Hacker News commenters across 14 separate months, 2019–2024.
talk · intermediate · evergreen
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.
“Watch this if you want to understand why so many people fall in love with it.”
20 Hacker News comments link this video. Each one links back to its thread.
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. ▶ this video
in “Two million checkboxes (written in Elixir)” · View on HN
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" - ▶ this 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.
in “Why Elixir (2014)” · View on HN
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. ▶ this video
in “An Elixir adoption success story” · View on HN
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] ▶ this video
in “YouTube Channels to Level Up Your Programming Skills” · View on HN
> [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ć ▶ this video Two shallow benchmarks: [link] [link] (phoenix is at 175)
in “Optimising for Concurrency: Comparing the BEAM and JVM virtual machines” · View on HN
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: ▶ this video
in “Crystal 0.33” · View on HN
> 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] ▶ this video
in “We 30x'd our Node parallelism” · View on HN
I recommend the talk The Soul of Erlang and Elixir by Sasa Juric. ▶ this 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.
in “Erlang/OTP 26 Highlights” · View on HN
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. ▶ this video
in “Show HN: Supavisor – a Postgres connection pooler written in Elixir” · View on HN
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] ▶ this video
in “How Async/Await Works in C#” · View on HN
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: ▶ this video
in “Queues Should Be Empty” · View on HN
I can highly recommend Elixir in Action, 2nd ed. This talk by the same author is also a good introduction in video format: ▶ this video
in “Millions of Active WebSockets with Node.js” · View on HN
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: ▶ this video
in “What I learned from Erlang about resiliency in systems design (2019)” · View on HN
If you're interested in Erlang/Elixir, you might want to watch this video: ▶ this 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?"
in “Elixir 1.11” · View on HN
The Soul of Erlang and Elixir, by Sasa Juric video: ▶ this video HN discussion: [link] Preventing the Collapse of Civilization, by Jonathan Blow video: [link] HN discussion: [link]
in “Ask HN: Best Talks of 2019?” · View on HN
I feel like this talk does a great job of answering that question - The Soul of Erlang and Elixir by Saša Jurić ( ▶ this video )
in “An Interview with Jose Valim, Creator of Elixir” · View on HN
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. ▶ this video
in “Exploring Gleam, a type-safe language on the BEAM” · View on HN
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. - ▶ this video
in “Unpacking Elixir: Concurrency” · View on HN
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] ▶ this video
in “Show HN: TriOTP, the OTP Framework for Python Trio” · View on HN
That sounds like one of Saša Jurić's talks: GOTO 2019 • The Soul of Erlang and Elixir • Saša Jurić ▶ this video [link] (also from Saša Jurić's book)
in “Learning Ruby: Things I Like, Things I Miss from Python” · View on HN