Erlang.CodeCompared.To/Elixir

Both run on the BEAM. Erlang prints with io:format/1 and the ~n format directive for the newline; Elixir's IO.puts/1 appends the newline for you. Note that Elixir statements are separated by newlines, not terminated by . — the trailing period is a piece of Erlang punctuation you get to leave behind.

Erlang's ~p ("pretty print") directive renders any term for humans; the value to print is passed in the argument list. Elixir's IO.inspect/1 does the same and — handily — returns its argument, so you can drop it into the middle of a pipeline to peek at a value without breaking the chain.

In Erlang variables are Capitalized and bind exactly once — = is a match, not assignment. Elixir keeps the match semantics but uses lowercase names and, crucially, allows rebinding: writing x = 40 and later x = 99 is fine. It does not mutate the old value (everything is still immutable) — it just points the name at a new one.

Because Elixir lets you rebind, it needs a way to say "match against this variable's current value" — that is the pin operator ^. So ^x = 2 in Elixir behaves like a bare X = 2 in Erlang once X is bound: it asserts equality rather than rebinding. Reach for ^ whenever you want Erlang's single-assignment behaviour inside a pattern.

The {ok, Value} tagged-tuple idiom is identical on both sides — matching against {ok, Value} both asserts the shape and extracts the payload. Erlang's bare atom ok simply becomes Elixir's :ok with a leading colon.

Same concept, different spelling: an Erlang atom is a bare lowercase word (ok, error); an Elixir atom carries a leading colon (:ok). The colon exists precisely because Elixir's lowercase identifiers are variables, so atoms need a marker to tell them apart.

In both languages true and false are just atoms, and so are module names — in Erlang lists is an atom, and in Elixir List is sugar for the atom :"Elixir.List". This is why you can pass a module around as a value and call it dynamically; the "everything is a term" model is inherited straight from Erlang.

These map almost one-to-one: Erlang's div and rem operators become Elixir's div/2 and rem/2 functions, and in both languages / always produces a float (3.4). Both also give you arbitrary-precision integers for free.

This is the biggest day-one surprise. In Erlang, "abc" is a charlist — a list of integer code points — which is why the ~w ("write the raw term") directive shows [97,98,99]. (The everyday ~p directive hides this: it heuristically prints printable char lists back as "abc".) In Elixir, "abc" is a binary, a proper UTF-8 string. Elixir's charlists exist too, written ~c"abc", but are reserved for the rare Erlang API that demands them.

Where Erlang reaches for io_lib:format/2 (and often lists:flatten to tidy the resulting iolist), Elixir has Ruby-style interpolation baked into the string literal: "Hello, #{name}!". Concatenation is <> in Elixir (the binary-concatenation operator), versus ++ on Erlang charlists.

Identical linked-list model, identical cons syntax: [Head | Tail] in Erlang is [head | tail] in Elixir. Both are singly-linked lists where prepending with [x | list] is cheap and indexing into the middle is not — the instincts you built in Erlang carry over exactly.

Erlang's lists module takes the list as the last argument (lists:filter(Fun, List)); Elixir's Enum module takes the collection first, which is exactly what lets the pipe |> thread a value through a chain of transformations. The functions themselves — filter, map, foldl → reduce — are the same tools you already know.

Tuples are fixed-size, contiguous terms in both languages. The one thing to watch: Erlang's element/2 is 1-indexed (element(1, Point)), while Elixir's elem/2 is 0-indexed (elem(point, 0)). In practice you rarely index tuples at all — you pattern-match them.

Erlang maps use #{key => value} and maps:get/2; Elixir maps use %{key => value}, and when every key is an atom you get the %{name: "Ada"} shorthand plus person.name dot access. The runtime representation is the same BEAM map underneath.

Both languages update a map by producing a new one, and both distinguish "update an existing key" from "add a key". Erlang's Map#{key := Value} (with :=) requires the key to exist; Elixir's %{map | key: value} does the same and raises if the key is missing — a small guard against typos.

An Erlang -record is compile-time sugar over a tagged tuple, defined at the module level (so it cannot run in this shell-based sandbox — it is shown for contrast). Elixir's defstruct is its spiritual successor but backed by a map: you get named fields, defaults, dot access, and struct pattern matching (%User{admin: true}), all without the header-file ceremony records are famous for.

Comprehensions are one of the closest matches between the two languages. Erlang's [Expr || Generator, Filter] becomes Elixir's for generator, filter, do: expr — same generator-and-filter idea, just with keywords instead of the || and <- punctuation. Elixir's 1..5 range replaces lists:seq(1, 5).

Erlang's lists:foldl/3 is Elixir's Enum.reduce/3. The accumulator threads through the same way; the argument order of the function even matches (fun(Element, Acc) ↔ fn element, acc). Elixir also offers Enum.sum/1 and dozens of other specialised reducers so you rarely hand-roll the fold.

Nearly identical. The differences are cosmetic: Elixir uses -> and a do/end block where Erlang uses -> with clauses separated by ; and terminated by end, and Elixir drops the trailing period. The matching semantics — first clause whose pattern fits wins — are exactly the same.

Guards (when) work the same in both languages and are restricted to the same small set of side-effect-free tests. The example uses a multi-clause anonymous function on both sides; note Elixir invokes an anonymous function with a dot — sign.(-3) — the one syntactic reminder that it is a value, not a named function.

Erlang's answer to a sequence of dependent matches is nested case expressions, which drift rightward fast. Elixir's with flattens exactly that pattern: each <- clause must match to continue, and the first failure falls through to else. It is the single most welcome control-flow addition for an Erlang developer.

Erlang's fun(N) -> ... end is Elixir's fn n -> ... end, and both are called with a dot in Elixir (double.(21)) versus a plain application in Erlang (Double(21)). The dot is Elixir's visible distinction between calling a named function and calling a value that holds one.

Erlang refers to an existing function as a value with fun Module:Name/Arity. Elixir's capture operator & is the terser equivalent — &abs/1 captures the named function, and &(&1 * 2) builds a new one where &1 is the first argument. Both express the same "function as a first-class value" idea.

At the shell an Erlang recursive function is a named fun (fun Fact(...) -> ... end, clauses separated by ;). In a real module you would define fact/1 with two clauses — which is exactly what the Elixir side shows: one def per pattern, base case first. Same multi-clause, pattern-driven recursion, expressed as named functions in a module.

An Erlang module is a whole file headed by -module and an -export list (so it is display-only in this expression sandbox). Elixir's defmodule can be defined inline and needs no export list — def is public and defp is private. Module names are dotted and hierarchical (MyApp.Calculator) rather than flat atoms.

Calling into the standard library reads the same on both sides — Module:function(Args) in Erlang, Module.function(args) in Elixir. Elixir's String module is largely a friendlier, binary-oriented layer over Erlang's string and unicode modules, and you can always call the Erlang ones directly (:string.length(...)) when you want to.

The {ok, Value} / {error, Reason} convention is a shared cultural bedrock — both maps:find/2 and Map.fetch/2 return exactly these, and callers match on them instead of raising. Elixir formalises the companion convention too: a foo! function is the variant that raises, while bang-less foo returns a tagged tuple.

Erlang and Elixir share the same three-way error model — throw, error, and exit — and both catch on the class and the value (throw:Reason ↔ :throw, reason). In both communities this is the rarely-used path: the idiomatic approach is tagged tuples for expected failures and letting a process crash (to be restarted by its supervisor) for the unexpected ones.

This is the machinery both languages exist to provide, and it is the same machinery — literally the same BEAM primitives. Erlang's Pid ! Message send operator becomes Elixir's send(pid, message), and spawn, self(), and receive are identical. Anything you know about processes, mailboxes, links, and monitors transfers with zero relearning.

The "state is an argument to a tail-recursive receive loop" pattern is pure Erlang, and Elixir inherits it unchanged — the two examples are line-for-line equivalent. In real code both languages wrap this in OTP's gen_server/GenServer, which is the same behaviour under both names.

OTP behaviours are the same contract in both languages — gen_server is GenServer, with identical callbacks and return shapes. Elixir's use GenServer injects sensible defaults and @impl true documents which callbacks you are implementing, but the underlying behaviour is Erlang's. (Module-level, so display-only here.)

Erlang dispatches on data only by hand-written is_* guards or tagged tuples. Elixir adds protocols — defimpl String.Chars, for: Money teaches IO.puts and interpolation how to render a Money value, the way defining a method would in an OO language. It is genuinely new capability on top of the BEAM, not just nicer syntax.

Erlang makes you nest calls inside-out, reading right-to-left and inner-to-outer. Elixir's pipe |> feeds each result as the first argument of the next call, so the code reads top-to-bottom in the order it executes. For a pipeline of lists/Enum transformations this is the single biggest readability win Elixir offers.

Elixir ships one blessed build tool, Mix, covering project creation, dependencies (via Hex), compilation, tests (ExUnit), and releases — where the Erlang world historically stitched together rebar3, relx, and assorted scripts. Both draw from the same Hex package registry, so an Erlang library is one {:dep, "~> x"} line away in an Elixir project.

The reflex to fix first: in Elixir "abc" is a UTF-8 binary, not a list of code points. When an Erlang API insists on a charlist, write ~c"abc" or call String.to_charlist/1. Most of the time you will simply stop thinking about charlists — binaries are the default and the right choice.

Coming from single-assignment Erlang, Elixir's rebinding can look like mutation — it is not. Each x = ... creates a fresh binding of an immutable value; anything that captured the old x (a closure, a spawned process) still sees the old value. You gain the convenience of reusing a name without giving up any of Erlang's immutability guarantees.

A few operators are respelled. Erlang's exact-equality =:= and =/= become Elixir's === and !==; the short-circuit andalso/orelse become and/or (which, like Erlang's, require real booleans), while &&/|| work on any value with nil/false as falsy. List concatenation stays ++, but string concatenation is <>, not ++.