Erlang.CodeCompared.To/F#

Erlang prints with io:format/1 and the ~n directive for the newline. F#'s printfn appends the newline for you. Neither language requires wrapping this in a class, module, or main function — both run top-level code directly, top to bottom, one of the strongest structural parallels on the whole site.

Erlang's ~p ("pretty print") directive renders any term for humans. F#'s %A format specifier does the equivalent job for any value, including nested options, lists, and records — both exist precisely so you never have to hand-write a formatter for ordinary data.

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

F# rarely needs the explicit annotations shown in the previous example — its Hindley-Milner-style 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 F# infers a type, it locks it in and enforces it everywhere the function is called.

F#'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 when guard attached to a specific pattern, a wildcard _ catch-all. Of every language in this comparison, F# maps onto Erlang's pattern-matching instincts the most directly.

Both languages destructure a tuple directly in a binding. Erlang tuples are untyped and any arity; F# 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. F#'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.

Erlang models "one of several shapes" as differently-tagged tuples, distinguished by their first element and arity at match time. F#'s type Shape = Circle of float | Rectangle of float * float formalizes exactly this pattern as a genuine, closed discriminated union — 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. F#'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 convention of returning {ok, Value} on success and a bare error on failure is exactly what F#'s built-in Option formalizes: Some value is {ok, Value}, and None is the failure case. Map.tryFind already returns an Option, baking the convention into the standard library rather than something you build by hand.

Where Option only says "did it work," F#'s Result<'T, 'Error> carries a reason on failure — Error reason corresponds directly to Erlang's {error, Reason}, and Ok value corresponds to {ok, Value}. F# even reuses the bare word Ok, the closest naming match 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 F# Result<int, string> as a bare int is a type error the compiler catches immediately; matching both Ok and Error is the idiomatic way to satisfy it.

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. F#'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 F# record can be mutated in place, "changing" one field always means producing a new value. F#'s { point with Y = 99 } copy-and-update syntax does this in one expression, copying every other field automatically — Erlang has no equivalent shorthand, so the same operation on a record means rebuilding the whole tuple by hand (or using the Point#point.y record-update syntax, which only exists inside a compiled module, not at shell-expression level).

Both languages model lists as singly-linked cons cells. Erlang spells the pattern [Head | Tail]; F# spells it head :: tail, the same :: cons operator F# lists are built from. F# 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 F#'s List.map. This is one of the closer standard-library vocabulary matches across the whole comparison.

Erlang's lists:foldl/3 and F#'s List.fold take the same three pieces — function, initial accumulator, list — in the same order, another close standard-library match. Note the accumulator comes first inside F#'s lambda, opposite the element, exactly the convention lists:foldl's function argument also uses.

A base-case clause and a recursive clause, in the same order — nearly a mechanical translation. The one new keyword: F# requires rec to explicitly mark a function as recursive (let rec factorial), since ordinary let bindings in F# 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. F# on .NET, 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 F#'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 F#, 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 real ergonomic gap. Erlang has no pipe operator at all — a chain of transformations either nests calls inside-out or introduces a fresh temporary variable per step, as shown. F#'s |> threads a value through a sequence of function calls left to right, reading in the same order the transformations actually happen — closer to Elixir's |> than anything native to Erlang itself.

Erlang variables genuinely cannot be rebound in the same scope — it is a match failure, enforced everywhere. F#'s let gives the same immutability by default, but a second let x = ... in a nested scope shadows rather than rebinds — a subtly different failure mode than Erlang's, though the net effect (the original value is never mutated) is the same.

This is a genuine capability gap: F#'s mutable keyword and <- assignment operator allow real, in-place mutation — something no Erlang construct can do, even Erlang's process state is really "a new recursive call with a new argument." F# requires opting into mutability explicitly per binding; Erlang structurally cannot offer it at all.

F#'s MailboxProcessor ("F# Agents") is explicitly documented as bringing Erlang-style actors to .NET: each agent has its own mailbox, processes messages sequentially with inbox.Receive(), and is sent messages asynchronously with Post — a direct structural echo of Erlang's spawn/!/receive. Unlike Erlang processes, though, .NET agents still share the same memory space, so the isolation Erlang gets for free is not automatic here.

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. F#'s "hello" is a genuine, immutable UTF-16 System.String from the .NET base class library — no code-list representation lurking underneath.

Erlang has no null concept whatsoever — undefined is just a regular atom with no compiler support behind it. F#, inheriting the .NET runtime, still permits null for reference types (though idiomatic F# avoids it almost entirely in favor of Option, and F# 9's nullability analysis increasingly warns against it).

Both ecosystems bundle project creation, compiling, an interactive shell, testing, and producing a deployable artifact behind one command-line tool. dotnet fsi ("F# Interactive") plays exactly the role rebar3 shell does — a REPL with your project already loaded, for quick experiments without a full compile cycle.