PHP.CodeCompared.To/Elixir

IO.puts appends the newline for you, which is why there is no \n here. Its sibling IO.write does not. The parentheses are optional in Elixir — IO.puts "Hello, World!" is the same call — but the community style guide asks for them everywhere except a handful of macros, so this page keeps them.

The detail that changes how you debug: IO.inspect returns its argument, so you can drop it into the middle of a pipeline without restructuring anything — list |> IO.inspect() |> Enum.sum() prints and carries on. print_r returns true (or the string, with its second argument), so it can never be spliced into an expression that way. Add label: to tell several inspects apart: IO.inspect(person, label: "before").

The reason is that iex can attach to a running system. An Elixir server keeps running between requests, so you can open a shell into production, inspect live state, and call functions on it — something PHP structurally cannot offer, because by the time you would look, the process that served the request is gone. The .exs extension means "script": it is compiled in memory each time. Compiled projects use .ex files and produce .beam bytecode.

Losing the $ costs you one real thing: PHP can tell a variable from a function call by looking at it, and Elixir cannot. A bare foo in Elixir is a variable if one is in scope and a zero-argument call to a local function otherwise, which is occasionally surprising and is why the compiler warns when you shadow a function name. The naming convention is snake_case for variables and functions, and CamelCase for module names only.

The difference is what happens with objects. $copy = $someObject in PHP copies a handle, so mutating through $copy is visible through the original; that is the bug class every PHP codebase has hit. In Elixir there is no such case, because no operation anywhere in the language modifies an existing value. copy ++ [4] does not append — it constructs a new list and rebinds the name copy to it. That guarantee is not a style preference; it is what makes it safe for thousands of concurrent processes to hold references to the same data, which is the subject of the Processes section below.

So {x, y} = point does two jobs at once — it destructures like PHP's [$x, $y] = $point, and it asserts that point really is a two-element tuple. The literal 3 in the second match is a pattern too, so that line is an executable claim about the first element. ^y is the pin operator: it says "do not rebind y, match against the value it already holds". Without the caret, y would simply be rebound and the assertion would be vacuous.

The distinction is between the name and the value. Rebinding greeting points the name at a different string; it does not reach into the old string and change it, so shout, which captured the result of the old one, is untouched. In practice you rebind far less than you reassign in PHP, because a pipeline usually replaces a sequence of reassignments. Erlang, Elixir's substrate, forbids rebinding entirely — Elixir relaxed that specifically because the Erlang style forces names like Numbers1, Numbers2, Numbers3.

Two properties make atoms carry so much weight. They compare in constant time regardless of length, because the runtime interns each one to an integer — so :some_very_long_status_name costs no more to compare than :ok, while two equal PHP strings are compared character by character. And they are self-describing without a class: you do not declare :ok anywhere, which is why library authors return {:ok, value} and {:error, reason} without first agreeing on a shared enum. The cost is that the atom table is never garbage collected, so never call String.to_atom on user input — use String.to_existing_atom, which raises rather than growing the table.

PHP's falsy list is famously long, and the entries that catch people are "0" — a non-empty string that is nonetheless falsy — and []. Elixir's list has exactly two entries: false and nil. Zero is truthy. The empty string is truthy. The empty list is truthy. If you are used to writing if ($items) to mean "if there are any items", that idiom silently stops working, because the empty list passes. Write if items != [], or unless Enum.empty?(items).

The convention is that a function which can fail returns {:ok, value} or {:error, reason}. Compare what PHP must do here: json_decode returns null on failure, but null is also the correct decoding of the input "null", so the two are indistinguishable and you have to call json_last_error() to tell them apart. A tagged tuple has no such ambiguity, and because case is a pattern match rather than a chain of comparisons, forgetting the error branch is a loud CaseClauseError rather than a null that travels three functions before it explodes. Tuples are for a known, small number of elements; use a list when the count varies.

Note that a string reports as a binary, which is literally what it is: a chunk of bytes, as the Strings section explains. There is no is_object because there are no objects — a struct reports as a map, which is what it is underneath. Two ordering details also differ from PHP: is_boolean must be tested before is_atom would match, since booleans are atoms; and in iex, i(value) is the interactive equivalent of gettype and prints a paragraph about any value you hand it.

A double-quoted Elixir literal is a binary — a UTF-8 byte sequence, and what everyone means by "string". A single-quoted literal is a charlist: an ordinary list of Unicode code points, which is what Erlang has always called a string. They are not interchangeable, they do not compare equal, and String.upcase will reject a charlist. Elixir 1.15 began asking for the explicit ~c"" sigil precisely because the bare single-quoted form misled so many newcomers. You will still meet charlists when calling Erlang libraries directly; List.to_string/1 and String.to_charlist/1 convert.

That refusal is the point. "age: " . 36 in PHP quietly stringifies, which is the same juggling that makes "1" == 1 true; "age: " <> 36 in Elixir is an ArgumentError, and you must say Integer.to_string(age). Interpolation is the exception — #{age} works on any value, because it calls the String.Chars protocol. ~S is the sigil for a string with no interpolation and no escape processing, which is what PHP's single quotes do.

The real difference is what is missing. PHP has strtoupper and mb_strtoupper, strlen and mb_strlen, because its original string functions are byte-oriented and Unicode support was bolted on as a separate extension you must remember to use — and which plenty of PHP builds do not compile in at all. Elixir has one of each, and it is always the Unicode-correct one: String.length("héllo") is 5 everywhere, with nothing to install and no prefix to remember. The question mark in contains? is a naming convention, not syntax; a trailing ! means "raises instead of returning an error tuple".

The naming tells you where each function lives in the mental model. byte_size is a plain kernel function on a binary — it is O(1), because a binary knows its own length. String.length is in the String module and walks the UTF-8, so it is O(n). That is the opposite of the PHP habit, where the cheap call is the one you reach for by default and the correct one costs an extension; here the correct one is the default and the cheap one is explicit. String.graphemes goes one level further than code points and groups combining marks, so an "e" followed by a combining accent counts as one.

That placement is not pedantry — it tells you where to look for related functions. Anything that takes a string and produces something is in String; anything that takes a list and reduces it is in Enum, alongside Enum.map and Enum.reduce. Both take the subject first, so there is no order to memorize, and that consistency is what makes the pipe operator work at all. String.split(line) with no second argument splits on whitespace, the way preg_split('/\s+/', $line) would.

Read the costs in the comments, because they drive Elixir style. A list is a singly linked list, so prepending is free and appending walks the whole thing — which is why idiomatic code builds lists backwards and calls Enum.reverse once at the end, and why there is no cheap $list[5]. A map is the general key-value store. A tuple is contiguous in memory, so indexing is instant but growing it copies. A keyword list is just a list of two-element tuples with atom keys, which is why it keeps insertion order and permits duplicates — it is what Elixir uses for optional function arguments, the role PHP fills with an associative array.

The symmetry is deliberate: [first | rest] on the left of a match takes a list apart, and [0 | numbers] on the right puts one together. Prepending is O(1) and, crucially, with_zero and numbers share the same three cells in memory — safe precisely because nothing can ever modify them. This shape is why so much Elixir is written as recursion over [head | tail], and why array_pop has no cheap counterpart: reaching the last element of a linked list means walking it.

The %{map | key: value} form is the update syntax, and it has a safety property worth knowing: it raises if the key does not already exist. That makes it a typo-catcher for records whose shape you believe you know, in exchange for being useless when you are adding a key — for that, use Map.put(person, :email, "a@b.c"). The dot access person.name also raises on a missing key, while person[:name] returns nil, which is the same split PHP has between $person["name"] (a warning and null) and $person["name"] ?? $default.

The practical rule: data from outside the system has string keys, data you wrote has atom keys. A decoded JSON body or a form submission arrives as %{"email" => …}, and if you write params.email you get a KeyError. That is deliberate, not an oversight — automatically converting incoming keys to atoms would let a hostile client fill the never-collected atom table. Phoenix's changesets do the conversion for you at a controlled boundary, which is where it belongs.

That last call reads as if the language had named arguments, and it is why nearly every Elixir library takes options this way. Underneath, separator: " | ", upper: true is exactly [{:separator, " | "}, {:upper, true}] — a list of tuples, which is why order is kept and why the same key may appear twice (Keyword.get returns the first). Use a keyword list for options and a map for data: options are a small fixed set written by a programmer, data is arbitrary and wants O(log n) lookup rather than a linear scan.

Read the pattern as a picture of the value, with holes. The underscore in [first_role | _] is the anonymous match — it accepts anything and binds nothing, and the compiler will not warn about it being unused. There is a second thing happening here that PHP's version does not do: a map pattern is a partial match, so this asserts the response has a status and a body with a name, and it raises immediately if the shape is wrong. The PHP version would sail past a missing body and hand you null to trip over later.

Notice that the PHP version has to index back into $result inside the arm, because matching on $result[0] threw away the connection to $result[1]. The Elixir branch binds value and reason as part of choosing the branch. Both languages raise when nothing matches — PHP an UnhandledMatchError, Elixir a CaseClauseError — which is the good behavior; switch falling silently through is the thing neither does.

cond is the tool for "several unrelated conditions, take the first true one" — exactly the shape of the PHP function beside it — and its final true -> is the else. Without it, no branch matching raises a CondClauseError. Guards are deliberately restricted: only a fixed list of side-effect-free operations is allowed, so you cannot call your own function in one. That looks limiting until you see why — a guard runs during matching, possibly many times, and the compiler must be able to prove it terminates and cannot alter anything.

The clauses are tried top to bottom, so order matters and the specific ones go first. There is no default branch here and that is deliberate: an unrecognized shape raises a FunctionClauseError naming the function and the argument that did not match, which is a better error than the InvalidArgumentException you had to remember to write. def name(args), do: body is the one-line form of def name(args) do … end. And notice the calls out to Erlang — :math and :erlang are Erlang modules addressed as atoms, which is how Elixir reaches the whole OTP standard library with no wrapper.

The consequence is that state which a PHP object would hold as a property becomes an explicit argument. That feels like a loss until you notice what it buys: any function can be called with any data, so there is no object to construct before testing, no partially initialized state, and no question of which methods are safe to call in which order. When you genuinely need state that persists and is shared, the answer is a process rather than an object — see the State section. Module names are CamelCase atoms; Greeter is really :"Elixir.Greeter", which is why calling Erlang modules looks like :math.pi().

The idiom above — a shorter arity that delegates to a longer one with a default filled in — is so common that Elixir has sugar for it: def greet(name, greeting \\ "Hello") defines both greet/1 and greet/2 in one line, and is what you would normally write. Seeing it spelled out is worth it once, because it explains an error message that puzzles newcomers: undefined function greet/1 when greet/2 is plainly defined right there. PHP has no equivalent, since a PHP function name is unique in its namespace regardless of parameters.

The dot is not decoration; it resolves a genuine ambiguity that PHP avoids with its $. Without a sigil, double(21) already means "call the local named function double/1", so there has to be some other spelling for "call the function this variable holds" — and that is double.(21). Note also that an Elixir anonymous function may have multiple clauses with patterns, which no PHP closure can do: fn {:ok, value} -> value; {:error, _} -> nil end. Capturing is automatic and by value; there is no use clause, because nothing captured could be mutated anyway.

&String.upcase/1 is a reference to a specific function of a specific arity, and the compiler will tell you at build time if it does not exist — the same guarantee as PHP's first-class callable syntax, with the arity spelled out. The second form is different and is the one you will write most: &(&1 <> "!") is shorthand for fn value -> value <> "!" end, where &1, &2 and so on are the positional arguments. It is best kept to a single short expression; past that, write the fn out.

The habit this breaks is the guard-clause style: if (!$user) return null; at the top of a PHP method, repeated four times before the real work starts. Elixir replaces it in one of two ways. For validation chains, with (in Control Flow below) reads like a series of early returns and is the direct answer. For dispatch on shape, multiple function heads do it — each clause is an early return, decided before the body runs. Once you stop looking for return, functions get shorter, because a function that wanted three early exits usually wanted to be three clauses.

This is why every Elixir standard-library function takes its subject first — String.split(string, pattern), Enum.map(collection, function), Map.put(map, key, value). That consistency is what makes pipelines composable, and its absence is exactly why PHP's array_map($fn, $array) and array_filter($array, $fn) cannot chain: the subject is in a different position in each. PHP 8.5 finally added a |> of its own, but it pipes into a single-argument callable rather than into a first parameter, so the two are not the same tool.

That is the difference between an open and a closed set. To add a step to the fluent version you must edit the class or subclass it; the Elixir pipeline can pass through Enum, String, a third-party library and a function you wrote five minutes ago, in any order, with no wrapper object and no ->all() at the end to unwrap. It also means there is nothing to construct: the value flowing through is a plain list the whole way, so any step can be tested on its own.

The Kernel.<> calls are here to make the mechanism visible, not because you should write them — in real code that last stretch would be one interpolated string. The rule they illustrate matters, though: a |> f(b, c) is exactly f(a, b, c), with no exceptions and no way to redirect the value into a different slot. When you need it elsewhere, stop piping and use an anonymous function: |> then(&String.replace(text, "x", &1)). Reaching for then often means the pipeline has ended and a named intermediate value would read better.

First, argument order: array_map takes the callback first and array_filter takes it second, an inconsistency every PHP developer has looked up. Every Enum function takes the collection first. Second, array_values: PHP's filter preserves the original keys, so removing element 0 leaves an array starting at key 1, which then serializes to a JSON object instead of an array — a bug so common it has its own Stack Overflow genre. Elixir lists have no keys, so nothing to renumber. Third, array_reduce puts the accumulator first in the callback while Elixir puts the element first — worth noting, since fn number, accumulator reads backwards to a PHP eye.

The quiet trick is that <- in a comprehension is a filtering match: an element that does not fit the pattern is skipped rather than raising, which is the one place in Elixir where a failed match is not an error. So active: true in the pattern is doing the work of the if. You can also write the condition separately — for person <- people, person.active, do: … — and several generators nest like nested foreaches. Note that for is not a loop: there is no index, no break and no continue, because it builds a value rather than repeating a statement.

Enum.group_by takes two functions: one that produces the key and one that produces the value to collect, so the second argument replaces the "pick the field" step you would otherwise do afterwards. Map.new then rebuilds the map with each list summed. The & &1.customer spelling is the capture shorthand from the Functions section — the space is required, since && is the boolean operator. The PHP version is shorter here, and honestly so; what the Elixir version buys is that each step is a value you can inspect on its own with IO.inspect in the middle of the pipe.

The rule that makes streams usable: everything in the Stream module is lazy and returns another stream, and everything in Enum is eager and forces the work. Nothing above runs until Enum.take(4), and then exactly enough runs to produce four results. That composability is what PHP's generators lack — chaining a filter onto a generator means writing another generator that loops over the first, which is why the PHP version has to fold the filter, the map and the limit into one loop with a break. The cost is per-element overhead, so for a list you already hold in memory, plain Enum is faster; reach for Stream when the source is huge, infinite, or a file being read line by line.

Assigning the construct instead of assigning in each branch removes a whole error class: there is no path through this code where advice ends up unset, because the expression must produce something. An if with no else returns nil when the condition is false, which is worth remembering before assigning one. And cond needs its final true -> catch-all — leaving it off raises CondClauseError rather than falling through to nil, which is the safer default even though it surprises people once.

Compare the two shapes. The PHP version interleaves the work with the checking, so the happy path is buried among the bail-outs; the with block lists the steps that must all succeed, then states the result, and handles every failure in one place. The else is optional — without it, a failing step becomes the return value of the whole with, which is often exactly right when your caller already expects {:error, reason}. This is the construct you will reach for in a Phoenix controller, where four things in a row must go right before you can render.

Read the recursion as the loop turned inside out: the while condition becomes the when guard, the loop body becomes the arguments to the recursive call, and the base case becomes its own clause. This costs nothing at run time — a call in tail position (the last thing a function does) reuses the stack frame, so this runs in constant space exactly like the while. In practice you write this shape far less than you would expect, because Enum and Stream already cover almost every loop that walks a collection; hand-written recursion is for the cases they do not, like this one.

Two things differ, and both come from a struct being a map. The key set is closed: %User{nickname: "A"} is a compile-time error, where a PHP object would need declare(strict_types=1) and a typed property to refuse it, and a plain array would accept anything. And there is no constructor to run, so there is nowhere to validate — the convention is a new/1 function in the module returning {:ok, user} or {:error, reason}, which is more honest than a constructor that can only signal failure by throwing. The hidden __struct__ key holds User, which is what lets a function head match %User{} specifically.

The two rebindings of counter are the price, and forgetting one is the most common beginner bug: Counter.increment(counter) on a line by itself computes a new counter and throws it away, with no warning that anything is wrong. The compensation is that there is no aliasing to reason about — if you handed counter to three other functions before this line, none of them saw it change. The %Counter{count: count} = counter head is doing two jobs at once: asserting the argument really is a Counter and pulling out the field, so a map that merely looks similar is rejected.

PHP passes an instance, and the interface constrains its type. Elixir passes the module itself — EmailNotifier is a value, an atom, and notifier.send(message) calls the function on whatever module the variable holds. That is why configuration in Elixir so often reads config :app, :notifier, EmailNotifier: swapping an implementation for a test means passing a different module name, with no container, no binding and no interface-to-implementation registry. The @impl Notifier annotation is optional and worth writing; it makes the compiler check that this function is actually part of the behaviour, catching a typo that would otherwise define an unrelated function silently.

The part PHP cannot do is the for:. A defimpl can name any type, including one from a library or a built-in like Integer, and it lives in your code rather than theirs — so you can teach someone else's struct how to serialize into your format without a wrapper class or a subclass. That is the same capability Rust calls a trait implementation and PHP has no equivalent for at all: adding an interface to a class you do not control requires editing that class.

Almost never, is the answer. In PHP an exception is the standard way to report that something went wrong, so a service method throws and a controller catches. In Elixir the standard way is the {:ok, value} / {:error, reason} tuple from the Atoms section, and an exception is reserved for something genuinely unexpected — a bug, a violated invariant, a broken assumption. The reason is not taste: an exception is a non-local jump that skips whatever the caller was doing, and the BEAM has a better answer for real failure, which is to let the process die and be restarted by its supervisor. That is the next few rows.

The advantage is that the failure is in the type of the return value, so it is impossible to ignore by accident — a case that omits the {:error, _} branch raises at that line rather than letting an exception unwind three frames to somewhere that has lost the context. Note {age, ""}: Integer.parse returns the number and the unparsed remainder, so matching the remainder against the empty string is what rejects "36abc" — a distinction PHP's (int) cast quietly loses, since (int) "36abc" is 36.

Choosing between them is a judgment about whose fault a failure is. If the input came from a user or a network and failing is a normal outcome, take the tuple and handle it. If the value is one your own code produced and a failure means you have a bug, take the ! version — an immediate crash with a precise message beats a nil that travels. That maps neatly onto JSON_THROW_ON_ERROR, which exists for the same reason; the difference is that Elixir makes the choice visible in the function name at every call site rather than in a flag argument.

The BEAM starts once and keeps running, so an Elixir application has a memory. An Agent is the simplest way to use it: a process holding one value, updated by sending it a function. The counter above genuinely counts across requests, and a cache, a rate limiter or a connection pool needs no external service. The trade is that you now have shared mutable state, which is the thing PHP's design eliminates by force — and the next rows are how the BEAM makes it safe without locks: the state lives inside a process, and the only way to touch it is to send that process a message.

Three primitives are the whole model. spawn starts a process and returns its identifier. send puts a message in that process's mailbox and returns immediately, never blocking. receive takes the first message matching one of its patterns, waiting if none has arrived — with after as the timeout, which you should almost always include. Note there is nothing shared: each process has its own heap, the message is copied, and so no lock, mutex or race condition is possible by construction. That is the trade the BEAM makes — copying costs memory bandwidth, and buys away the entire category of bug PHP avoids by throwing the world away instead.

Real code would write this as Task.async_stream, which is one line and handles timeouts, failures and back-pressure; it is spelled out here with spawn and receive because seeing the mailbox once makes Task obvious afterwards. Note that results arrive in completion order, not the order they were spawned, which is why they are collected into a map keyed by the input rather than a list. That into: %{} option on the comprehension is what builds a map instead of a list.

The spawned process raised and died, printing a crash report, and the parent did not notice. That is the default: processes are unlinked, so a failure is contained to whatever was doing the failing. "Let it crash" follows from it — instead of defensively rescuing every possible error, you let a process die on bad input and have something restart it in a known-good state, because a fresh process has no corrupted leftovers to carry forward. The something is a supervisor, which watches a set of processes and restarts them by a declared strategy. This is what people mean by BEAM fault tolerance, and it has no PHP equivalent because there is nothing long-lived to supervise.

The difference is that only the GenServer's own process touches its state. Every caller sends a message and waits, so requests are serialized by construction: two callers adding to this basket simultaneously cannot interleave, because the process handles one message at a time. A PHP object shared between concurrent requests would need a lock, which is precisely why PHP does not share objects between requests at all. Note the two call styles — call waits for a reply and is synchronous, cast is fire-and-forget — and that the public functions and the callbacks live in the same module, which is the convention: the top half is the API a caller sees, the bottom half is what runs inside the process.

That is the entire mechanism: state is a parameter of a function that never returns, so it is mutable-looking without any mutation, and it is private because the only way in is the mailbox. Everything use GenServer adds is the boilerplate around this — replying to the caller, handling system messages, reporting to a supervisor. Write the loop by hand once for understanding and then use GenServer, because the hand-rolled version silently lacks all of that. The loop.(loop, state) spelling is how an anonymous function calls itself: it has no name to refer to, so it is handed itself as its first argument — a named module function would simply say loop(state).

The PHP column shows what you would otherwise hand-write: a retry loop that has to know which failures are retryable and how to rebuild whatever the dead attempt left behind. Real PHP supervision lives one level up instead — supervisord, systemd or Laravel Horizon restarting a worker process — which means the unit of failure is the whole program and recovery costs a full start-up. A BEAM supervisor restarts one child in microseconds while everything else keeps serving, and the strategies say how far the blast reaches: :one_for_one restarts only what died, :one_for_all restarts all the children when any dies (for children that only make sense together), and :rest_for_one restarts the ones started after it. A real application is a tree of these, and that tree is the architecture document.

Elixir's == never coerces; the only latitude it allows is comparing an integer with a float numerically, and === is the stricter one that also demands the same type. The genuinely strange line is the last: any two values can be compared with <, ordered by type — number < atom < reference < function < port < pid < tuple < map < list < bitstring. It never raises, which is what makes Enum.sort work on a mixed list, and it is also a trap: a comparison bug that PHP would surface as a TypeError silently returns a boolean here. Erlang chose it so that sorting is always total; know it exists and do not lean on it.

Elixir 1.14 changed the default so IO.inspect prints [104, 105] and only shows the charlist form when asked, which removed most of the confusion. The underlying fact has not changed and cannot: there is no separate charlist type, so [104, 105] and ~c"hi" are the same value. If a function hands you what looks like nonsense text where you expected numbers, it is this — and List.to_string/1 and String.to_charlist/1 convert in each direction.

The consequence bites when a result is used as an index, a count, or an argument to something expecting an integer: 10 / 5 gives 2.0, and Enum.take(list, 2.0) raises. Use div/2 whenever you want integer division, which is PHP's intdiv. Also note that % is not the modulo operator here — it introduces a map — and the operator you want is the function rem/2. Like PHP's %, it takes the sign of the dividend; Integer.mod/2 is the one that takes the sign of the divisor.

This produces the most common beginner bug in the language, and it fails silently: a line that calls a function and ignores its result does nothing at all. The compiler does warn for some cases, but not once the call is inside a pipeline or passed along. The habit to build is that any line which is not IO.something should either bind its result or be piped into the next step — if it does neither, it is dead code. The compensation is that you never have to remember which functions mutate, because none of them do.

Read the output: 0, not 6. The compiler warns about it, and it is the moment most people finally understand that immutability is not a suggestion. The answer is never to find a way to reach out of the block; it is to use a function that returns the accumulated value — Enum.sum here, or Enum.reduce when the accumulation is not a standard one. If you genuinely need a value that several pieces of code can change over time, that is what a process is for, which is the State section above.