OCaml.CodeCompared.To/Erlang

Erlang qualifies every call outside the current module as module:function(…), so io:format names the io module explicitly — there is no open and no way to bring names into scope. The newline is ~n rather than \n, because the format string is interpreted by io:format rather than by the lexer. And note what is absent: no entry point, no let, and a period rather than a semicolon to end the expression.

OCaml's format string is a typed value the compiler checks against the arguments. Erlang's is an ordinary string and the arguments come as a list, so a mismatch in count or kind is a runtime badarg. The directives worth knowing: ~p pretty-prints any term and is what you reach for by default, ~s prints a string or binary as text, and ~w writes a term without the pretty-printing. Note the capitalized variable names — that is not a convention, it is the syntax, and the next section is about why.

rebar3 is Erlang's build tool and Hex is its package registry, which maps onto dune and opam closely enough. The idea with no OCaml counterpart is the release: a bundle of your application together with the runtime itself, which can be started, supervised, connected to from a remote shell, and upgraded while running. That is the shape the whole platform is built around — a system that is expected to stay up across its own deployments, which is a different target from producing a binary.

The OCaml toplevel is a development tool: it evaluates expressions in a fresh process. The Erlang shell is an ordinary process inside a node, so it can send messages to any other process, inspect state with sys:get_state, check mailbox lengths, load new code, and do all of that on a live production node over a remote shell. That is a different debugging model — the question "what is this system doing right now" has a direct answer rather than requiring logs and a redeploy. It is also, obviously, a considerable amount of rope.

OCaml checks every expression before the program starts. Erlang checks nothing ahead of time — and unlike Python's optional hints or TypeScript's erased ones, the language has never had a static type discipline to fall back on. What it has instead is Dialyzer, a success-typing analyzer that finds code which cannot possibly work rather than code that is not provably right, so it reports no false positives and misses a great deal. The specs it reads (-spec add(integer(), integer()) -> integer().) are documentation the compiler ignores. The real answer to "how is this safe" is the next twelve sections: isolation and supervision rather than proof.

The -spec syntax is expressive — unions, records, opaque types, function types — and none of it is enforced at compile time or at run time. Dialyzer reads it, plus the code, and reports discrepancies: places where a call can be shown to always fail. Its design principle is that it never reports a false positive, which means it stays quiet about a great deal that OCaml would reject outright. Running it is a separate step most projects do in CI. The comparison an OCaml programmer should hold: this is not gradual typing, it is a linter with a very good theory behind it.

OCaml's let creates a new binding that hides the old one, so refining a value step by step under one name is idiomatic. In Erlang a variable is bound once per scope, and = is not assignment — it is a pattern match. Writing Value = Value * 2 attempts to match 5 against 10 and raises badmatch. So each step needs its own name, which is why real Erlang is full of Value0, Value1, Value2 — a genuine ergonomic cost, and the reason pipelines are written as nested calls or with a helper function per stage.

{Status, Body} = {200, "ok"} binds because both variables are new. {200, Body} = Response would bind Body and assert the first element is 200, raising badmatch if not — which is idiomatic Erlang for "this must be true, and I want to crash here if it is not". OCaml has the same power split across let, match and assertions. Note the case … of … end syntax and that clauses are separated by semicolons with the last ending in end; the guard keyword is when, as in OCaml.

OCaml's status is a type with three values, and the compiler proves the match covers them. Erlang's pending is an atom, any atom is a valid value, and no declaration exists to be exhaustive over — an unmatched value raises case_clause when it arrives. That sounds worse than it is in practice, for a reason this page keeps returning to: the crash is contained in one process and the supervisor restarts it, so the failure mode is a restarted worker and a log entry rather than a corrupted system. It is a genuinely different bet about where correctness comes from. Note the list comprehension, [Expr || X <- List], which OCaml does not have.

An atom is a constant whose value is its own name, written in lower case (or quoted: 'hello world'). It needs no declaration, is unique across the whole system, and compares in constant time because it is interned. OCaml's polymorphic variants are the nearest analogue — also undeclared, also structurally typed — but OCaml tracks which tags a value may carry and Erlang does not, so an atom is genuinely just a value. Atoms carry an enormous amount of Erlang: ok, error, undefined, every message tag, every module and function name. One caution: the atom table is not garbage collected, so never create atoms from untrusted input.

A tuple whose first element is an atom is the universal Erlang idiom — {ok, Value}, {error, Reason}, {circle, Radius} — and it maps onto an OCaml constructor with a payload exactly. What is missing is the declaration: nothing lists the shapes, nothing prevents a fourth, nothing checks the arity of the payload, and a typo in the tag simply fails to match. In exchange the tags cost nothing to introduce, travel between processes and across machines unchanged, and can be pattern-matched by code that has never heard of them.

Both are singly linked immutable lists, so consing is constant time and length is a traversal. The syntax differs in three ways: elements are comma-separated, the cons is [Head | Tail] rather than Head :: Tail, and the pattern form is the same bracket syntax ([First, Second | Rest]), which is more flexible than OCaml's. Erlang lists are heterogeneous — [1, atom, "text"] is a perfectly good list — where OCaml requires one element type. And length/1 is a plain function rather than List.length, because the commonest list operations are auto-imported.

OCaml's Map.Make (String) builds a module specialized to string keys and every operation goes through it. Erlang's map is a built-in type with literal syntax, keys of any type, and maps:find/2 returning {ok, Value} or the atom error — which is the tagged-tuple convention doing what an option does. The thing OCaml cannot do at all is the last two lines: a map is a pattern, so #{ada := Found} = Ages destructures it, and a function clause can match on the presence and value of specific keys. That makes maps usable where OCaml would need a record.

A -record declaration creates no type: the compiler rewrites #point{x=0} into a tuple {point, 0, 0} and field access into element positions. That means records are fast and are also invisible at run time, cannot be inspected generically, and require every module that uses one to include the same header file. Maps came later and are what most new code uses — no declaration, no header, matchable, and printable. OCaml's record is a genuine type the compiler checks and a signature can hide, which neither Erlang option offers. The Origin#{x := 5} syntax is the map update, and := requires the key to already exist while => inserts.

A double-quoted literal in Erlang is a list of integer code points — "abc" and [97, 98, 99] are the same value, indistinguishable. That is the same design as Haskell's String and has the same cost: one cons cell per character, and no way to tell a string from a list of small numbers, which is why io:format guesses and why ~p sometimes prints a word and sometimes prints digits. Real text uses binaries (<<"abc">>), covered in their own section, and modern code uses them nearly everywhere.

The comprehension reads as set-builder notation: generators with <-, filters as bare boolean expressions, and the result at the front. Each extra generator costs a line rather than a nesting level, where OCaml has to compose concat_map with filter_map and indent for each. Erlang also has binary comprehensions (<< <<(X*2)>> || <<X>> <= Binary >>), which generate and consume binaries the same way and have no counterpart anywhere else on this anchor.

A binary is a packed, immutable byte sequence — the type Erlang actually uses for text and for network data, because a "string" in the older sense is a list of integers, one cons cell per character, which is as wasteful as Haskell's String. What has no OCaml counterpart is that a binary is matchable: <<First, _/binary>> binds the first byte and ignores the rest, and the same syntax constructs. OCaml handles bytes with Bytes and Bigarray and offers no pattern syntax for them at all.

Bit syntax lets a pattern name field widths in bits, so a packed protocol header is matched by writing out its layout, with endianness and signedness available as modifiers and construction working the same way. The runnable example is byte-aligned, and the comment shows where the feature actually earns its reputation: widths below a byte, so <<Version:4, HeaderLength:4, ServiceType:8, TotalLength:16, …>> parses an IPv4 header in one expression. The OCaml column shows the alternative — shifts and masks by hand, one line per field, with the widths implicit in the constants. This is why Erlang is used for telecoms protocol work, and it is a genuine capability gap rather than a matter of taste.

In a module this would be two clauses — length_of([]) -> 0; and length_of([_|Rest]) -> 1 + length_of(Rest). — separated by a semicolon and ending with a period, which is the idiomatic form. Because the page evaluates expressions rather than modules, the anchor column's case shape is used instead, with fun Self(…) naming the function so it can recurse. Note that Erlang functions are identified by name and arity: foo/1 and foo/2 are entirely different functions, which is why documentation always writes the arity.

An OCaml when guard may call anything. An Erlang guard may use only a fixed set of built-in tests (is_integer, is_list, is_atom), comparisons and arithmetic — calling your own function in a guard is a syntax error. The reason is that guards must be free of side effects and guaranteed to terminate, because they run inside pattern matching including in receive. A guard that raises does not propagate the error; it just fails, and the next clause is tried. Note =:=, which is exact equality; == compares 1 and 1.0 as equal and is almost never what you want.

Erlang has no currying, so Add(10) is a call to a function of arity 1 that does not exist — an undef error rather than a partial application. Writing the closure out is the whole answer; there is no partial helper because arity is part of a function's identity, so a generic one cannot be written. The related idiom is fun Module:Function/Arity, which names an existing function as a value: lists:map(fun erlang:integer_to_list/1, Numbers).

OCaml eliminates tail calls as a language property, and so does Erlang. The difference is what rests on it: every long-running Erlang process is an infinite tail-recursive loop, receiving a message, computing a new state and calling itself. Without the guarantee the entire process model would be impossible. That is why the BEAM makes it a promise rather than an optimization, and why an Erlang programmer thinks about it constantly where an OCaml programmer thinks about it occasionally.

The lists module maps onto OCaml's List closely, with the notable difference that lists:foldl passes the element first and the accumulator second, which is the reverse of List.fold_left and a reliable source of confusion. There is no pipeline operator: Erlang has no |> and no currying to make one useful, so pipelines are nested calls or a chain of intermediate variables. The list comprehension covers most of what a pipeline would, with filters as bare guards after the generator.

OCaml's discipline is to make failure impossible or explicit: return a result, handle every case, keep the function total. Erlang's is to write only the happy path and let the process die when reality disagrees — because a process is cheap, isolated, and supervised, so a crash costs a restart from a known-good state rather than a corrupted system. The argument behind it is that defensive code for situations you did not anticipate is itself unreliable, and that the code you did not write cannot be wrong. It works because of the runtime, not instead of it, which is why the next four sections matter.

{ok, Value} and {error, Reason} are so universal that the whole standard library follows them, which makes them as reliable as a type in practice and as unenforced as any other convention. The distinction Erlang draws is worth adopting even in OCaml: expected failures are values, unexpected ones are crashes, and conflating them is what produces both over-defensive code and swallowed errors. What is missing compared with OCaml's result is composition — there is no bind, no let*, so chaining several fallible steps means nested case expressions.

error is a runtime fault — a bad match, a bad argument, a division by zero — and carries a stack trace. exit is a process terminating, and is what links and monitors report. throw is a non-local return the author intended, for control flow. OCaml has one mechanism and the distinction lives in naming conventions instead. The practical value of the split is that catch error:_ does not accidentally swallow a deliberate throw, and a supervisor can distinguish "this process was asked to stop" from "this process broke".

An OCaml 5 Domain is an operating-system thread with its own minor heap, so the guidance is a handful. An Erlang process is a runtime-level structure costing a few hundred words, with its own heap and its own garbage collector — so a process per connection, per user, per state machine is the normal design, and systems with millions are routine. That cheapness is what makes the rest possible: isolation, supervision and "let it crash" are only affordable because restarting a process is cheap. Note self() and ! for send, and that receive blocks until a matching message arrives.

OCaml's ref is a heap cell that any holder can write, needing a mutex once shared. Erlang has nothing equivalent — no cell, no assignment, no shared memory at all. State is a process holding a value and tail-calling itself with the next one, and the only way in is a message, so access is serialized by construction and a data race is not expressible. That is why the tail-call guarantee is load-bearing, and it is the pattern OTP's gen_server generalizes. The cost is that reading a value is a message round trip, which is why Erlang also has ETS for shared tables when that cost is too high.

register/2 binds an atom to a process for the whole node, so counter ! Message works from anywhere — and if the process dies, the name is released and sending to it raises badarg. That is how OTP's named servers are reached, and it is the closest thing Erlang has to a global. The cost is the usual one for globals: a registered name is a single instance per node, so anything needing several must be addressed by pid or through a registry process. OCaml has no equivalent because a domain handle is an ordinary value you thread through.

Each process has a mailbox, and receive scans it in order for the first message matching any of its patterns, leaving non-matching messages in place for a later receive. That makes priority handling, request/response correlation and protocol state machines trivial: a process expecting a reply to request 7 simply receives on {reply, 7, Result} and everything else waits. OCaml's queues and channels deliver in order, so the same behavior means draining, inspecting and re-queuing by hand. The caveat is performance: a selective receive scans the mailbox, so a process with a large backlog and a narrow pattern can go quadratic.

OCaml 5 domains share one heap, so passing a structure passes a pointer and correctness depends on locking. Erlang copies every message into the receiver's own heap, so no two processes ever reference the same mutable data — which is why there are no locks, no data races, and no need for a race detector. It is also why each process can be garbage collected independently, so a collection pauses one process rather than the world. The cost is real: sending a large structure copies it. The exceptions are large binaries, which are reference-counted and shared, and ETS tables, which are explicitly shared storage.

after Milliseconds -> … is a clause of receive, so every wait can carry a deadline at no cost. after 0 makes it a non-blocking poll of the mailbox, and a receive with only an after clause is how you sleep. That uniformity — waiting, timing out and sleeping being one construct — is the same design instinct behind Go's select, arrived at independently and twenty years earlier. OCaml has no timed wait in the standard library at all; Eio and Lwt supply one, and building it from Condition by hand is fiddly to get right.

OCaml's Domain.join re-raises the domain's exception in the joining thread, so the parent must be joining at the moment it wants to know. An Erlang monitor is one-directional and asynchronous: the watcher receives a 'DOWN' message whenever the watched process exits, for any reason, and can be doing something else in the meantime. A link is the bidirectional version — if either end dies abnormally the other is killed too, unless it has trapped exits. Those two primitives are the whole of the failure-propagation model, and supervisors are ordinary processes built from them.

The real version is a supervisor behavior: you declare the children, the restart strategy (one_for_one, one_for_all, rest_for_one) and the intensity — how many restarts in what period before the supervisor itself gives up and escalates to its supervisor. That escalation is why it is a tree: failure propagates upward until some level can restart from a state known to be good. There is no OCaml equivalent at any level, and building one is not simply a library exercise, because it depends on cheap isolated processes with independent heaps.

A link is bidirectional: if either end dies abnormally the other is killed too, which by default propagates failure through a group of related processes and takes the whole group down. Setting trap_exit changes that for one process: instead of dying, it receives an {'EXIT', Pid, Reason} message and can decide what to do. That one flag is the entire difference between a worker and a supervisor. OCaml has nothing comparable — an exception in a domain surfaces only at Domain.join, so a parent must be waiting at the moment it wants to know.

A gen_server is the receive loop with the generic half extracted: you write handle_call, handle_cast and handle_info, and OTP supplies the loop, synchronous calls with timeouts, orderly shutdown, code upgrade, tracing hooks and supervision integration. The other behaviors — supervisor, gen_statem, application — do the same for their patterns. The closest OCaml analogue is a module with a state type and transformation functions, which is a good design and leaves concurrency, restart policy and lifecycle entirely to you. OTP is the reason Erlang is used in production more than the language is.

An application bundles modules with a supervision tree, a declared dependency list and start/stop callbacks, so application:start/1 brings up everything it needs in dependency order and application:stop/1 tears it down cleanly. Applications compose into a release, which adds the runtime itself. The result is that "the system" is a first-class artifact with a defined lifecycle, rather than a binary plus an init script plus a process supervisor supplied by the operating system. OCaml has libraries and executables and leaves the lifecycle entirely to you.

The BEAM counts reductions — roughly, function calls — and preempts a process after about two thousand, regardless of what it is doing. There is no yield point to remember, no cooperative scheduling to get wrong, and no way for one process to starve another. Combined with a per-process heap and per-process garbage collection, that means no global pause: collecting one process does not stop the system. This is why the platform can promise soft real-time latency, and it is the deepest architectural difference from OCaml, whose domains run until they yield and whose collector, while incremental, is shared.

The BEAM holds two versions of a module at once — current and old. A local call stays in the version the process is already running; a fully qualified call (?MODULE:loop(State)) jumps to the newest. So a long-running process picks up new code at a point you choose, carrying its state across, with a code_change callback to migrate that state if its shape changed. No restart, no dropped connections, no draining. OCaml has nothing comparable and neither does any other target on this anchor; a deployment is a new executable. It is worth knowing this exists even if you never use it, because it explains why so much of Erlang looks the way it does.

Connect two BEAM nodes and Pid ! Message works between them unchanged, with the runtime handling connection, term encoding and failure detection. A monitor spans machines, so a node going away arrives as the same 'DOWN' message a local process dying does — one failure model for both. That is a genuinely different starting point from choosing HTTP or gRPC and a codec. The honest caveats: the default distribution protocol assumes a trusted network and a shared cookie, it is a full mesh that does not scale past a few hundred nodes, and "transparent" distribution hides latency and partition behavior that eventually matters.

Message passing copies, which is what makes isolation work and what makes a shared cache expensive — every reader would get its own copy. ETS is the escape hatch: an in-memory table living outside any process heap, readable and writable concurrently, with configurable concurrency options. It is explicitly not garbage collected with a process, is owned by its creator and dies with it, and it reintroduces exactly the shared-mutable-state problems the rest of the language removes. The rule of thumb is to use it for caches and lookup tables read far more often than written, and to keep mutable logic in processes.

erlang:process_info/2 reports a process's mailbox length, current function, memory, links and more; erlang:processes() lists every process in the node; sys:get_state/1 extracts a running gen_server's state; and the tracing facilities can watch specific function calls on a live system with per-process filters. None of that needs instrumentation added beforehand, and all of it works over a remote shell against production. OCaml has excellent profiling and a debugger, and they are tools you run against a process rather than questions the runtime answers about itself.

Both columns print the same three lines and neither has colored functions — task is an ordinary function in both. The mechanisms are opposites. OCaml suspends a computation and hands its continuation to a handler that decides what happens next, which is extremely general: schedulers, generators, backtracking and async I/O are all one feature. Erlang suspends a process, which blocks in receive until a message arrives — far less general, and it comes with isolation, supervision, per-process collection and distribution attached. OCaml has the more powerful primitive; Erlang has thirty-five years of production systems built on the less powerful one.

Two transfer directly and need no runtime support. Separate expected failures from bugs — a result for what a caller should handle, an exception for a broken invariant, and never the reverse; conflating them is what produces both over-defensive code and swallowed errors. Put state behind a boundary that serializes access — in OCaml that is a module with an abstract type and functions that transform it, which gets you the same "no unsynchronized reach-in" property by discipline where Erlang gets it by construction. What does not transfer is "let it crash", which is not a coding style but a property of a runtime with cheap isolated processes and supervision; adopting it without them is just unhandled exceptions.

The BEAM is built for scheduling millions of processes fairly and preempting them predictably, and those goals cost raw throughput. Numeric and CPU-bound work is substantially slower than OCaml's native code — often by an order of magnitude — and although the two columns above do the same ten thousand iterations and print the same total, the time taken is not close. The standard answer is a NIF (a C function loaded into the VM), which reintroduces every risk Erlang exists to remove: a NIF that crashes takes the whole node with it, and one that blocks too long breaks the scheduler's fairness guarantee. If the hard part of the problem is computation rather than coordination, this is the wrong runtime.