Erlang.CodeCompared.To/Scala

Erlang prints with io:format/1 and the ~n directive for the newline. Every runnable Scala program needs a main method on an object; println appends the newline for you and needs no import, since it comes from the automatically-included Predef.

Erlang's ~p ("pretty print") directive renders any term for humans, including nested tuples and lists. Scala's println relies on every object's inherited toString, which case classes and standard collections already implement sensibly — the output shown, Some(List(1, 2, 3)), needs no extra formatting call.

Erlang has no compile-time type checking at all — Add("two", 3) would compile fine and only fail when that exact line executes. Scala's def add(x: Int, y: Int): Int means add("two", 3) is rejected before the program ever runs, caught by the JVM's static type system rather than discovered in production.

Scala infers the type of result from context, so day-to-day local code reads almost as unannotated as Erlang — you rarely write val result: Int = ... explicitly. The difference only surfaces at function boundaries: Scala method parameters and return types are (with rare exceptions) always explicit, the one place static typing cannot infer its way past a genuine ambiguity.

Erlang's closest equivalent to Scala's type checker is Dialyzer, a separate static-analysis tool reading optional -spec annotations that a project can ship without ever running. In Scala, scalac is not an optional linter — the compiler simply refuses to produce a running program if the types disagree.

Erlang picks a function clause by matching the call against each one, top to bottom; Scala's match expression does the identical thing inside a single function, one case per Erlang clause. The when N > 0 guard becomes an if n > 0 guard on the case arm — same idea, attached in a slightly different place.

Both languages let you destructure a tuple directly in a binding. Erlang tuples are untyped and can hold anything of any arity; Scala tuples like (Boolean, Int) are typed by position, so mismatched destructuring is caught at compile time rather than crashing on an unlucky input.

Erlang can guard a case arm with when exactly the way it guards a function clause; Scala mirrors this with an if guard on a match case. Both read as "this shape, but only when this extra condition also holds."

Erlang's convention of returning {ok, Value} on success and a bare error on failure is exactly what Scala's built-in Option formalizes: Some(value) is {ok, Value}, and None is the failure case. Map.get already returns an Option, so this pattern is baked into the standard library rather than something you build by hand.

Nothing in Erlang forces you to handle the failure branch — skipping it just defers the crash to whenever a bad input finally reaches that assumption. Treating a Scala Option[Int] as a bare Int is a type error the compiler catches immediately; matching both Some and None is the idiomatic way to satisfy it.

Erlang has no built-in "transform the value if present, otherwise leave the failure alone" helper — you write the two-clause pattern match by hand every time. Scala's Option.map encapsulates exactly this: applying a function only inside Some, and leaving None untouched, with no explicit branching required.

Where Option only says "did it work," Scala's Either[L, R] carries a reason on failure — Left(reason) corresponds directly to Erlang's {error, Reason}, and Right(value) corresponds to {ok, Value}. By convention Right is the success case (a mnemonic: "right" also means "correct"), the same way ok tuples are always the success case in idiomatic Erlang.

Scala does have JVM-style exceptions and try/catch, syntactically close to Erlang's own try/catch. The philosophical difference is emphasis: idiomatic Scala tends to reserve exceptions for genuinely exceptional conditions and models expected failures with Option/Either instead, closer to how idiomatic Erlang reserves an actual crash for "let a supervisor restart me" rather than routine error signaling.

Erlang's -record(point, {x, y}). desugars to a tagged tuple at compile time — a naming convenience with no runtime type distinct from any other tuple of the same shape. Scala's case class Point(x: Int, y: Int) introduces a genuinely distinct type, plus free equality, a sensible toString, and pattern-matching support, none of which Erlang's records provide automatically.

Case classes come with pattern-matching support built in for free — case Point(x, y) => destructures exactly the way matching an Erlang tagged tuple {point, X, Y} does, down to naming the fields positionally. This is the feature that gives case classes their name: they exist specifically to be pattern-matched.

Erlang models "one of several shapes" as differently-shaped tagged tuples, distinguished by their first element and arity at match time. Scala's sealed trait Shape with case-class subtypes makes this a genuine closed sum type — sealed means the compiler knows every possible subtype lives in this file, and can warn if a match misses one, where Erlang would only discover a missed tuple shape when that exact input finally arrives at runtime.

An Erlang atom like ok is an unstructured constant drawn from a global, unbounded namespace of possible atoms. Scala's case object Ok extends Status gives the same "one fixed named value" idea but scoped and typed — a Status can only ever be Ok or Failed, never some unrelated value that happened to be spelled the same way elsewhere in the program.

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

Both languages call these map and filter. The syntax differs — Erlang passes the collection as an argument (lists:map(Fun, List)), Scala calls the method directly on the collection (list.map(fun)) — but the underlying transformation is identical, and _ * 2 is Scala's terse placeholder syntax for a one-argument lambda.

Erlang's lists:foldl/3 takes (function, initial accumulator, list); Scala's foldLeft is called on the list itself and takes (initial accumulator, function), with the accumulator listed first inside the lambda rather than the element. Same reduction, different argument order to watch for when porting code by hand.

Erlang's [Expr || Generator] list comprehension and Scala's for (generator) yield expr comprehension both describe "produce this expression for every value the generator yields." The keyword yield at the end is Scala's equivalent of Erlang putting the expression up front — both mark the same collected result.

Erlang appends the filter condition after a comma inside the same brackets; Scala's for attaches it with an if guard inside the parentheses. Both filter the generator before applying the result expression, and both read left-to-right as "for each X in this range, where this holds, produce this."

Multiple generators produce every combination in both languages, with the last generator varying fastest. Scala's multi-line for { ... } block form (using braces instead of a single line) is the idiomatic style once more than one generator is involved — worth recognizing as the same construct, not a different feature.

Erlang expresses the base case and recursive case as separate clauses; Scala often expresses the same idea as a single if/else expression, since Scala's match (the closer syntactic parallel to Erlang clauses) is more commonly reserved for genuine pattern matching rather than simple arithmetic conditions. Either style computes the identical result.

The accumulator-passing style every Erlang developer already relies on for stack-safe recursion transfers directly. Scala adds one thing Erlang has no equivalent for: the @tailrec annotation, which makes the compiler verify the function is actually tail-recursive and refuse to compile if it is not — Erlang's BEAM optimizes tail calls silently, with no way to ask the compiler to confirm a given function qualifies.

Both languages treat functions as ordinary values — Erlang funs and Scala function values are equally first-class. Scala's Int => Int is a function-type annotation, spelling out in the type system something Erlang leaves entirely implicit.

Erlang requires writing the wrapping fun by hand to get a partial application, exactly as shown. Scala supports currying natively via multiple parameter lists — def add(x: Int)(y: Int) — and add(5) _ (the trailing underscore) explicitly requests the remaining function as a value. Unlike Haskell, Scala functions are not curried automatically; you opt in with multiple parameter lists when you want this.

Erlang variables genuinely cannot be rebound within a scope — it is a match failure, enforced by the language itself, everywhere. Scala's val gives the same guarantee but as a choice: Scala also has var for genuine mutable variables, so immutability is a discipline you (or your team's style guide) opt into, not a rule the language forces on every binding the way Erlang does.

This is a genuine capability gap, not just a style choice: Scala's var is real, in-place mutation of a variable, something no Erlang construct can do — even Erlang's process state is really "a new recursive call with a new argument," never a variable changing value under your feet. Idiomatic Scala reaches for var sparingly (favoring val and immutable collections almost everywhere), but the option exists in a way it structurally cannot in Erlang.

This is the headline historical parallel of this whole comparison: Akka, the JVM's most widely used actor framework, was explicitly built as "Erlang-style actors for Scala/Java" — mailboxes, message passing, and supervision hierarchies are direct analogues of Erlang's process model, spawn/send/receive, and OTP supervisors. The commented Akka snippet is not executed (Akka is a separate library dependency this sandbox does not vendor), but the shape — receive a message, react, continue — is the same shape Erlang's receive block already uses.

Erlang's "let it crash" philosophy is not folklore borrowed loosely by Akka — Akka's SupervisorStrategy (restart, resume, stop, escalate) is a near-literal port of OTP's supervisor restart strategies (permanent, transient, temporary). An Erlang developer reading Akka supervision code will recognize the vocabulary, not just the concept.

Erlang's =:= always compares by structure and value, term for term — there is no other notion of equality to worry about. Scala's == is, reassuringly, also structural for case classes and standard collections like List (unlike raw Java's ==, which compares references) — but this is a deliberate override Scala's standard library provides, not a universal language guarantee the way it is in Erlang.

Erlang has no null concept whatsoever — undefined is just a regular atom with no compiler support behind it. Scala, inheriting the JVM, still has a real null that can be assigned to any reference type; idiomatic Scala avoids it almost entirely in favor of Option, and Option(value) is the standard bridge for wrapping a possibly-null Java API result safely.

The two ecosystems map closely at the command level: creating a project, compiling, an interactive shell, running tests, and producing a deployable artifact are all one rebar3/sbt subcommand away. sbt's build file is Scala itself (build.sbt), where rebar3's is Erlang terms (rebar.config) — both let the build configuration be written in a dialect of the language it builds.