Erlang.CodeCompared.To/Go

Erlang prints with io:format/1 and the ~n directive for the newline. Go's fmt.Println appends the newline automatically, but needs an explicit import "fmt" — there is no automatically-available prelude the way Erlang's io module is always reachable.

Erlang's ~p ("pretty print") directive renders any term for humans. Go's %v ("value") verb inside Printf plays the closest role, printing a sensible default representation of nearly any value — though unlike Erlang, Go has no single term type that covers both a tag and a list at once, so this drops the ok wrapper Erlang's tuple carried.

Erlang has no compile-time type checking at all — Add("two", 3) would compile and only fail once that exact line executes. Go's func add(x int, y int) int means add("two", 3) is rejected at compile time — caught before the program runs, not discovered live.

Go's := infers the type of a local variable from its initializer, so result needs no annotation — reading almost as unadorned as Erlang. Unlike Haskell or Scala, though, Go's inference stops there: function parameters and return types are always written out explicitly, and Go has no Hindley-Milner-style inference across function boundaries.

This is the biggest structural loss moving from Erlang to Go: there is no pattern matching at all, anywhere in the language. Go's switch without an operand (each case is its own boolean condition) is the closest replacement for Erlang's guarded case — but it is testing conditions, not destructuring a shape the way Erlang's case/function clauses do.

Erlang's {point, X, Y} = Point destructures a whole tuple into named variables in one motion. Go has no equivalent syntax at all — every field must be accessed individually as point.X, point.Y. This single gap is the biggest everyday adjustment for an Erlang developer, showing up in nearly every function that used to be a one-line pattern match.

Erlang selects among several complete function bodies by matching the call against each clause head. Go allows exactly one function body per name — every "which case is this" decision has to be made with ordinary if/else or switch statements inside that single body, rather than the language choosing a clause for you.

Erlang bundles success-or-failure into one tagged tuple, {ok, Value} or {error, Reason}. Go spreads exactly the same information across two separate return values instead: the last one is conventionally an error, nil on success. Both idioms exist for the identical reason — make failure an ordinary, inspectable value instead of an exception — just packaged differently.

Neither language's compiler forces you to handle the failure case — Erlang discovers a skipped check only when a badmatch actually crashes the process; Go lets you discard err with _ and silently continue with a meaningless zero value, with no crash and no warning at all. This is a real weak spot in Go's design that linters (errcheck) exist specifically to patch — Go's type system, unlike Haskell's or Scala's, does not make ignoring an error a type error.

Erlang's -record(point, {x, y}). is compile-time sugar for a tagged tuple — nothing at runtime distinguishes it from any other tuple of the same shape. Go's type Point struct { X int; Y int } introduces a genuinely distinct, named type — the compiler will never let a Point be confused with an unrelated two-field struct, even one with identical field types.

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. Go's receiver syntax, func (r Rectangle) Area() int, attaches the function to the type itself, callable as rectangle.Area() — a genuinely new piece of syntax with no Erlang equivalent.

Erlang lists are singly-linked cons cells — cheap to prepend, linear to index. Go's slice is a different data structure entirely: a contiguous, resizable view over an array — cheap to index and iterate, but a genuinely new concept an Erlang developer has to learn (there is no [Head | Tail] pattern; you slice with numbers[1:] instead).

Erlang's lists:map/2 and lists:filter/2 are built-in higher-order functions. Go's standard library only added a generic slices package recently and idiomatic Go still very often reaches for a plain for range loop with manual append instead — a real style difference, not just a syntax one: Go code tends to be more explicit about the mechanics of iteration where Erlang code describes the transformation directly.

Erlang's map syntax #{Key => Value} and Go's map[KeyType]ValueType{...} literal both give a genuine hash map. The key difference: Erlang maps are heterogeneous (any term can be a key or value), while Go maps are homogeneous and statically typed — every key must be string, every value must be int, enforced at compile time.

The recursive structure survives the translation intact — a base case and a recursive case. What is lost is the clause-per-case readability: Go collapses both cases into one function body with an explicit if, where Erlang keeps them as two separate, self-documenting clauses.

This is a genuine, important difference. Erlang's BEAM guarantees every tail call is optimized into a loop — an Erlang developer can write deeply recursive, accumulator-passing code with total confidence it runs in constant stack space forever. Go's specification makes no such promise, so idiomatic Go generally reaches for an explicit loop wherever Erlang would reach for tail recursion, rather than relying on an optimization the compiler is not obligated to perform.

Both languages treat functions as ordinary values — Erlang funs and Go function literals (func(x int) int { ... }) are equally first-class. Go's func(int) int is a function-type annotation, making explicit in the type system something Erlang leaves entirely implicit.

Here the languages genuinely diverge: an Erlang closure captures its enclosing variables' values, and since those values can never change, calling the returned fun repeatedly always produces the same result. Go closures capture variables by reference, and because Go allows real mutation, counter() called twice returns 1 then 2 — genuine mutable state trapped inside a closure, something no Erlang closure can express.

Erlang's spawn/1 and Go's go keyword both launch a new, independently-scheduled lightweight unit of concurrency in one word. The extra sync.WaitGroup ceremony in the Go example exists only because main would otherwise exit before the goroutine gets a chance to run — Erlang has no equivalent problem in this sandboxed context since the shell evaluator processes expressions to completion before moving on.

This is the single most important thing to unlearn moving from Erlang to Go. Erlang processes share absolutely nothing — the only way to interact is ! and receive, which is precisely what makes a crashed process incapable of corrupting anything outside itself. Goroutines run in the same address space and share memory directly, so anything touched by more than one goroutine (like counter above) needs an explicit sync.Mutex — the exact category of bug (data races, corrupted shared state) that Erlang's process isolation makes structurally impossible.

Erlang gives every process an implicit mailbox — any process can ! (send) to it, and receive pattern-matches to pick a specific message out of the queue. Go's channel is an explicit, typed conduit you must create with make(chan T) and pass to whichever goroutines need it — there is no implicit "the current goroutine's inbox" the way every Erlang process automatically has one.

Erlang's receive can selectively pluck a specific message shape out of a single mailbox, leaving other queued messages untouched for a later receive. Go has no equivalent to a mixed-message mailbox with pattern-based filtering — the idiomatic Go answer is usually a separate, distinctly-typed channel per kind of message, as shown, since one Go channel only ever carries one type.

Go's select statement is the direct structural analogue of Erlang's multi-clause receive: both block until exactly one of several possible incoming messages is ready, and both run only the branch matching whichever arrived. The difference is granularity — Erlang matches on the shape of a message from one shared mailbox, while Go's select chooses among entirely separate channels.

Go's panic/recover pair is philosophically close to Erlang's "let it crash": a panic unwinds the current goroutine's call stack looking for a recover, much like a crashing Erlang process looks for its supervisor. The big difference is scope — Go's recover is called explicitly inside a defer in the SAME goroutine, a manual, local mechanism, where Erlang's supervision tree is a separate, structural part of OTP that restarts a whole different process automatically, with no manual recover-equivalent call required anywhere.

OTP's supervisor behaviour — declaring which children to restart, how often, and under what strategy (one_for_one, one_for_all, and so on) — is a first-class, battle-tested part of Erlang's standard library. Go has nothing built in that plays this role; if you want a crashed goroutine automatically relaunched, you write that restart loop yourself, or reach for a third-party library — there is no OTP-equivalent shipped with the language.

Erlang has no null concept whatsoever — undefined is just a regular atom, with zero special compiler treatment. Go, like most C-descended languages, has a genuine nil that pointers, slices, maps, channels, and interfaces can all hold — and dereferencing a nil pointer panics at runtime exactly the way you would expect, something Erlang's type of "absence" cannot even attempt.

Erlang requires every variable to be bound by a matching expression before it can be used — there is no notion of a variable existing but "empty." Go gives every type an automatic zero value (0 for numbers, "" for strings, false for booleans, nil for pointers/slices/maps) so a declared-but-unassigned variable is always immediately usable — convenient, but a real source of Go bugs when a zero value is silently mistaken for meaningful data.

Erlang variables genuinely cannot be rebound within a scope — it is a match failure, not silent mutation. Go's = (after the initial := declaration) is ordinary, unrestricted reassignment, no different from most mainstream languages — there is no Erlang-style single-assignment discipline anywhere in Go by default.

Both ecosystems bundle project creation, compiling, running, and testing behind one command-line tool. The philosophical difference: Go's tooling is a single first-party binary shipped with the language itself (no separate install, no competing build tools), where Erlang's rebar3 (or the alternative mix shared with Elixir) is a separate, community-maintained tool you install on top of the language.