Elm.CodeCompared.To/Elixir

Elixir will feel familiar at the data level — everything is immutable, like Elm — but effects are not fenced off: IO.puts runs mid-expression, mid-function, wherever. The discipline Elm's runtime enforces becomes a convention you keep.

The @spec line is optional documentation checked by an external tool (Dialyzer), not the compiler — nothing stops a caller passing a string until the multiplication fails at runtime. Elixir's answer to "if it compiles, it works" is different machinery: pattern matching that crashes early, and supervisors that restart what crashed.

Anything Elm can destructure in a let, Elixir destructures with = — and more: matching {:ok, value} against a tagged tuple both asserts the tag and binds the value in one stroke. If the match fails, the process crashes with a MatchError, which is Elixir's runtime version of the exhaustiveness Elm checks at compile time.

The cons cell is spelled [head | tail] rather than head :: tail, and because = matches anywhere, no case ceremony is needed when you already know the shape. IO.inspect is Elixir's Debug.toString-and-print in one call.

Elixir has no free-floating named functions: def only works inside a defmodule, and calls are Module.function(arguments) with parentheses. The one-line form def greet(name), do: "…" exists too, much like Elm keeping short functions on one line.

This is the signature Elixir idiom: the patterns that would be case branches become function heads — factorial(0) and factorial(number). The compiler does not check the clauses are exhaustive (there is no type to be exhaustive over); a value no clause matches raises a FunctionClauseError at runtime.

Two things to absorb: &(&1 * 3) is the shorthand Elm never grew, and calling a function value needs a dot — triple.(7), not triple(7). The dot marks "this name holds a function" versus "this is a module function," a distinction Elm does not have.

Calling add.(10) is an arity error, not a partially applied function — Elixir identifies functions by name and arity (add/2). The capture &add.(10, &1) builds the one-argument function Elm would have given you for free. This is the deepest habit change for an Elm developer, and it is also why Elixir's pipe passes the first argument (see the next section).

The pipelines read identically, but the mechanics differ: list |> Enum.map(function) becomes Enum.map(list, function) — subject first — while Elm's list |> List.map function works because List.map function is a curried function still waiting for its last argument. Each design fits its language: data-first suits uncurried functions, data-last suits curried ones.

Interpolation calls to_string on the result, so numbers need no String.fromInt chaperone. Elixir's concatenation operator is <> rather than ++ (which Elixir reserves for lists) — a small vocabulary swap.

The module-of-functions style is identical — String.toUpper answers to String.upcase, and both languages treat strings as UTF-8 with String.length counting graphemes, not bytes. Coming from Elm, the Elixir standard library will feel organized the way you expect.

Both are immutable singly-linked lists with the same costs: prepending is cheap, appending walks the list. Elm's :: is Elixir's [head | tail], and Elixir's ++ concatenates lists (string concatenation moved to <>).

Where Elm has List.map, Dict.map, and Array.map as separate modules, Elixir has one Enum.map for anything enumerable — here fed by the range literal 1..5. Elm's List.foldl is Enum.reduce, with the accumulator as the lambda's second argument.

The generator number <- 1..10, the filter rem(number, 2) == 0, and the do: body compress Elm's two pipeline stages into one line — the comprehension syntax Elm (following Haskell's lead but not this far) never adopted. The pipeline version works in Elixir too; the comprehension is just often preferred.

Elixir tuples wear curly braces and have no arity limit — Elm stops at three elements and steers you to records beyond that. Destructuring with = replaces Tuple.first/Tuple.second; elem/2 exists for positional access when a match is overkill.

The literal %{key => value} needs no constructor call, and a map pattern — %{"Ada" => ada_age} — pulls a value out by matching, something Dict cannot do. Maps with atom keys get the sweeter %{name: "Ada"} spelling, which structs build on next.

A struct literal %Person{…} rejects unknown keys at compile time — the closest Elixir gets to Elm's record typing — and dot access works the same. Unlike Elm records, structs carry their name at runtime, so pattern matching can dispatch on %Person{} versus some other struct.

The visual rhyme is no accident — both syntaxes descend from the same functional-record tradition. Both build a new value sharing the unchanged fields; the original is untouched, as the second print shows. The update form also raises if the key does not already exist, mirroring Elm's rule that update cannot add fields.

No type Direction exists — the atoms are just values, and nothing but convention stops a caller passing :sideways (which would crash with no matching clause). That is the trade running through this whole page: Elm declares the closed set and the compiler enforces it; Elixir matches on the open set and crashes loudly on surprises.

Same shape, different guarantees: nothing forces a function to return only :ok/:error tuples, and nothing forces the caller to handle both. In exchange, the convention needs zero declarations and composes across every library. Elm developers usually find they miss the checking more than Elixir developers expect to.

Map.get returns nil for a missing key — the honest equivalent of Nothing, minus the type that forces you to notice. The three-argument form Map.get(map, key, default) is Maybe.withDefault folded into the lookup, and || 0 works because only nil and false are falsy in Elixir. The compiler will not chase unhandled nils for you; pattern matching usually catches them one function later.

Guards are limited to a safe subset of functions (comparisons, arithmetic, type checks) so a guard can never have side effects — a small taste of Elm-style discipline inside the dynamically typed world. The same when clauses work on function heads, where multi-clause definitions make them shine.

cond evaluates each condition in order and takes the first truthy branch — Elm's else if ladder as a single expression, with true -> as the final else. Like everything in Elixir, it returns a value, so it binds directly to grade.

Each <- line must match its pattern for the chain to continue; the first non-matching value (an {:error, reason} tuple, say) becomes the result of the whole expression. It is Result.andThen without the nesting — and because it works on patterns rather than a Result type, it chains any shape of step.

The philosophy is the interesting part. Elm makes crashes impossible by proving totality at compile time. Elixir makes crashes cheap: a process that hits a bad state dies, and a supervisor restarts it clean — so idiomatic code rarely writes rescue, preferring tagged tuples for expected failure and a crash for the unexpected. Two opposite roads to reliability, both taken seriously.

receive pattern-matches on the mailbox exactly the way Elm's update matches on Msg — tagged tuples playing the role of the Msg type. The difference is scale and ownership: an Elm app has one implicit mailbox managed by the runtime; a BEAM system has millions of processes, each with its own, and you spawn them yourself.

Look at the two columns side by side: Elm's update folded over a list of messages IS Counter.loop receiving from its mailbox — new state passed to the next iteration, never mutated. The Elm Architecture is this pattern with the loop hidden in the runtime; OTP's GenServer is this pattern with the loop hidden in a library. An Elm developer already understands BEAM concurrency; they have just never been allowed to spawn a second loop.