Erlang.CodeCompared.To/OCaml

Erlang prints with io:format/1 and the ~n directive for the newline. OCaml has no single required entry point at all — a source file is a sequence of top-level bindings evaluated in order, and let () = ... is simply a binding whose left side is the unit pattern, run purely for its side effect.

Erlang's ~p ("pretty print") directive renders any term for humans, with no derivation step required. OCaml has no universal pretty-printer built into the language itself — Printf.printf requires format specifiers matched to concrete types, so printing a structured value like an option-wrapped list means writing the formatting logic by hand (or reaching for a library like Format/Fmt with derived printers), a real ergonomic gap from Erlang's ~p.

Erlang has no compile-time type checking at all — Add("two", 3) would compile fine and only fail when that exact line executes. OCaml's inferred type int -> int -> int means add "two" 3 is rejected before the program ever runs, caught by the compiler rather than discovered in production.

OCaml rarely needs the explicit annotations a Haskell or Rust example might show — its Hindley-Milner inference deduces double : int -> int from how double is used, the same way Erlang never needed a type for Double at all. The difference: once OCaml infers a type, it locks it in and enforces it everywhere the function is called.

OCaml's match expression and Erlang's function clauses are close enough to read as dialects of the same idea: patterns tried top-to-bottom, a guard attached to a specific pattern (both spell it when — see the dedicated Guards section), and a wildcard _ catch-all.

Both languages destructure a tuple directly in a binding. Erlang tuples are untyped and any arity; OCaml tuples like bool * int are typed by position, so a mismatched destructure is caught at compile time instead of failing on an unlucky input at runtime.

This is a genuine safety upgrade. An Erlang case missing a clause only reveals the gap when a real input finally hits it — a {case_clause, Value} crash in production. OCaml's compiler statically analyzes whether a match covers every possibility and emits a warning (elevated to an error under strict settings) for an incomplete one, catching the exact bug Erlang can only discover at runtime.

This is one of the closest single-keyword matches on the whole site: Erlang's when Condition after a clause head and OCaml's when condition after a match pattern are literally the same English word, doing the same job — attaching an extra boolean condition to a pattern that must also hold for that branch to match.

Both read top-to-bottom as a chain of "if this, then that; otherwise keep checking" — Erlang guards attached to separate function clauses, OCaml guards attached to separate match arms. The visual rhythm is nearly identical between the two.

Erlang models "one of several shapes" as differently-tagged tuples, distinguished by their first element and arity at match time. OCaml's type shape = Circle of float | Rectangle of float * float formalizes exactly this pattern as a genuine, closed variant type — the compiler knows every possible case, and a match that misses one is a compile-time warning, not a runtime surprise.

An Erlang atom like ok is an unstructured constant from a global, unbounded namespace of possible atoms. OCaml's type status = Ok | Failed gives the same "one fixed named value" idea, but scoped and typed — a status can only ever be Ok or Failed, never an unrelated value from elsewhere in the program that happens to share the same name.

Erlang's -record(point, {x, y}). desugars to a tagged tuple at compile time — a naming convenience only, indistinguishable at runtime from any other tuple of the same shape. OCaml's type point = { x : int; y : int } is a genuinely distinct type with structural equality and immutability built in, and — unlike Erlang — the compiler will never let a point be confused with an unrelated two-field record.

Since neither an Erlang tuple nor an OCaml record can be mutated in place by default, "changing" one field always means producing a new value. OCaml's { point with y = 99 } copy-and-update syntax does this in one expression, copying every other field automatically — Erlang has no equivalent shorthand at expression level, so the same operation means rebuilding the whole tuple by hand.

Erlang's convention of returning {ok, Value} on success and a bare error/false on failure is exactly what OCaml's built-in option formalizes: Some value is {ok, Value}, and None is the failure case. List.assoc_opt already returns an option, baking the convention into the standard library rather than something built by hand.

Where option only says "did it work," OCaml's result type carries a reason on failure — Error reason corresponds directly to Erlang's {error, Reason}, and Ok value corresponds to {ok, Value}. OCaml even reuses the bare word Ok, one of the closest naming matches of any language in this comparison.

Nothing in Erlang forces you to handle the failure branch — skipping it just defers the crash until a bad input eventually reaches that assumption. Treating an OCaml (int, string) result as if it were a bare int is a type error the compiler catches immediately; matching both Ok and Error is the idiomatic way to satisfy it.

Both languages model lists as singly-linked cons cells. Erlang spells the pattern [Head | Tail]; OCaml spells it head :: tail, the same :: cons operator OCaml lists are built from. OCaml lists must be homogeneous (one element type throughout); Erlang lists happily mix atoms, numbers, and tuples.

Both languages call these map and filter, with a near-identical argument order: (function, list) in both lists:map/2 and OCaml's List.map. This is one of the closer standard-library vocabulary matches across the whole comparison.

Erlang's lists:foldl/3 and OCaml's List.fold_left take the same three pieces — function, initial accumulator, list — in the same order, another close standard-library match. Note the accumulator comes first inside the lambda in both, opposite the element.

This is a genuine, surprising gap for an Erlang developer used to [Expr || Generator] comprehension syntax (which Erlang borrowed directly from Haskell). Standard OCaml has NO built-in list-comprehension syntax at all — the equivalent transformation is always spelled out with ordinary List.map/List.filter calls, unlike Erlang and Haskell, which both offer a dedicated comprehension notation for exactly this pattern.

Erlang appends the filter condition after a comma inside the same comprehension brackets, reading as one fluent expression. OCaml has to spell the same idea out as a separate List.filter call composed with whatever generates the source list (here List.init, since OCaml has no lists:seq/2-style range literal either) — noticeably more verbose for what Erlang expresses in one bracketed expression.

A base-case clause and a recursive clause, in the same order — nearly a mechanical translation. The one new keyword: OCaml requires rec to explicitly mark a function as recursive (let rec factorial), since ordinary let bindings in OCaml cannot refer to themselves — a small but real syntactic difference from Erlang, where every fun can always call itself by name.

The accumulator-passing style every Erlang developer already relies on transfers unchanged. OCaml, like Erlang's BEAM, guarantees tail-call optimization for calls in tail position, so this runs in constant stack space in both languages — one of the few guarantees that carries over exactly, not just in spirit.

Both languages treat functions as ordinary values, freely passed and stored. Notice OCaml's apply needs no type annotations at all here — inference figures out that f must be a function from increment's usage, staying just as terse as the Erlang original.

Here the languages genuinely diverge. Erlang requires writing the wrapping fun by hand to get a one-argument version of a two-argument function. In OCaml, add 5 alone is already valid — every function is secretly a chain of one-argument functions, so supplying fewer arguments than expected simply returns another function, with no wrapping required.

This is a genuine capability gap running the opposite direction from most of this site's Erlang comparisons: OCaml's ref cells and := assignment operator allow real, in-place mutation of a value shared across a whole program run — something no Erlang construct can do at all, since even Erlang process state is really "a new recursive call with a new argument" under the hood. OCaml requires opting into mutability explicitly per binding (via ref or a mutable record field); Erlang structurally cannot offer it in any form.

OCaml records may declare individual fields mutable, permitting <- assignment to update that field in place without rebuilding the whole record — Erlang has no equivalent whatsoever, since every Erlang tuple/record is entirely immutable and "updating" always means constructing a brand-new value.

Erlang modules are a flat, one-file, one-namespace mechanism — export a function or don't, with no deeper structure available. OCaml's module system is a genuinely richer, separate layer of the language: modules can nest inside each other, be parameterized by other modules (functors), and be constrained by explicit signatures (module type) independent of their implementation — a considerably more powerful toolkit with no direct Erlang equivalent.

Unlike Haskell (which prefers Either/Maybe for nearly everything and treats exceptions as a last resort), both Erlang and OCaml reach for genuine exceptions comfortably and often — try ... catch and try ... with are both everyday, idiomatic tools in these languages, not an escape hatch reserved for truly exceptional situations.

OCaml requires declaring an exception up front with the exception keyword, giving it a genuine name and payload type the compiler checks. Erlang has no separate exception-declaration step at all — throw({invalid_age, -1}) just throws an ordinary tagged tuple, caught by pattern matching the same way any other value would be, with no nominal exception type involved.

Erlang's "hello" is secretly [104, 101, 108, 108, 111], a plain list of integer code points — which is why ~w ("write the raw term") shows the numbers, while ~p/~s reprint it as text. OCaml's "hello" is a genuine, distinct string type — an immutable byte sequence, not a list of characters or code points at all, and not even iterable the way OCaml lists are without an explicit conversion.

Unlike the Haskell comparisons elsewhere on this site, an Erlang developer moving to OCaml finds no laziness-related surprises at all — both languages are strict by default, evaluating every expression immediately in the order written, with no thunks and no infinite-list idiom to learn. (OCaml does offer an explicit opt-in Lazy module for the rare cases that need deferred evaluation, matching Erlang's complete absence of anything similar.)