Do You Really Need Processes? by Brian Underwood | Code BEAM Europe 2023

✨This talk was recorded at Code BEAM Europe 2023. If you're curious about our upcoming event, check codebeameurope... ✨
Abstract:
You probably know that the power of the BEAM comes from processes which operate concurrently and supervisors which, in many cases, allow service to continue. Maybe you’ve thought that your application needs to use more GenServers and Supervisors to become the best that it can be. But then again, maybe everything is fine.
In this talk, Brian will present a demo of a ride-sharing application which he created to understand what is possible with a standard Phoenix + PostgreSQL application. He will explore what performance and resiliency gains can (or can’t) be achieved by designing various process and supervision architectures using an external database, process state, ETS tables, and combinations therein.
Let's keep in touch! Follow us on:
💥 Twitter: / codebeamio
💥 Facebook: / codesyncglobal
💥 Linkedin: / code-sync
💥 Mastodon: genserver.soci...

[@stevenhe3462]

Hi. I did not get the point. :(

[@BrianUnderwoodCodes]

Yeah, I can maybe understand 😅 I spent a while preparing this talk and I feel like I made a lot of progress from where it started, but after I gave it I also got a number of insights from talking with different people at CodeBEAM. I’ve been thinking about writing a blog post or maybe giving the talk again with some of those insights in mind.
But basically the point is: In Erlang there’s an expectation that you will be using processes/genservers/supervisors all of the time, but in Elixir that doesn’t happen so much, primarily because Elixir-ists generally work at a higher level and leave libraries to take advantage of the power of BEAM concepts and abstract away things which aren’t relevant to their applications (to be clear, I still thing Elixirists should *definitely* understand how processes/supervisors work, but they should also know that they probably won’t need them as often as they may be led to believe).
It feels a bit like how, early in Elixir’s life, I read many blog posts talking about hot-code-reloading and how it made Elixir a game changer. But after a while the community came to a conclusion of “hot code reloading is useful if you *really* need it for specific cases, but most of the time it doesn’t fit with the most common ‘modern’ approach of deployments going out many times a day/week”
The other main point is that, because of:
* frequent deploys
* eschewing of hot-code-reloading
* the expectation that you’re going to have an external database
…processes can’t be/aren’t used in Elixir for long-term state in the same way that it seems like they are in Erlang. Though after my talk at least one person suggested that Erlang applications rarely depend on process / memory state either, which was a bit of a surprise from the “story” that people tend to tell of Erlang (usually revolving around the original story of using Erlang for telephone switches)
There was also some stuff in there exploring storing state (in GenServers, ETS, via PartitionSupervisor, etc…) that maybe muddies the point, TBH… 😅