Ruby.CodeCompared.To/Elixir

Both languages print to standard output with a one-word call. Elixir's IO.puts/1 lives in the IO module — there is no top-level puts the way Ruby has Kernel#puts — but the call reads almost identically. The /1 you will see in Elixir docs means "arity one": functions are identified by name and argument count.

This is the deepest difference between the two languages. In Ruby, << mutates the array in place. Elixir values are immutable: ++ builds a brand-new list and the original numbers is untouched. Nothing you can write in Elixir will ever change a value another part of the program is holding — the foundation that makes its concurrency safe.

The line count = count + 1 looks the same in both, but means something different. In Ruby the variable's object may change; in Elixir the value 1 is immutable and can never change — you are simply rebinding the name count to a new value. The old value is untouched; anything else pointing at it still sees 1.

Like Ruby, Elixir has no return keyword in idiomatic code — a function returns the value of its last expression, and if is an expression that evaluates to one branch or the other. A Rubyist already writes this way; Elixir simply makes it the only way.

Elixir's = is the match operator, not assignment. The right-hand side is matched against the pattern on the left, binding any variables in it. Ruby's parallel assignment first, second = pair is the closest analog, but in Elixir the left side is a full structural pattern: the [ ] is required, and the shapes must line up or the match fails.

A map pattern matches on a subset of keys, binding exactly what you name. This is the everyday way to pull fields out of a map in Elixir, and it is the same mechanism used in function arguments, case, and with — one idea reused everywhere.

Because = asserts a shape, a mismatch raises a MatchError rather than silently binding nil. Matching against a tagged tuple like {:ok, value} is the idiomatic way to say "I expect success, and I want the payload" — the pattern doubles as a runtime assertion.

Since a bare variable on the left of = is bound, not compared, Elixir needs the pin operator ^ to say "use the existing value of this variable as part of the pattern." Ruby has no equivalent because it has no matching — it only ever assigns.

An Elixir atom is exactly Ruby's Symbol: a constant whose name is its value, written with a leading colon. Atoms are used constantly in Elixir — as map keys, as status tags like :ok and :error, and as the names of modules and functions.

Where Ruby has dedicated TrueClass, FalseClass, and NilClass, Elixir's true, false, and nil are simply the atoms :true, :false, and :nil with nicer spelling. There are no boolean or nil objects — just atoms all the way down.

Here Ruby and Elixir agree completely, and it is worth stating because it trips up newcomers from other languages: only false and nil are falsy. The number 0, the empty string, and the empty list are all truthy. Elixir adds strict boolean operators (and, or, not) that require actual booleans, alongside the Ruby-like &&, ||, and ! that work on any value.

A sharp difference: in Elixir the / operator always returns a float, even for two integers, so 17 / 5 is 3.4. Integer division is the named function div/2, and the remainder is rem/2 rather than Ruby's %. This removes the "is this / integer or float?" ambiguity that Ruby resolves by operand type.

Both languages let you group digits with underscores for readability and both have arbitrary-precision integers, so 2 ** 64 is computed exactly with no overflow. Elixir borrowed the _ digit separator directly from Ruby, and its ** power operator behaves the same.

Elixir's Integer.parse/1 returns a {number, leftover_string} tuple rather than raising on trailing junk — a recurring Elixir theme of returning data you can match on instead of raising. Integer.to_string/2 takes a base, mirroring Ruby's to_s(16).

Elixir copied Ruby's #{} interpolation syntax verbatim — one of the most visible signs of its Ruby heritage. Under the hood the two are very different: an Elixir string is a UTF-8 binary (a sequence of bytes), not an object with methods.

Strings are joined with <> (the binary-concatenation operator), not +. Because + in Elixir is strictly numeric, using it on strings raises an ArithmeticError — the language refuses to guess whether you meant to add or to join.

Ruby calls methods on the string object; Elixir passes the string to functions in the String module. Note that String.length/1 counts graphemes, so the accented "héllo" is length 5 — Elixir is Unicode-correct by default, just like modern Ruby.

Splitting lives in the String module, but joining lives in Enum — because once you have split a string you hold a plain list, and joining is a list operation. This split of responsibilities (string functions vs. collection functions) is characteristic of Elixir's design.

A Ruby Array is a contiguous, index-addressable buffer; an Elixir list is a singly-linked list. That is why the idiomatic way to take it apart is the [head | tail] pattern rather than numbers[0] — reaching the head is instant, but indexing into the middle means walking the links.

Because lists are linked, prepending with [element | list] is instant and cheap, while appending must copy the whole list. Elixir programs are written to grow lists at the front and reverse once at the end — the opposite of the "push onto the end" habit a Rubyist brings.

Elixir distinguishes lists (variable length, walked front-to-back) from tuples (fixed length, stored contiguously and indexed in constant time with elem/2). The convention is: tuples for a known handful of related values — especially the ubiquitous {:ok, value} and {:error, reason} — and lists for sequences you iterate.

An Elixir map is Ruby's Hash: a key–value store written with %{} and the => rocket that Ruby also uses. Any value can be a key, and lookup with map[key] returns nil for a missing key, exactly as in Ruby.

When every key is an atom, Elixir offers the shorthand %{name: "Ada"} (the same key: sugar Ruby uses for symbol keys) and a special power Ruby lacks: person.name dot-access. The dot form raises if the key is missing, making it a good fit for structs where the shape is known.

The %{map | key: value} syntax returns a new map with an updated key — and it will only update keys that already exist, raising otherwise, which catches typos. Since maps are immutable, the original person is untouched; there is no in-place []= the way Ruby hashes allow.

A keyword list — a list of {atom, value} tuples with sugar so you can write color: "red" — is Elixir's version of Ruby's trailing options hash. Passed as the last argument, the brackets are optional, so draw("circle", color: "red") reads just like Ruby keyword arguments while being an ordinary list underneath.

Ruby chains methods on an object; Elixir has no objects, so the pipe |> threads a value through free functions, feeding it as the first argument to each. x |> f(y) is exactly f(x, y). The result reads like Ruby's method chain and is the single most beloved feature of the language.

Elixir's Enum.reduce/3 is Ruby's inject/reduce, with one thing to watch: the accumulator is the second parameter of the function (fn element, acc), the reverse of Ruby's { |sum, n| } order. Nearly every other Enum function — map, filter, each, find — matches Ruby closely.

The for comprehension combines mapping and filtering in one expression: number <- 1..5 is the generator, rem(number, 2) == 0 is a filter, and do: is the transformation. Ruby has no comprehension syntax, so this compact form — familiar from Python and Haskell — is a small delight for the Elixir side.

The Enum module is as rich as Ruby's Enumerable: group_by, chunk_every, frequencies, zip, flat_map, and dozens more are all present with familiar names. A Rubyist's collection instincts transfer almost one-to-one.

Elixir's case matches a value against a series of patterns — precisely what Ruby 3's case/in pattern matching does, an idea Ruby borrowed back from languages like Elixir. Each clause both tests the shape and binds variables (code) from within it.

A guard (when n > 0) adds a boolean test to a pattern. Combined with multiple function clauses, guards replace most if/elsif ladders: Elixir picks the first clause whose pattern and guard both hold. This is the language's signature style — dispatch by shape and condition, not by branching inside one body.

When the branches are arbitrary boolean expressions rather than patterns, cond is the tool — it is Elixir's if/elsif/else ladder. The final true -> clause is the catch-all else; without it, a cond that matches nothing raises.

The with expression chains several matches, running the do block only if every step matches; the first failing match short-circuits to the else. It is the idiomatic replacement for deeply nested cases or Ruby's early-return guards, and it keeps the happy path flat and readable.

An anonymous function is written fn args -> body end and — crucially — must be invoked with a dot: double.(21). The dot is Elixir's visible line between calling a named function (foo(x)) and calling a value that holds a function (foo.(x)). Ruby's lambda.(x) shorthand is the same idea.

The capture operator & is a terse way to build a function: &Integer.to_string/1 captures an existing named function (like Ruby's &:to_s), while &(&1 * 2) builds a new one where &1 is the first argument. It is the compact cousin of fn, used heavily in pipelines.

Default argument values use the \\ operator (greeting \\ "Hello") instead of Ruby's =. The behavior is identical — omit the argument and the default fills in — but the different syntax exists because = is already spoken for as the match operator.

Rather than branching inside one body, Elixir lets you write a function as several clauses, each with its own pattern; the runtime tries them top to bottom. Defining fib(0) and fib(1) as their own clauses expresses the base cases as data patterns — a style that reads like a mathematical definition.

A defmodule is a namespace for functions — closest to a Ruby module full of module-methods. Every function must live in a module (there are no free-floating top-level defs), and def makes it public while defp makes it private. There is no self. because there is no instance to belong to.

Nested module names use dots (Strings.Helper). alias shortens a long name, and import pulls a module's functions into scope so you can call shout(...) unqualified — roughly Ruby's include, but for plain functions rather than mixed-in instance methods.

A module attribute like @pi defined at the module level acts as a compile-time constant, the rough equivalent of a Ruby PI = ... constant. Attributes are also how Elixir attaches documentation (@doc), behaviour declarations, and other metadata to a module.

A struct is a map with a fixed set of fields and default values, tagged with its module name. It is the closest thing Elixir has to a Ruby object's state — but it is only data: there are no methods inside it, no initialize, and no behavior. Fields are accessed with dot syntax and missing fields are a compile-time error.

This is the heart of "no objects." Ruby bundles state and behavior and lets deposit mutate self. Elixir keeps them apart: deposit/2 is a function that takes an account and returns a new one. You rebind account to the result — the old value is never changed. Every "method" becomes a function whose first argument is the data it acts on.

Because a struct is data, you can pattern-match on it in a function head: %User{admin: true} matches only admin users. This replaces the if user.admin check with dispatch on the data's shape — the same technique used for tuples and maps, now applied to your own types.

Ruby's to_s lets any object define how it stringifies. Elixir's equivalent is implementing a protocol: defimpl String.Chars, for: Money teaches IO.puts and interpolation how to render a Money. Protocols are Elixir's answer to "add behavior to a type you did or didn't define" — polymorphism without reopening a class.

Where a Rubyist reaches for monkey-patching — reopening Array to add second globally — Elixir uses a defprotocol plus one defimpl per type. The difference is discipline: a protocol adds behavior explicitly, per type, and never silently changes a class out from under other code. (This example is not executed because user-defined protocols require a compile-time consolidation step the in-browser evaluator does not run; the built-in String.Chars example above does run.)

The idiomatic Elixir style is not to raise for expected failures but to return a tagged tuple — {:ok, value} or {:error, reason} — that the caller matches on. Reserved words like Map.fetch/2 return exactly these. Errors become ordinary data you handle with case, rather than exceptions that unwind the stack.

Elixir borrows Ruby's ! naming convention but gives it a precise meaning: a foo! function is the variant that raises on failure, while the bang-less foo returns {:ok, _}/:error or nil. So Map.fetch! raises, Map.fetch returns a tuple — you pick based on whether a missing value is a bug or an expected case.

Real exceptions exist for truly exceptional situations, and try/rescue mirrors Ruby's begin/rescue closely, right down to matching on the exception type and reading e.message. But in Elixir this is the rare path — most code prefers tagged tuples, and processes that crash are restarted by supervisors rather than wrapped in defensive rescue blocks.

This is why Elixir exists. A process is not an OS thread — it is a lightweight, VM-scheduled unit (millions can run at once) that shares no memory with any other. Processes communicate only by sending immutable messages that the recipient pulls from its mailbox with receive. No shared state means no locks, no races — the actor model, built into the language.

How can an immutable language have stateful counters? A process holds its state as an argument to a recursive loop: to "change" the count, it calls loop/1 again with a new value. The state lives in the process's own stack, reachable only through messages — so state exists, but no shared mutable memory does. This hand-rolled loop is exactly what GenServer and Agent package up for real code.

Every process is identified by a pid (process identifier). self() returns the current process's pid, and spawn/1 returns the new child's. A pid is the address you send messages to — and because a pid can point at a process on another machine just as easily as this one, the same message-passing code scales from one core to a distributed cluster.

The single most common Rubyist mistake: reassigning an outer variable from inside a loop. In Elixir the closure rebinds its own total, and the outer one is untouched — so the loop appears to do nothing. Because nothing is mutable, you must reduce to carry an accumulator through, or build a new collection with map. There is no such thing as "modify as you go."

In Ruby single and double quotes both make strings. In Elixir a double-quoted "hello" is a binary string, but a ~c"hello" charlist is a plain list of integer code points — a different type entirely, occasionally seen in Erlang libraries. Mixing them up is a classic early confusion; when in doubt, use double quotes.

Unlike modern Ruby symbols, Elixir atoms are never garbage-collected — they live for the life of the VM. Atoms written literally in your code are finite and safe, but converting untrusted input to atoms with String.to_atom/1 in a loop can exhaust the atom table and crash the node. Use String.to_existing_atom/1, or keep the data as strings.

A string, list, or map has no methods of its own — so "hello world".split is meaningless in Elixir. The pipe recovers the readability of Ruby's chains by threading the value through String and Enum functions. Once this clicks, the "data plus functions" model stops feeling like a limitation and starts feeling like clarity.