Erlang's not about lightweight processes and message passing (2023)

Original Article ↗ Hacker News Discussion ↗

What makes Erlang/BEAM special?

  • Many argue the power is in the combination of features, not any single one:
    • Lightweight isolated processes (millions per node), preemptive scheduler, message passing, pattern-matching receives.
    • Supervision trees and “let it crash” design for partial recovery / microreboots.
    • Hot code + state upgrades, distributed nodes, OTP behaviours, Mnesia, built-in telemetry and tooling.
  • Some push back on the article’s emphasis on behaviours/interfaces as the key idea: behaviours are useful, but depend on the VM’s process model and fault-handling; taken alone they’re not the main differentiator.
  • Others stress the scheduler: preemption and per-process heaps mean a bad process can’t easily take down the system, unlike typical async runtimes.

Comparisons: OS processes, k8s, actors, async, other stacks

  • Replacing BEAM pieces with OS processes, Kubernetes, Java threads, or hot-reload mechanisms is seen as possible in theory but painful in practice; Erlang’s value is having these as a coherent, in-language stack.
  • Actor-like libraries (Akka, Orleans, etc.) and CSP-style channels are discussed; consensus: the model isn’t unique to Erlang, but BEAM’s isolation, supervision, and distribution are unusually integrated.
  • Long subthread comparing BEAM to Node.js and general async runtimes:
    • Critiques: lack of preemption, orphaned async tasks, lost errors, hard observability and profiling.
    • BEAM’s per-process mailboxes, crash semantics, and introspection are seen as easier to reason about under load.
    • Counter-claims note that modern async in .NET/Rust is highly optimized and that some Erlang fans overstate BEAM’s technical lead.

State, durability, and limits

  • Erlang processes lose in-memory state on crash; durable state must be handled via Mnesia or external systems, with explicit queue-ack and retry patterns.
  • Mnesia is described as powerful but tricky to scale; naive “one big Erlang cluster” designs can hit memory and scaling ceilings.

Adoption, ecosystem, and business concerns

  • Reasons cited for limited adoption: alien syntax, need to internalize OTP’s crash/restart mindset, small hiring pool, lack of a big-corporate sponsor, and perception of only incremental (not 10x) gains.
  • Others argue Erlang/Elixir can significantly reduce engineering effort and operational pain, but these advantages show up later in a product’s life, not at adoption time.

History and misc

  • The “Erlang was banned” story is clarified: there was a late‑90s ban on new use inside Ericsson for business/strategy reasons; it led to open-sourcing, later relaxation of the ban, and continued internal use.
  • Side discussions cover syntax preferences (Erlang vs Elixir vs Gleam), aging BEAM internals/tooling, and experimental projects like a Node-RED-style FBP frontend over an Erlang backend.