Ruby.CodeCompared.To/Erlang

Erlang prints with io:format/1, and the newline is not automatic — the ~n directive inside the format string produces it. Notice the trailing period: it terminates the whole expression, the way a Rubyist might end a statement, except Erlang uses it only at the very end of a sequence of expressions, with commas between the steps.

Erlang's ~p ("pretty print") directive renders any term for humans, the direct counterpart of p. The value here also previews two Erlang staples: a tuple — a fixed-size, ordered group of values, here a status code, an atom, and a string — is the everyday way to bundle a few related things, and the arguments to io:format are passed as a list in the second position, so the format string and its data stay separate.

Erlang has a single comment form: % runs to the end of the line, and there is no block-comment syntax at all, so a multi-line comment is just several % lines. Convention doubles the marker (%%) for a comment that describes the code below it and a single % for an aside at the end of a line, but that is style, not a language rule.

In Erlang = is the match operator, not assignment. Variables start with a capital letter, and X = 41 asserts that the left side matches the right: since X is unbound, the match succeeds by binding it. This one operator does double duty as both "bind" and "assert equal", which is the foundation of the pattern matching in the rest of this section — the same = that binds a name can also take a value apart.

An Erlang variable is bound exactly once. Because = is a match, writing X = 2 after X = 1 does not reassign — it asserts that 1 equals 2, which fails with a badmatch error and stops the program. This "single assignment" rule is the surprise that trips up every Rubyist first, and it is deliberate: a value you have named can never change under you, so there is no such thing as stale state or a variable meaning two things in one scope.

Erlang destructures with the same = you just met: {X, Y} = Point matches a two-element tuple, binding X and Y as it goes. It looks like Ruby's parallel assignment, but it is stricter and more powerful at once — the shapes must line up exactly (a three-element tuple would badmatch here rather than silently drop a value), and you can put literals in the pattern to match and assert in a single step, such as {ok, Value} = ....

An Erlang atom is the same idea under a different name: a constant whose value is just itself, interned and compared by identity. The one visible difference is the punctuation — a Ruby symbol wears a leading colon (:ok) while an Erlang atom is a bare lowercase word (ok), which is exactly why Erlang variables must be capitalized: the capitalization is what distinguishes a variable from an atom. Atoms carry far more weight in Erlang than symbols do in Ruby — true, false, ok, and error are all just atoms.

Erlang has no objects, no classes, and no methods. The idiomatic stand-in for a small record is a tagged tuple — {person, "Alice", 30}, a tuple whose first element is an atom naming its shape — which you take apart by matching. The data carries no behavior at all; functions that operate on a person live separately in a module and receive the tuple as an argument. This split between inert data and free functions is the deepest structural difference from Ruby, where data and the methods that act on it are bundled together in an object.

Erlang's map is the close counterpart, written with the #{...} syntax and read with functions from the maps module rather than an index operator — maps:get/2 here. The keys are atoms (cpu, memory), the same role Ruby's symbol keys play in { cpu: 4 }. Like everything in Erlang the map is immutable — maps:put/3 returns a new map rather than changing the original — and a missing key raises with maps:get/2, so the safe-lookup habit is maps:get/3 with a default or maps:find/2, which returns an {ok, Value}/error result you match on.

Nothing in Erlang can be mutated in place. "Adding" to a list means building a new one with ++ and binding it to a new name, while the original stays exactly as it was — note how Numbers is still [1, 2, 3] afterward. This removes the aliasing surprise a Rubyist knows well, where two variables point at the same array and a push through one is silently seen through the other. Combined with single assignment, it means no value in the program ever changes once created — the property that makes Erlang's share-nothing processes safe.

Erlang has no nil. The pervasive convention is to return a tagged tuple — {ok, Value} on success, {error, Reason} on failure — that the caller takes apart by matching. The value here also shows a fun with two clauses matching different argument patterns (answer versus the catch-all _), which is how Erlang expresses what a Rubyist would write as an if or a ternary. Because the result is a value with a shape, the "forgot to check for nil" bug becomes a match you cannot skip.

Erlang's case is the natural home of this idiom, and it reads almost exactly like Ruby's case/in: each clause is a pattern that both selects the branch and binds the payload, with clauses separated by semicolons and the whole thing closed by end. The difference from Ruby is that this structural matching is not a newer addition bolted onto the language but its primary control-flow tool — you will reach for case and multi-clause functions far more than for anything resembling an if.

Erlang has try/catch too, and it matches on the class and value of the failure (error:badarith here) much as Ruby matches an exception class. But the Erlang philosophy is to use it sparingly: rather than defensively rescuing, you "let it crash" and let a supervisor restart the failed process in a known-good state (see the Processes section). Where a Rubyist wraps risky code in begin/rescue to keep one thread alive, an Erlang programmer more often lets a small isolated process die cleanly and be reborn.

An Erlang fun is the same first-class function value, written fun(N) -> N * 2 end and applied by simply naming it with parentheses, Double(21). Erlang has no blocks and no distinction between a passed function and a special callback slot — a fun is just a value you can bind, pass, and call anywhere, so the &/yield/block_given? machinery a Rubyist juggles simply has no equivalent here.

Erlang's lists:map/2 takes the function first and the list second, passing a fun where Ruby passes a block. The operations you know from Enumerable mostly live in the lists module as plain functions — lists:filter/2, lists:foldl/3, lists:sort/1 — called on the list rather than dotted off it. There is no method chaining, since lists are not objects with methods; you either nest the calls or thread the value through a comprehension, which the next section shows.

Erlang has no for or while loop and no mutation, so repetition is recursion — here a named fun (fun Fact(...) -> ... end) so it can call itself. Note the two clauses separated by a semicolon: Fact(0) matches the base case and Fact(N) the rest, so the pattern in the function head replaces the if a Rubyist would write inside the body. Real Erlang leans hard on this — most "loops" are multi-clause recursive functions, and the runtime optimizes tail-recursive ones so they never grow the stack.

This is what real Erlang code looks like on disk: a file declares its -module name, lists the functions it makes public with -export, and defines top-level named functions with pattern-matched clauses — no fun ... end wrapper needed. A module is purely a namespace for functions; there is nothing to instantiate and nothing to mix in, so it is closer to a Ruby module of self. methods than to a class. Calls are always qualified by the module, as in math_utils:double(21).

Erlang has a built-in list comprehension that folds the filter and the transform into one expression: [N * N || N <- List, N rem 2 =:= 0] reads as "N squared, for each N drawn from the list, where N is even". The <- is a generator and the trailing condition is a filter — a compact, readable alternative to chaining lists:filter/2 and lists:map/2. Note =:=, Erlang's exact-equality operator; it is stricter than == and does not treat the integer 2 and the float 2.0 as equal.

Erlang's lists:foldl/3 is the counterpart to reduce, taking the folding function, the starting accumulator, and the list. The argument order differs from Ruby — the function comes first and the list last — and the accumulator is the second parameter of the fun, not the first, so it pays to read the signature rather than assume Ruby's ordering. There is also a lists:foldr/3 that folds from the right, and lists:sum/1 for this specific case.

This is why a Rubyist would learn Erlang. spawn starts a fully isolated, independently garbage-collected process — far lighter than an OS thread, thousands or millions to a system — and hands back its Pid (bound here to Printer). Processes share no memory; they communicate only by sending messages with !, and a process blocks in receive until a message matches one of its patterns. There are no locks anywhere because there is no shared state to protect, so the whole category of race condition a Ruby Mutex exists to prevent simply does not arise.

Erlang has no mutable variables, so state cannot live in an object field — it lives in a process. A recursive receive loop carries the current count as an argument, and each message produces the next state by calling itself with a new value (Loop(Count + N)); nothing is ever mutated. The only way to read or change that state is to send the process a message, which means the state is reachable from exactly one place and can never be corrupted by a concurrent caller. This process-holds-state pattern is the seed of OTP's gen_server, the backbone of real Erlang systems.

Erlang's answer to failure is structural rather than inline. A process links to another with spawn_link, and when the child crashes (here an explicit exit(boom)) the runtime sends the linked parent an {'EXIT', Pid, Reason} message instead of letting the error propagate into it. A parent that has called process_flag(trap_exit, true) receives that message and can restart the child in a fresh, known-good state. That is "let it crash": you do not defensively rescue every operation, you isolate work in small processes and let a supervisor above them handle death — a resilience model Ruby has no built-in equivalent for.

Erlang folds the conditions into the function head as guards: fun(N) when N > 0 -> ... means "this clause applies only when N is positive". The clauses are tried top to bottom, and the catch-all (_) plays the role of else. Guards are restricted to a fixed set of side-effect-free tests (comparisons, type checks like is_integer/1, arithmetic), so you cannot call an arbitrary function in one — a limitation that keeps matching predictable and fast.

Erlang's if is a guard-driven expression, and it is stricter than Ruby's in a way that catches newcomers: every branch is a guard, and one of them must succeed, so the conventional final branch is the literal guard true -> serving as the catch-all. There is no bare else, and omitting the true branch when nothing else matches raises an error rather than quietly producing nil — Erlang would rather fail loudly than hand back a nothing you did not ask for. In practice Erlang code uses case and function-head guards far more than if.

A double-quoted Erlang string is not a distinct type at all — it is a plain list of integer character codes, which is why ~w (raw term output) prints [104,101,108,108,111] rather than the letters. Every list function works on it, but there is no string object and none of Ruby's string methods. For real text-heavy work Erlang programs use binaries instead, written <<"hello">>, which are compact and are what libraries expect; the list-of-codes form survives mostly for small literals and history.

Erlang has no truthiness whatsoever. true and false are ordinary atoms, and the boolean operators andalso, orelse, and not accept only those two atoms — a number or a list in a boolean position is an error, not a shortcut. The Ruby idioms that lean on truthy values (value || default, guarding on a possibly-nil object) have no equivalent; their jobs move to explicit pattern matching on {ok, _}/{error, _} and to guards. Nothing is ever coerced to a boolean behind your back.