Erlang.CodeCompared.To/Haskell

Erlang prints with io:format/1 and the ~n directive for the newline. Every Haskell program's entry point is main :: IO () — a type signature declaring that main performs side effects and produces no meaningful value — and putStrLn appends the newline automatically.

Erlang's ~p ("pretty print") directive renders any term for humans. Haskell's print does the same job, but through the Show typeclass — it only works on values whose type has derived or implemented Show, which is almost everything built-in.

This is the single biggest adjustment for an Erlang developer. Erlang has no compile-time type checking at all — Add("two", 3) would compile just fine and only blow up when that line actually executes. Haskell's type signature Int -> Int -> Int means add("two", 3) is rejected by the compiler before the program ever runs, not discovered in production.

Haskell does not actually require you to write every type signature — its Hindley-Milner type inference deduces double :: Num a => a -> a on its own, the same way you never had to specify a type for Double in Erlang. The difference is what happens after inference: Haskell locks that inferred type in and enforces it everywhere the function is used.

Erlang's closest thing to Haskell's type checker is Dialyzer, a separate static-analysis tool that reads optional -spec annotations — but it is advisory, runs as its own build step, and a project can ship with zero specs. In Haskell, type checking is not a linter you can skip; the compiler refuses to produce a program at all if the types do not line up.

Both languages pick which "clause" (Erlang) or "equation" (Haskell) runs by matching the call against each in order, top to bottom. The shape is so close that an Erlang developer can read Haskell equations on sight — the only new idea is the | guard syntax, covered next.

Both languages let you destructure a tuple directly in a binding. Where they differ: Erlang tuples are heterogeneous and untyped, so {ok, 42} and {ok, "hi"} are both perfectly ordinary 2-tuples; Haskell tuples are typed by position, so (Bool, Int) and (Bool, String) are genuinely different types that cannot be swapped in by accident.

Erlang's case Expr of Pattern -> Body end and Haskell's case Expr of Pattern -> Body are close enough to be nearly interchangeable reading material — both let you attach a guard to an individual pattern arm rather than defining a whole new function clause.

A direct rename: Erlang's when Condition after a clause head becomes Haskell's | Condition = ... after an equation head. otherwise in Haskell plays exactly the role of Erlang's catch-all clause with no guard — it is simply defined as the atom True so it always matches last.

Both read top-to-bottom as a chain of "if this, then that; otherwise keep checking" — Erlang guards attached to separate clauses, Haskell guards attached to one equation. The visual rhythm (right-aligned conditions, right-aligned results) is nearly identical between the two.

Erlang can guard a case arm with when exactly the way it guards a function clause. Haskell mirrors this with a guard on the case alternative — and this example shows Haskell's backtick syntax, x `mod` 2, for calling a two-argument function as an infix operator, which has no Erlang equivalent (Erlang's rem/div are already infix keywords).

Erlang's convention of returning {ok, Value} on success and a bare error (or {error, Reason}) on failure is exactly what Haskell's built-in Maybe type formalizes: Just value is {ok, Value}, and Nothing is the failure case. The difference is that Haskell's type system requires the caller to handle both cases — there is no way to accidentally treat a Maybe Int as a bare Int the way Erlang code can accidentally forget to check for error.

This is the same idea one level richer: where Maybe only says "did it work," Either carries a reason on failure — Left reason corresponds directly to Erlang's {error, Reason}, and Right value corresponds to {ok, Value}. By convention Left is always the failure case in Haskell, the same way error/error tuples are always the failure case in idiomatic Erlang.

Nothing in Erlang forces you to handle the error branch — skipping it just means a crash shows up later, at the exact unlucky moment a bad input reaches that assumption. Haskell's compiler will warn (and with the right settings, refuse to compile) if a case over an Either or Maybe does not cover every constructor — the "handle both outcomes" habit a careful Erlang developer already has becomes something the compiler double-checks for you.

The bracket-and-comma literal [1, 2, 3] and the cons pattern are conceptually the same linked-list model in both languages — Erlang spells cons as [Head | Tail], Haskell as (headValue : tailValues), using : instead of |. One real difference: Haskell lists are homogeneous — every element must share one type — while Erlang lists happily mix atoms, numbers, and tuples.

Both languages call these map and filter, and both apply cleanly in a pipeline. Haskell's (* 2) is a "section" — a partially applied operator that reads as "multiply by 2" without needing an explicit lambda, and even is a built-in predicate where Erlang needs to spell out N rem 2 =:= 0.

Erlang's lists:foldl/3 and Haskell's foldl share the same name and the same argument order (function, initial accumulator, list) — a rare case where the standard library vocabulary lines up exactly. Haskell also offers the stricter, more efficient foldl' for large lists, avoiding the lazy thunk buildup foldl can accumulate.

This is the single closest syntactic match between the two languages anywhere in this comparison. Erlang's list comprehension syntax, [Expr || Generator], is a direct descendant of Haskell's [expr | generator] — same reading order, same generator arrow, differing only in || versus |. An Erlang developer can read Haskell comprehensions with essentially no translation.

Both put the filter condition after a comma, following the same generator. The range syntax differs slightly — Erlang's lists:seq(1, 10) is a function call, while Haskell's [1 .. 10] is built-in range syntax — but the comprehension itself reads almost identically.

Multiple generators, separated by commas, produce every combination in both languages — the second generator varies fastest, exactly the nested-loop order you would expect. This is the pattern behind the classic Prolog-style "generate every pair" idiom, expressed natively in both Erlang and Haskell without reaching for an external library.

A base-case clause and a recursive clause, in the same order, doing the same thing — this could nearly be a mechanical translation. Haskell's Integer (as opposed to fixed-width Int) gives arbitrary precision the same way Erlang's integers do by default, so factorial 30 does not silently overflow in either language.

The base case for the empty list and the recursive case peeling off the head are identical in structure. Note the Haskell type signature [a] -> Int: the lowercase a is a type variable, meaning this function works on a list of any single type — Erlang gets the equivalent generality for free simply by having no type system to restrict it.

The accumulator-passing style every Erlang developer already uses for stack-safe recursion transfers unchanged. The one asterisk: because Haskell is lazy by default, a naive accumulator can build up a chain of unevaluated additions (a "thunk") instead of a running total — real Haskell code often reaches for foldl' (the strict fold) rather than hand-rolling this exact pattern, which the "Laziness" section covers.

Both languages treat functions as ordinary values that can be passed around, stored, and called through a variable — Erlang funs and Haskell functions are equally first-class. The type signature (a -> b) -> a -> b is Haskell being explicit about something Erlang leaves implicit: the first argument must itself be a function from some type to another.

Here the languages genuinely diverge. Erlang's Add(5, Y) IS a two-argument call — to get a one-argument function you must wrap it in a new fun by hand, as shown. In Haskell, add 5 alone is already valid: every function is secretly a chain of one-argument functions (Int -> (Int -> Int)), so supplying fewer arguments than expected just returns another function, no wrapping required.

Erlang has no built-in composition operator, so combining two functions means writing the wrapping fun yourself. Haskell's . operator does exactly that composition natively — f . g means "apply g, then apply f to the result" — turning composition into a first-class piece of syntax rather than a pattern you build by hand.

Erlang's -record(point, {x, y}). desugars to a tagged tuple at compile time — it is purely a naming convenience, and nothing stops a stray tuple of the right shape from being mistaken for a record elsewhere in the code. Haskell's data Point = Point { x :: Int, y :: Int } introduces a genuinely distinct type: a Point can never be confused with an unrelated two-field structure, even one that happens to also hold two Ints.

Erlang models "one of several shapes" as a list of differently-shaped tagged tuples, distinguished at pattern-match time by their first element and arity. Haskell's data Shape = Circle Double | Rectangle Double Double makes this a genuine sum type — the compiler knows there are exactly two constructors, and if a match on Shape ever misses one, it can warn you at compile time rather than crashing on an unmatched Erlang tuple shape at runtime.

An Erlang atom like ok is an unstructured, untyped constant that could be any of thousands of possible atoms in the whole runtime. Haskell's data Status = Ok | Failed gives you the same "one of a fixed small set of named things" idea, but scoped and typed — a Status value can only ever be Ok or Failed, never an unrelated atom that happened to leak in from somewhere else in the program.

Erlang's version genuinely crashes: both arguments are computed before First is even entered, so 1 div 0 raises before the function has a chance to ignore it. Haskell's equivalent succeeds and prints 42 — laziness means div 1 0 is never evaluated at all, because the function body never actually looks at its second argument. This is one of the largest behavioral differences an Erlang developer will encounter.

Erlang's lists:seq/2 must be given a finite end, because Erlang lists are ordinary eagerly-built data. Haskell's [1 ..] is a genuinely infinite list that costs nothing to write down — only take 5 forces the first five elements to actually be computed. Laziness turns "generate infinitely, consume finitely" into a completely ordinary pattern, where Erlang would need a dedicated recursive generator process to get the same effect.

An Erlang function can print, send a message, or write a file in the middle of otherwise-pure logic, with nothing in its signature warning the caller. Haskell's type signature String -> IO () makes side effects visible in the type itself — any function that touches the outside world is tagged IO, and the compiler will not let an IO action quietly hide inside code that claims to be pure.

Erlang sequences side-effecting expressions with an ordinary comma, the same punctuation as every other expression. Haskell needs a dedicated syntax, do notation, specifically because ordinary Haskell expressions have no inherent order — do is what lets IO actions read top-to-bottom like an imperative script despite the language being pure everywhere else.

Both examples do the same work, but only Haskell's type signatures document the distinction: square :: Int -> Int is guaranteed pure (same input, same output, forever, no exceptions), while printSquare :: Int -> IO () is honest about touching the outside world. Erlang has no equivalent marker — you learn which functions are safe to call repeatedly only by reading their bodies.

Erlang's concurrency story is famously the process — cheap, isolated, sharing nothing, communicating only through message passing, with a supervisor tree to restart failed ones. Haskell's forkIO gives similarly lightweight green threads, but they are not isolated the way Erlang processes are: Haskell threads share memory by default (using MVars or software transactional memory to coordinate), so the fault-isolation "let it crash" story is not automatic the way it is on the BEAM.

Erlang processes never share memory — the only way to communicate is ! (send) and receive, and this is true whether the processes are on the same machine or different ones, which is exactly what makes Erlang distribution transparent. Haskell's MVar is a shared, mutable, synchronized box that multiple threads can read and write directly — a fundamentally different (and more familiar-to-most-languages) concurrency model than Erlang's share-nothing actors.

Erlang's reliability philosophy does not try to prevent every possible runtime error — it accepts that failures happen, isolates each computation in its own process, and relies on a supervision tree to restart failed processes into a known-good state. This works precisely because Erlang has no static type system standing in the way of writing quick, disposable code that is expected to sometimes fail.

Haskell's philosophy is the mirror image: design the types so the bad state cannot be constructed in the first place, and let the compiler enforce that every caller handles the case where it might have failed. Neither philosophy is strictly "better" — Erlang trades compile-time guarantees for extreme runtime fault isolation and hot code reloading; Haskell trades development-time friction for eliminating whole categories of bugs before the program ever runs. Both were built by people who took reliability seriously, from opposite ends of the problem.

Erlang variables genuinely cannot be rebound within the same scope — attempting it is a match failure, not silent mutation. Haskell has no assignment operator at all in the imperative sense; let x = 41 inside a nested scope merely shadows the outer x with a new, unrelated binding, rather than either rebinding it (impossible) or erroring (also different from Erlang). Both languages ultimately guarantee "no mutation," but they enforce it through different mechanisms and fail differently when you fight them.

Here the two languages actually agree more than either agrees with, say, Elixir: Haskell's built-in String type is defined as [Char], a plain linked list of characters — conceptually the very same representation as Erlang's charlist. The visible difference is only in how each language's default printer renders it: Haskell's Show instance for String prints it back as quoted text, while Erlang's ~w reveals the raw list of codes and only ~p/~s reprint it as readable text.

It is worth remembering Haskell's guarantees have edges: head on an empty list crashes at runtime exactly the way Erlang's hd([]) does, because the ordinary list type carries no compile-time proof of non-emptiness. Serious Haskell code reaches for a total alternative (listToMaybe, or a non-empty list type) the same deliberate way careful Erlang code checks for an empty list before calling hd/1 — the type system reduces the surface area of possible bugs, but "reduces" is not "eliminates."