Kotlin.CodeCompared.To/Elixir

No main, no class, no braces, and no semicolons — the file body is the program. IO.puts prints a string; IO.inspect prints any value in its literal form (and returns it, so it drops into the middle of a pipeline without disturbing it), which is the one you will actually use for debugging. String interpolation is #{…}, which is the Ruby heritage showing — José Valim came from Rails, and the surface of the language is deliberately friendly. What is underneath it is not Ruby at all.

A module holds functions and nothing else — no fields, no constructor, no instance. That is the single biggest structural change from Kotlin: you do not build an object that owns some state and then send it messages; you write functions that take data in and return new data out. Elixir's equivalent of "an object with state" is a process, which lives at the far end of this page, and it is a much bigger hammer than a class. Everything in between — the vast majority of your code — is plain functions over plain data.

Data is immutable, full stop: Map.put returns a new map, [0 | numbers] returns a new list sharing structure with the old. Rebinding a name is allowed (counter = counter + 1 is fine), which trips people who expect a purely functional language to forbid it — but the value the old name pointed at is untouched, so nobody else observes the change. This is what makes the concurrency model at the bottom of this page work: a value handed to another process cannot be changed by anyone, so there is no shared state to protect and no lock to take.

Read {1, second} = point as an assertion, not an assignment: it says "this had better be a two-tuple starting with 1", binds second, and raises a MatchError if it is not. That is why so much Elixir code has no defensive checks — the match is the check, and it fails at the exact line where the data stopped being what you thought. The pin operator ^ is the one piece of syntax to memorize: without it, expected = x rebinds expected; with it, ^expected = x compares. Everything else on this page — function heads, case, with, receive — is this one operator wearing a different hat.

A map pattern matches a subset of the keys — %{name: name} = user succeeds even though user has other keys — which makes it the natural way to accept a "record with at least these fields", and it is why so little Elixir code needs a declared type. Lists match with [head | tail], and that pattern is the whole of list recursion. Kotlin's destructuring is positional, one level deep, and only works where componentN exists, so the equivalent is a chain of property accesses. The same pattern language works in every binding position here: =, function heads, case, for, receive.

Atoms do the job Kotlin gives to enums and (badly) to strings: a name that is a value, interned, compared by identity, needing no declaration. nil, true and false are themselves atoms, which means nil is an ordinary value rather than a hole in the type system — and since there is no type system, you get no null safety, no ?., and no compiler telling you a value might be absent. What you get instead is that nil is matchable: functions dispatch on it, case branches on it, and the {:ok, value} | {:error, reason} convention in the next concept means most functions never return a bare nil in the first place.

The tagged tuple carries what a nullable type cannot: why it failed, in as much structured detail as you like ({:error, {:not_found, id}}), with no exception class to declare and no Throwable to unwrap. Because the caller matches on the shape, a forgotten error branch is a CaseClauseError at that line rather than a nil that flows onward and explodes somewhere else — which is the failure mode Kotlin's ? exists to prevent, reached by an entirely different road. The ! convention is the escape hatch: Map.fetch/2 returns a tuple, Map.fetch!/2 raises, and the bang in the name is the whole documentation.

Two collection types where Kotlin has one, and the distinction matters. A map is the hash map: unique keys, O(log n) access, and the %{map | key: value} update syntax, which — unlike Map.put — requires the key to already exist and so catches a misspelled field at run time. A keyword list is an ordered list of {atom, value} pairs that allows duplicates, and its only real job is to be the last argument of a function: connect("example.com", secure: true) is a keyword list with the brackets omitted, which is how Elixir gets something that reads exactly like Kotlin's named arguments with defaults.

The pipe is Kotlin's dot chain with the receiver moved outside the function: x |> f(y) is f(x, y). That is why every function in the standard library takes its subject as the first argument — the convention exists to make the pipe work, and your own functions must follow it or they will not compose. The capture syntax is the other half: &String.upcase/1 passes a named function (the /1 is its arity, which is part of its identity here), and &(&1 * 2) is the short lambda where &1 plays the role of Kotlin's it. Slipping IO.inspect(label: …) into the middle of a pipe is the debugging idiom you will use forever.

The functions are all in one module rather than on the type, so the call is Enum.map(collection, function) — and it works on anything implementing the Enumerable protocol: lists, ranges, maps, streams, and your own structs. The vocabulary maps over cleanly (fold is reduce, partition is split_with, associateWith is Map.new), with one caution worth internalizing: the accumulator comes after the element in Enum.reduce's function, which is the reverse of Kotlin's fold and will catch you at least once.

Stream is asSequence() and Enum is the eager version — the split is exactly Kotlin's, down to the fact that a lazy pipeline does nothing until a terminal operation (any Enum call) forces it. The rule of thumb is the same too: reach for Stream when the collection is large, infinite, or expensive to produce (a file read line by line is the canonical case), and stay with Enum otherwise, because for a small list the laziness costs more than it saves.

Note the false friend: Elixir's when is a guard attached to a clause, not Kotlin's multi-branch expression — the multi-branch job is done by writing several clauses. Guards are restricted to a fixed list of pure, fast checks (is_integer, comparisons, arithmetic), because the compiler needs to decide them without side effects; you cannot call your own function in one. The payoff is that dispatch, destructuring, and the base case of a recursion all live in the function head, which is why idiomatic Elixir has so few ifs. What you lose is exhaustiveness: nothing warns you that no clause matches a shape, and the result is a FunctionClauseError at run time.

A function's identity is its name and its arity, written greet/1 — so greet/1 and greet/2 are two different functions, and every error message, doc page and stack trace will refer to them that way. Default arguments (\\) are sugar that generates the extra clause. The other thing to get used to: calling an anonymous function needs a dot (greeter.("Alan")), because a variable holding a function is not the same kind of thing as a named function — a distinction Kotlin does not draw and Elixir cannot avoid, since a bare name is a function call with no parentheses.

Kotlin's one when splits three ways: case matches a value against patterns (with guards), cond takes a list of conditions with no subject, and if is a two-branch expression that idiomatic Elixir mostly avoids in favor of function clauses. All three are expressions, so they return values. Two details: cond's else branch is spelled true, and an unmatched case raises a CaseClauseError rather than returning null — which is the recurring theme here, that failure is loud and immediate instead of silently absent.

with reads the happy path top to bottom and lets every failure fall out sideways, carrying its own reason — which is what the Kotlin ladder cannot do, since ?: can only produce a fallback, not propagate the cause. It is pattern matching all the way down: each <- is a match, and a mismatch short-circuits the whole block to the unmatched value (the else is optional — without it, with simply returns whatever failed). Kotlin's closest equivalents are an early-return ladder, a chain of nullable lets, or Arrow's either { } block, which exists to import exactly this shape.

A struct gives you the data-class payoff — named fields, defaults, value equality, and %{struct | field: value} as copy() — with one structural difference: the functions live beside the data, not on it, so you call Person.greeting(ada) rather than ada.greeting(). That looks like a downgrade until you notice it pipes. Two things a struct will not do: it cannot be missing a key (the set is fixed at compile time, which catches typos the plain-map version would not), and it enforces nothing about the types of those fields — %Person{name: 42} is perfectly legal.

A protocol is dispatched on the runtime type of its first argument, and defimpl can implement it for any type — including Integer, List, and structs from libraries you did not write. That is the type-class-shaped feature Kotlin approximates with extension functions, and the gap shows in the last block: extension functions are resolved statically, so a Kotlin extension on Int is invisible when the value arrives as Any from a heterogeneous list, while the protocol simply works. The built-in protocols are the ones you will implement in practice — String.Chars (what to_string uses), Inspect (what IO.inspect uses), and Enumerable (what makes your type work with the whole Enum module).

Elixir has exceptions (raise/rescue/after, and defexception to declare one), and it would rather you did not use them for anything you expect to happen. Expected failure is a {:error, reason} tuple, because it is a value — it can be matched, piped, stored, and returned, and the compiler-free equivalent of a signature tells the caller it exists. An exception is reserved for the genuinely exceptional: a bug, a broken invariant, a disk that is not there. And here the philosophy turns strange to Kotlin eyes, because the standard response to an exceptional condition is not to catch it at all — see the next concept, and then the Supervision section, where crashing is the design.

The reason "let it crash" is not recklessness is isolation: a process has its own heap, so a crash cannot corrupt anyone else's data, and by default it takes nothing else down with it. Compare the Kotlin column, where an uncaught exception in an async child cancels the whole coroutineScope — sibling work included — which is exactly why defensive try/catch ends up sprinkled through coroutine code. The Elixir position is that defensive code for unforeseen failures is a fantasy (you cannot catch a bug you did not anticipate), so the only robust answer is to let the failed thing die and restart it from a state you know is good. Which requires something watching. That is a supervisor, and it is the next section.

A coroutine is a cheap unit of scheduling over shared memory; a process is a cheap unit of isolation. Nothing is shared, so a message send copies the value (cheap, because the value is immutable and small; and the copy is exactly what makes the isolation real), and there is no lock, no @Volatile, no Mutex, and no shared-state bug to write. Two more differences with teeth. Scheduling is preemptive: the BEAM interrupts a process after a fixed budget of work, so a tight CPU loop cannot starve anything — where a Kotlin coroutine that never suspends will happily hog its thread, which is why Dispatchers.IO and yield() exist. And every process has a PID, which is its entire interface: no methods, no handle, just an address you send to.

A mailbox is not a channel. It belongs to the process rather than sitting between two of them, it is untyped, and receive selects by pattern — so a process can pull an urgent message out of the middle of its queue and leave the rest for later, which a FIFO Channel simply cannot do. That selectivity is the mechanism behind GenServer's call/cast split and the whole of OTP. The cost is the mirror image: because a mailbox is unbounded and untyped, a slow consumer grows it without limit (the classic BEAM production failure) and a message nobody matches sits there forever, where Kotlin's Channel<T> gives you a type, backpressure, and a close().

The state lives in loop/1's argument and in nothing else. It is reachable only by sending the process a message, and the process handles one message at a time — so mutual exclusion is not something you added, it is the shape of the thing. This is a Kotlin Mutex-protected field with the mutex removed and the possibility of forgetting it removed with it. The tail call in loop costs no stack, so a process can loop forever. And note how much boilerplate this is for a counter: send, receive, match, reply, recurse. That is exactly the boilerplate GenServer exists to delete.

A GenServer is the recursive loop from the previous concept with the plumbing generated: call is a synchronous request that waits for a reply (with a five-second default timeout), cast is fire-and-forget, and the state is threaded through the handle_* callbacks as their last argument and returned as part of the result. The split to keep straight is which code runs where: increment/1 runs in the caller's process and merely sends a message, while handle_call/3 runs inside the server, serialized with every other message. That serialization is the lock in the Kotlin column — except that it cannot be forgotten, cannot deadlock against another lock you also took, and comes with supervision for free.

The supervisor is the answer to "then who catches the exception?" — nobody does. The worker crashes, the supervisor is notified (it is linked to it), and it starts a fresh one from init/1, which is a state known to be good because it is the state the program started in. Failures do not have to be anticipated for this to work, which is the entire point: it recovers from the bug you did not think of. The knobs are the restart strategy (:one_for_one restarts just the dead child; :one_for_all restarts the whole group when any one dies, for children whose state is coupled) and a restart intensity — too many crashes too fast and the supervisor gives up and dies itself, escalating to its supervisor. That is the tree, and it is why a BEAM system degrades in a small area instead of falling over. Kotlin's structured concurrency is genuinely good at the other half of this problem — deterministic cancellation and cleanup — but it has no notion of restart, so the retry policy, the backoff, and the "known-good state" are all yours to design.

Task.async/Task.await is the closest thing on this page to a straight translation of async/await — and it is genuinely parallel, since the BEAM schedules processes across every core with no GIL and no Dispatchers.Default to choose. Two differences to hold onto. A Task is linked to its caller, so if the task crashes, the caller crashes too (that is the default, and usually what you want: a broken sub-computation should not leave a half-finished parent limping on). And Task.await's timeout exits the caller rather than returning null, which is why the fallback above is a catch :exit and not a ?: — the BEAM's answer to a stuck task is to kill something, not to paper over it. Use Task.yield/2 when you genuinely want to wait and keep going.