Elixir/Erlang Hot Swapping Code (2016)
Hot code swapping on the Erlang/Elixir BEAM VM is praised as a powerful way to achieve near-zero downtime in long‑running, stateful systems—from telecoms and healthcare to niche uses like live‑updating drones and music tools. Commenters note that while the VM and OTP provide sophisticated mechanisms (e.g., `code_change` in GenServers), making upgrades safe in production is complex and often not worth the risk for typical web apps, which instead favor container-based blue‑green deployments. Similar capabilities exist in platforms like Common Lisp and some game engines via data‑driven hotfixes, but many engineers conclude that designing for simple restarts and stable APIs is usually more practical than embracing full hot code reloading.
Role and Reliability of Hot Swapping on the BEAM
- Erlang/Elixir’s hot code loading is widely acknowledged as real and powerful, designed for high‑uptime, long‑running, stateful systems (e.g., telecom, healthcare, persistent connections).
- Several commenters stress Erlang’s overall reliability focus (fault tolerance, supervisors, “let it crash”) but distinguish that from the reliability of hot swapping itself, which they see as more fragile.
- Many argue that for most web apps, simpler restart‑based or blue‑green/container deployments are adequate and safer.
Practical Use vs. Complexity
- Some teams report heavy production use: e.g., ~99% of deployments via hot reload with almost no restarts, or frequent zero‑disruption Elixir patches; others only use it in emergencies while CI/CD pipelines run.
- Others found that “zero downtime via hot reload” required large extra effort: explicit state migration code (
code_change), careful supervision design, and thorough testing. - Complexity points raised:
- Two versions of a module can coexist; internal vs fully qualified calls can hit different versions.
- State schemas and message formats must be forward/backward compatible during transitions.
- Bidirectional migrations between specific versions are needed; bugs here can kill processes or cause restart loops.
Distributed Systems and Atomicity
- Commenters note you cannot achieve truly atomic hot upgrades across nodes, or even fully within one VM; schedulers and processes see new code at slightly different times.
- Recommended patterns focus on progressive rollout and compatibility steps: deploy code that handles old+new requests, then update clients/peers, then remove legacy paths.
Comparisons to Other Ecosystems
- PHP “edit in prod” nostalgia surfaces; acknowledged as workable for small, simple systems and teams, but unsafe at scale.
- Many prefer container‑level rolling/blue‑green deployments, arguing they already require resilience to instance churn. Others counter that some domains (telephony, MMOs, drones, interactive music systems) truly benefit from in‑place state‑preserving updates.
- Similar capabilities are mentioned in Common Lisp, Smalltalk, some Lisps/Clojure workflows, JVM hot reload, MUD engines, and game servers using data‑ or script‑driven hotfixes.
Community Trajectory
- In Elixir, hot‑upgrade enthusiasm (e.g., older Distillery/relup workflows) has cooled; newer tooling (mix releases) downplays it due to complexity.
- Consensus: a powerful, niche feature—critical when you truly need continuous, stateful uptime, but overkill and risky for most everyday services.