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.

Rule: if two pieces of code never run at the same time and share no mutable state, they are functions, not processes.

The functional core

Match in function heads, not with if — branches become exhaustive and self-documenting, and a non-match crashes loudly instead of silently falling through.

# Bad - imperative branching, easy to miss a case
def area(shape) do
  if shape.type == :circle do
    :math.pi() * shape.r * shape.r
  else
    shape.w * shape.h
  end
end

# Good - one clause per shape, unmatched input crashes (which a supervisor handles)
def area(%Circle{r: r}), do: :math.pi() * r * r
def area(%Rect{w: w, h: h}), do: w * h

Return tagged tuples {:ok, value} / {:error, reason} — the caller pattern-matches the outcome; this is the protocol the whole ecosystem speaks.

# Good
def fetch(id) do
  case Repo.get(id) do
    nil -> {:error, :not_found}
    record -> {:ok, record}
  end
end

Chain fallible steps with with — it reads as the happy path and short-circuits on the first non-match, no nested case pyramids.

# Good - any step returning a non-{:ok, _} falls straight to else
with {:ok, user} <- fetch_user(id),
     {:ok, acct} <- fetch_account(user),
     :ok <- authorize(acct) do
  {:ok, acct}
else
  {:error, reason} -> {:error, reason}
end

Use guards to constrain clauses (when is_integer(n) and n > 0) — keeps validation declarative and lets the compiler reason about types.

Pipe left-to-right for data flowing through transforms — data |> step1() |> step2(). Do not pipe just to avoid an intermediate variable; if a step needs the value in a non-first argument, name it.

There is no mutation. Rebinding x = f(x) makes a new binding; data you passed elsewhere is unchanged. Stop reaching for mutable accumulators — use Enum.reduce/3, comprehensions, or recursion.

Processes and message passing

Raw spawn/send/receive exists and is fine for a throwaway fire-and-forget where supervision genuinely does not matter, but in production you almost always want an OTP behaviour (GenServer/Task/Agent) so you get child_spec, supervision, and shutdown handling for free.

• Link (spawn_link) couples lifetimes: if one dies abnormally, the other gets an exit signal. This is how supervision works.
• Monitor (Process.monitor/1) is one-directional and non-fatal: you get a {:DOWN, ...} message but you do not die. Use it when you care that something died but should survive it.

GenServer

Split the client API (runs in the caller) from the server callbacks (run in the GenServer process). Callers never touch state directly.

defmodule Counter do
  use GenServer

  # --- Client API (caller's process) ---
  def start_link(opts) do
    GenServer.start_link(__MODULE__, opts[:start] || 0, name: opts[:name] || __MODULE__)
  end

  @spec increment(GenServer.server()) :: :ok
  def increment(server \\ __MODULE__), do: GenServer.cast(server, :increment)

  @spec value(GenServer.server()) :: integer()
  def value(server \\ __MODULE__), do: GenServer.call(server, :value)

  # --- Server callbacks (GenServer's process) ---
  @impl true
  def init(start), do: {:ok, start, {:continue, :warm_up}}

  @impl true
  def handle_continue(:warm_up, state) do
    # heavy/slow init goes here, AFTER start_link has returned
    {:noreply, state}
  end

  @impl true
  def handle_cast(:increment, count), do: {:noreply, count + 1}

  @impl true
  def handle_call(:value, _from, count), do: {:reply, count, count}
end

• Never block in init/1. start_link blocks until init returns, so a slow init stalls the whole supervision tree boot. Return {:ok, state, {:continue, term}} and do the work in handle_continue/2.
• use GenServer auto-defines child_spec/1 — you rarely write one by hand; override only to change :restart or :shutdown.
• call is synchronous (with a 5s default timeout), cast is fire-and-forget. Use call when the caller needs the result or backpressure; cast when it does not. A flood of casts with no backpressure is the classic mailbox-growth bug — timeouts and backpressure recipes in references/otp-patterns.md.
• Name via Registry, not a global atom, when you have many dynamic instances — atoms are never garbage-collected (see anti-patterns).