The Soul of Erlang and Elixir • Saša Jurić

  • Elixir (really the BEAM VM) uses processes (not OS processes) as a unit of work.
    • A process is completely isolated (no shared memory), and can only communicate with other processes via message-passing.
    • A single instance can support millions of processes, so they’re fairly lightweight.
  • Schedulers are are mapped 1:1 with OS threads, and are responsible for scheduling processes.
    • Fairness (at least in the default configuration) is prioritized, so a single errant process can’t stop others from progressing, even on a single scheduler.
    • I assume there’s a way to disable/customize this for “hot path”-style code if necessary.
  • Splitting logic into processes helps both for fault and latency tolerance.
    • The demo sets up a Connection process for an open WebSocket; this process spawns other Computation processes for actual units of work. Benefits to this style:
      • You can maintain a long-running connection to the server and still have it process multiple units of work in parallel.
      • A single computation that’s taking too long (or even spinning infinitely) doesn’t stop you from running other units of computation.
  • The live demos were great, and used Phoenix LiveView to render fairly rich UI without writing any JS.
    • I don’t think that LiveView is doing anything that can’t be replicated elsewhere; definitely want to give this a shot when building up readysetlog.
    • htmx is another interesting tool in this area.
  • BEAM is very operable. You can shell into a running BEAM instance (the shell becomes one more of many processes) and perform diagnostics.
  • The main argument was that Erlang/Elixir+BEAM is a much more solid choice to start off with than Rails.
    • I’m inclined to agree; I don’t see these benefits being particularly useful to a mature system, but this sounds a lot better than a Rails MVP, for example.
    • Making a system fault tolerant (a long /errant computation can’t stop other users of your system from making progress) is a lot more involved in other stacks.
    • This slide explains this a bit more succinctly:
    • I’m not entirely sure how Erlang is a replacement for an actual database (under “Persistable Data”, though) 🤔
  • BEAM can operate in cluster mode, where message-passing can transparently occur between physical machines.
    • This is problematic in practice for many reasons, but is an option.
  • Much of this talk was a live demo (which was great!)
Edit