elixir
Elixir
You are writing Elixir on the BEAM. The runtime gives you cheap isolated processes, preemptive scheduling, and supervision. The single mental shift that separates idiomatic Elixir from ported imperative code: let it crash and supervise it, do not defend every call. A process that hits an impossible state should die and be restarted clean by its supervisor — that is more correct than a try/rescue that limps on with corrupt state.
Default to pure functions. Most of your code is data transformation and needs no process at all. Reach for a process only when you need state, concurrency, or fault isolation. Target Elixir v1.19.5 (stable, requires Erlang/OTP 28.1+) or v1.20-rc (full type inference, OTP 27+/29). Use the modern stdlib: built-in JSON, set-theoretic type warnings, mix format.
Decision: do you even need a process?
A process is not "an object": spawning one to hold a value you could pass as an argument is the most common beginner mistake, and it adds a serialization bottleneck and a failure mode for nothing.
| Situation | Use | Why |
|---|---|---|
| Pure transform of input -> output | plain function / module | No state, no concurrency: a process only adds overhead and a mailbox |
| Hold mutable state behind an API | GenServer (or Agent for trivial state) |
Serializes access, owns a lifecycle, supervisable |
| Run N independent jobs concurrently | Task.async_stream / Task.Supervisor |
Bounded fan-out, results collected, crashes isolated |
| Isolate a risky/external boundary | a supervised process | A crash there restarts clean without taking down callers |
| Shared read-heavy cache | :ets table |
Concurrent lock-free reads, no single-process bottleneck |
Rule: if two pieces of code never run at the same time and share no mutable state, they are functions, not processes.