Erlang.CodeCompared.To/Rust

Erlang prints with io:format/1 and the ~n directive for the newline. Rust's println! macro appends the newline for you. Rust's "no main needed for a snippet" convention on this site (the runner auto-wraps this in fn main() { ... }) mirrors how Erlang's shell expressions need no wrapping function either.

Erlang's ~p ("pretty print") directive renders any term for humans. Rust's {:?} ("debug") format specifier does the equivalent for any type that derives or implements Debug — which includes nearly everything in the standard library, including Option and Vec.

Erlang has no compile-time type checking at all — Add("two", 3) would compile and only fail when that exact line executes. Rust's fn add(x: i32, y: i32) -> i32 rejects add("two", 3) before the program ever runs.

Rust infers the type of result from context, so everyday local code reads almost as unannotated as Erlang. The difference only surfaces at function boundaries: Rust function parameters and return types are always explicit, one place static typing cannot infer its way past a genuine ambiguity.

Erlang picks a function clause by matching the call against each one, top to bottom; Rust's match does the identical thing inside a single function, one arm per Erlang clause. Rust adds one guarantee Erlang lacks: the compiler verifies every match is exhaustive, refusing to compile if a case is missed.

Both languages destructure a tuple directly in a binding. Erlang tuples are untyped and any arity; Rust tuples like (bool, i32) are typed by position, so a mismatched destructure is a compile error rather than a runtime crash.

Erlang's convention of returning {ok, Value} on success and a bare error on failure is exactly what Rust's built-in Option<T> formalizes: Some(value) is {ok, Value}, and None is the failure case. HashMap::get already returns an Option, baking the convention into the standard library.

Where Option only says "did it work," Rust's Result<T, E> carries a reason on failure — Err(reason) corresponds directly to Erlang's {error, Reason}, and Ok(value) corresponds to {ok, Value}, reusing the exact word ok.

Erlang has no shorthand for "unwrap this {ok, Value}, or bail out early with the error" — every step in a chain re-pattern-matches by hand, as shown. Rust's ? operator does exactly that in one character: it unwraps an Ok and continues, or returns the Err immediately from the enclosing function — the biggest ergonomic win Result has over Erlang's tagged-tuple convention.

Erlang models "one of several shapes" as differently-tagged tuples, distinguished by their first element and arity at match time. Rust's enum Shape { Circle(f64), Rectangle(f64, f64) } formalizes exactly this pattern as a genuine, closed sum type — the compiler knows every variant, and a match missing one is a compile error, not a runtime surprise.

An Erlang atom like ok is an unstructured constant from a global, unbounded namespace of possible atoms. Rust's enum Status { Ok, Failed } gives the same "one fixed named value" idea but scoped and typed — a Status can only ever be Status::Ok or Status::Failed, never an unrelated value that happens to share the name.

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. Rust's struct Point { x: i32, y: i32 } introduces a genuinely distinct type the compiler will never confuse with an unrelated two-field struct.

Erlang has no notion of a method — every function is a free function at module scope, and "the record it operates on" is just its first ordinary argument by convention. Rust's impl Rectangle { fn area(&self) -> f64 { ... } } attaches the function to the type, callable as rectangle.area() — genuinely new syntax with no Erlang equivalent.

Erlang's per-process garbage collector is invisible and automatic — you never think about when memory is freed. Rust has no garbage collector whatsoever: every value has exactly one owner, and the compiler inserts the deallocation at the precise point that owner goes out of scope. This is the single biggest new concept for an Erlang developer, because Erlang gives you no equivalent mental model to build on — there is simply nothing like it to compare against.

This has no Erlang analogue at all: assigning original to moved does not copy the vector and does not create a second independent binding — it moves ownership, and the compiler forbids using original afterward. Erlang variables, once bound, can be referenced from anywhere, as many times as you like, forever — there is no notion of a binding becoming invalid.

Erlang passes values to functions freely — nothing is ever "used up" by a function call, because nothing is ever mutated or moved. Rust's &numbers (a borrow, or reference) achieves the same "still usable afterward" result, but by explicit design: print_length only gets temporary, read-only access, never ownership, so numbers remains valid in main after the call returns.

Erlang lists are singly-linked cons cells — cheap to prepend, linear to index. Rust's Vec<T> is a contiguous, growable array — cheap to index, and there is no [Head | Tail] pattern; split_first() is the closest equivalent, returning an Option since an empty vector has no first element to split off.

Both languages call these map and filter. Rust's iterators are lazy — .iter().map(...).filter(...) builds up a pipeline that does no work until .collect() actually drives it, unlike Erlang's lists:map/2, which eagerly builds a brand new list at every single step.

The base case and recursive case survive the translation intact, expressed as match arms rather than separate clauses. Unlike Erlang's BEAM, Rust's compiler does not guarantee tail-call optimization — deep recursion in Rust can genuinely overflow the stack, where idiomatic Erlang leans on the BEAM's guaranteed tail-call elimination without a second thought.

Both languages treat functions as ordinary values — Erlang funs and Rust closures (|x| x + 1) are equally first-class. Rust's F: Fn(i32) -> i32 generic bound is the type system spelling out, in detail, something Erlang leaves entirely implicit: exactly what kind of callable function must be.

Erlang closures always capture the enclosing variables' values directly — there is only one way to do it, and since values never change, it is never ambiguous. Rust closures must choose (or let the compiler infer) whether to capture by reference or by move (taking ownership) — move |y| x + y explicitly takes ownership of x so the closure can safely outlive make_adder's own stack frame.

Erlang's spawn/1 and Rust's thread::spawn share a name and a rough shape, but not the isolation guarantee. Erlang processes share nothing — a crash cannot corrupt another process's state, by construction. Rust threads run in the same address space and CAN share memory, though Rust's ownership rules (specifically the Send/Sync traits) enforce at compile time that any sharing is done safely — a fundamentally different mechanism reaching for a related guarantee.

Erlang gives every process an implicit mailbox that any other process can ! into. Rust's std::sync::mpsc ("multiple producer, single consumer") channel is explicit — you create the sender/receiver pair yourself and pass the sender to whichever thread needs it, rather than every thread automatically having an inbox the way every Erlang process does.

Both crash loudly on a genuine bug rather than silently limping onward — a Rust panic! unwinds the current thread, much like a crashing Erlang process. The scope differs: an Erlang process crash is a first-class, expected event that a supervisor is specifically designed to notice and recover from; a Rust panic! is treated as exceptional, catch_unwind is rarely used in ordinary code, and idiomatic Rust reaches for Result to handle anything genuinely expected to fail.

Both describe "a contract this type/module must satisfy," but the enforcement differs sharply. Erlang's behaviours (like gen_server) are a convention checked only loosely (a compiler warning if a callback is missing, not a hard error) and only matter once the behaviour is actually invoked. Rust traits are enforced fully at compile time — impl Greet for Person without a greet method simply does not compile, and nothing can call .greet() on a type that never implemented the trait.

Erlang variables genuinely cannot be rebound within a scope — it is a match failure, enforced everywhere, with no opt-out. Rust's let is immutable by default too, but — unlike Erlang — offers an explicit escape hatch: let mut x permits real, in-place reassignment, something no Erlang variable can ever do.

Both ecosystems bundle project creation, compiling, running/testing, and producing a deployable artifact behind one command-line tool. Cargo is a first-party tool shipped with the language itself (no separate install), the same relationship Go's go command has to Go — where Erlang's rebar3 is a separate, community-maintained tool installed on top of the language.