PHP.CodeCompared.To/Erlang

The module:function(Args) shape is how every Erlang call to another module is written, so io:format is the format function of the io module, and the colon is not a namespace separator in the PHP sense — it is part of the call. The trailing period ends the expression, which matters far more than it looks; the next section is about that punctuation.

Four directives cover most real code. ~p is "pretty print" and renders any term for a human, which is print_r and var_dump at once and needs no declaration for a custom type. ~s prints a string or iodata as characters. ~w is the raw, unformatted version of ~p, and you will see it in log lines where the formatting cost matters. ~n is the newline. The one to be careful with is ~s: hand it something that is not a string or iodata and you get a badarg, where ~p would have printed it happily.

The reason is that the shell can attach to a running production node — erl -remsh opens a prompt inside the live system, where you can inspect a process's state, trace a function's calls with dbg, and count messages in a mailbox, all without a restart. PHP structurally cannot offer this: by the time you would look, the process that served the request has exited. It is also why the examples in this column are shell expressions rather than module files — comma between expressions, single period at the end — which is exactly what you would type at that prompt.

Read them as English and they stop being arbitrary: comma is "and then", semicolon is "or else", and period is "that is the end of this sentence". The rule that catches everyone is that the last clause before an end takes no semicolon, exactly as the last item in a list takes no comma. PHP uses ; for what Erlang uses , for, which is why a PHP reader's instinct is wrong in the most common position. When you see a function definition ending in . you have reached the end of that function and the next line starts a new one.

PHP settles the same question with $, so a PHP reader has nothing to unlearn except where to look. Two consequences worth carrying. A lowercase word you do not recognize is almost certainly an atom rather than an undefined constant, which is why Erlang code is full of bare words like ok, error, undefined and infinity — they are values, not names of values. And an underscore-prefixed variable such as _Reason is a real variable the compiler will not warn about being unused, while a bare _ matches anything and binds nothing. You will see both constantly in OTP callbacks.

The module name must match the filename, so counter.erl declares -module(counter) and nothing else — there is no namespace hierarchy at all, and every module in a running system shares one flat namespace. That is why OTP libraries prefix their modules by hand: gen_server, ssl_connection, rabbit_channel. Visibility has no keyword: a function is public if and only if it appears in -export, so the export list is the file's public interface and reading it first is the fastest way into an unfamiliar module. The comment convention is worth knowing too — %%% for the file, %% for a function, % for a trailing note.

That places it between PHP's two mechanisms. PHP 8's int $value is checked at run time and will throw; PHP's @param docblock is checked by PHPStan or Psalm if you run them. An Erlang -spec is the second kind — and Dialyzer's design goal is no false positives, meaning it reports only discrepancies it can prove, and stays silent about everything it cannot. So a clean Dialyzer run is not a statement that the code is type-correct, and a -spec you read in unfamiliar source is the author's intent rather than a guarantee. Treat it as excellent documentation, which is genuinely what it is.

Read the two outputs: the PHP column can only print 2, because the 1 is gone, while the Erlang column still has both. Those numbered names are not a style someone chose — they are forced, and recognizing them is part of reading Erlang fluently: State1 is the state after step one. A PHP developer should read a numbered sequence as "this is the pipeline of transformations", which is what a chain of reassignments would be. Elixir relaxed this rule and allows rebinding, which is the single most visible syntactic difference between the two languages and the reason Elixir code has no numbered variables in it.

So {X, Y} = Point destructures like PHP's [$x, $y] = $point and asserts that Point really is a two-element tuple. When you meet {ok, Result} = some:call() in unfamiliar code — and you will, constantly — read it as "this must succeed, and I want the value": the line is both the unpacking and the assertion that the call returned ok. If it returned {error, Reason} the process crashes right there, deliberately, which is the subject of the Errors section.

Notice that the PHP version has to index back into $result inside each arm, because matching on $result[0] discarded the connection to $result[1]. The Erlang branch binds Value and Reason as part of choosing. Both languages raise when nothing matches — UnhandledMatchError and case_clause — which is the good behavior. Note io_lib:format rather than io:format: it returns the formatted iodata instead of printing it, which is the pair you want whenever a value is being built rather than emitted.

Recognizing it is most of what it takes to read an unfamiliar OTP module. Compare what PHP has to do here: json_decode returns null on failure, but null is also the correct decoding of the input "null", so the two are indistinguishable without json_last_error(). A tagged tuple has no such ambiguity. You will also meet the one-element form ok on its own, for a call that either succeeds with nothing to report or returns {error, Reason} — file:close/1 is the canonical example.

That symmetry is the shape most Erlang recursion is written in, so [H|T] in unfamiliar code reads as "the first element and everything else". Prepending is free and WithZero genuinely shares its tail with Numbers in memory, which is safe precisely because nothing can be modified. There is no cheap indexing — lists:nth(3, L) walks — and no cheap append, which is why idiomatic code builds lists backwards and calls lists:reverse/1 once at the end. If you see that pattern, it is not a bug.

The map update syntax has a distinction PHP does not: := requires the key to exist already and fails otherwise, while => inserts or updates. Using := where you mean "change this field" is a free typo check, and seeing it tells you the author expected the key to be there. A proplist is just a list of two-element tuples, which is why it keeps insertion order and permits duplicates — proplists:get_value/2 returns the first match. It is the older options-passing convention and is still everywhere in OTP's own APIs, so you will read plenty of it.

The expansion means #person{name = "Ada", age = 36} becomes the tuple {person, "Ada", 36}, so the field names exist only at compile time and only in files that have the -record declaration in scope — which is why record definitions live in .hrl header files that get -included, and why changing a record's shape means recompiling every module that uses it. It also means a record printed with ~p shows as a bare tuple with no field names at all, which is genuinely confusing the first time. Maps were added partly to escape all of this, but OTP's own internals are full of records and you will read them.

The confusing part is the printing. ~p shows a list of small integers as text when every element happens to be a printable code point, so [97, 98, 99] displays as "abc" — and a list of numbers that just happens to contain 72 and 105 displays as "Hi", which has sent many people hunting for a bug that does not exist. If a value you expected to be numbers prints as a word, this is why. Use io:format("~w~n", [Text]) to see the raw list.

Iodata is the idea worth taking away, because it has no PHP equivalent and it explains a lot of code you will read. Concatenating strings in PHP copies both operands every time; an iodata list just refers to its pieces and is flattened once, by the runtime, at the moment it is written to a socket or a file. That is why an Erlang web framework builds a response as a deeply nested list of binaries and never calls anything resembling implode. Anything accepting iodata accepts a binary, a list, or any nesting of them, so [<<"a">>, ["b", <<"c">>]] is perfectly ordinary. One directive to know when this meets real text: ~s writes bytes, so a UTF-8 binary containing anything above ASCII comes out mangled — ~ts is the Unicode-aware version, and reaching for it is the fix when accented characters arrive as noise.

The pattern is the point — once you know list_to_integer, you can guess binary_to_integer, atom_to_list, float_to_binary and term_to_binary without looking any of them up, and they all exist. Two warnings. These functions raise rather than returning a sentinel, so list_to_integer("abc") is a badarg and not 0 — which is a real improvement on PHP's (int) "abc" being a valid-looking zero. And never call list_to_atom on user input: the atom table is never garbage collected, so a hostile client can exhaust it and bring the node down. list_to_existing_atom is the safe version.

Clauses are tried top to bottom, so order matters and the specific ones go first — and note the semicolons between them, with none before end. There is no default clause here and that is deliberate: an unrecognized shape raises function_clause, naming the function and the argument, which is a better error than the InvalidArgumentException you had to remember to write. When you read an OTP module, the clause list is the specification of what that function accepts.

Guards are deliberately restricted to a fixed set of side-effect-free operations, so you cannot call your own function in one — a guard runs during matching, possibly many times, and must be provably terminating and harmless. Read the comma inside a guard as and, and a semicolon inside a guard as or, which is a third meaning for both marks and worth noting. The last line is a list comprehension used purely for its side effect, which is idiomatic Erlang and looks alarming to a PHP reader: [Expr || V <- List] is "do this for each".

Two things a PHP reader gains here. array_values has no counterpart because an Erlang list has no keys to preserve — PHP's filter keeping the original keys, so that removing element 0 leaves an array starting at key 1 that then serializes as a JSON object, is a bug class that simply does not exist. And you will often see fun Module:Function/Arity passed directly, as in lists:map(fun erlang:integer_to_list/1, Numbers), which is a reference to a named function with its arity spelled out. Note =:= rather than ==, which the Gotchas section explains.

So greet/1 and greet/2 are different functions that happen to share a name, and the shorter one delegating to the longer with a default filled in is the standard idiom — Erlang has no default arguments, so this is how they are spelled. The practical payoff when reading: an error saying undefined function counter:step/2 when step is plainly defined right there means the arity is wrong, not the name. And -export([start/0, step/1]) tells you the arity of everything public before you read a line of the body.

Erlang can hold two versions of a module in memory at once — the current one and the previous one. A local call stays in the version it is already running, so a long-running loop keeps executing the old code; a fully qualified module:function(…) call jumps to the current version. That is why a gen_server loop calls itself fully qualified: it is the moment an upgrade takes effect. When you read a module and see the same function called both ways in different places, that is not inconsistency — somebody has thought about upgrades.

Read the file in two halves, which is the convention every such module follows. The top half is the public API — ordinary functions a caller invokes, which send a message and wait. The bottom half is the callbacks, which run inside the process. The return tuples are the whole protocol: {reply, Reply, NewState} answers a call, {noreply, NewState} handles a cast with nothing to say back, and {stop, Reason, State} ends the process. call is synchronous and cast is fire-and-forget. And ?MODULE is a preprocessor macro expanding to this module's name.

PHP passes an instance and the interface constrains its type. Erlang passes the module name, which is just an atom, and the framework calls back into it. That is why configuration reads {callback_module, my_handler} and why swapping an implementation for a test means passing a different atom — no container, no binding, no registry. The genuinely useful thing to know when reading OTP: gen_server, supervisor and the rest are not language features. They are ordinary modules in the standard library, and opening gen_server.erl to see the receive loop that drives your callbacks is a good afternoon.

The strategies say how far a failure reaches: one_for_one restarts only what died, one_for_all restarts every child when any dies (for children that only make sense together), and rest_for_one restarts the ones started after it. The intensity and period pair is the give-up rule — more than five restarts in ten seconds and the supervisor itself dies, escalating to its supervisor, which is how a genuinely broken subsystem eventually takes down the node rather than thrashing forever. A real application is a tree of these, and that tree is the architecture document: reading the supervisor modules tells you what a system is made of and what depends on what.

The BEAM starts once and keeps running, so an Erlang application has a memory, and a cache or a rate limiter needs no external service. The trade is that you now have shared mutable state — the thing PHP eliminates by force — and the BEAM makes it safe without locks by putting the state inside a process whose only door is a mailbox. Note the shape of the loop: state is a parameter of a function that never returns, so it looks mutable without any mutation, and gen_server is exactly this with the boilerplate filled in.

Three primitives are the whole model. spawn starts a process and returns its identifier, a pid, which prints as <0.123.0> and which you will see everywhere in logs. ! puts a message in a mailbox and returns immediately, never blocking and never failing — sending to a dead process is silently fine. receive takes the first message matching one of its patterns, waiting if none has arrived, with after as the timeout you should almost always include. Nothing is shared: each process has its own heap and the message is copied, so no lock is possible by construction.

A link means "if either of us dies, so does the other", which is what spawn_link sets up and what makes a supervision tree collapse cleanly — a supervisor traps those exit signals rather than dying, which is what process_flag(trap_exit, true) is for whenever you see it. A monitor just sends you a {'DOWN', …} message, which is what gen_server:call uses internally so that calling a dead server gives you an error rather than hanging forever. The quoted 'DOWN' is an atom that needs quotes precisely because it starts with a capital letter.

"Let it crash" says: do not write defensive code for cases you did not anticipate, because a process that has met an impossible situation has no idea what state it is in, and continuing is worse than stopping. The {ok, User} = Fetch(1) line is an assertion — if the call returns {error, _} it raises badmatch, the process dies, its supervisor restarts it from a known-good state, and the failure is logged with a full stack trace. That is why a well-written Erlang module handles the errors it expects and ignores the ones it does not. Copying PHP's catch-everything habit into Erlang produces code that limps on in a corrupted state, which is strictly worse.

The distinction is about intent. error means a bug — badmatch, badarg and function_clause are all this class, and it carries a stack trace. exit means this process is stopping on purpose, and it is what supervision is built on. throw means a non-local return the author expects somebody to catch, and it is comparatively rare in real code. The catch-all shorthand catch Expression that you will meet in older source catches all three and mangles the reason into {'EXIT', Reason}, which is why modern code uses the explicit try … catch Class:Reason form.

That transparency is Erlang's most distinctive operational feature and its most double-edged. What you gain is that a system can be spread across machines without changing how processes talk. What you must know is that it is fully meshed and fully trusted — every node connects to every other, and a node that knows the shared cookie can run any code on any of them, so the distribution protocol must never be exposed to a network you do not control. It is also not partition-tolerant by default: a network split produces two halves that each think the other died. Everything Elixir does here is this same mechanism.

The two columns print the same shape of answer and mean different things: PHP names a file on disk, Erlang names a loaded module that carries a version attribute — and that vsn is exactly what the release upgrade machinery compares. The mechanism is the one from the calling-conventions row: two versions live in memory at once, a local call stays in the version already running, and a fully qualified call goes to the current one. So a gen_server loop that calls itself fully qualified picks up new code at its next iteration, and OTP's code_change/3 callback exists to migrate the process's state to whatever shape the new version expects. A PHP deploy has nothing to migrate because nothing survives the request — which is a real simplicity, and the exact reason PHP cannot offer this.

Erlang's == does only numeric widening — it will compare an integer with a float and nothing else, so there is no "1" == 1 here and no string juggling at all. Idiomatic Erlang uses =:= almost everywhere, for the same reason careful PHP uses ===: it means what you expect, always. The stranger property is that any two terms can be compared with <, ordered number < atom < reference < fun < port < pid < tuple < map < list < bitstring, so 1 < a is true rather than an error. That total ordering is what makes lists:sort/1 work on anything, and it will also quietly accept a comparison you did not mean.

So if Count -> … is not a shortcut, it is an if_clause error at run time — you write if Count > 0 -> …. Zero, the empty list and the empty binary are all just values, none of them false. Coming from PHP this removes a whole class of bug, particularly the "0" case and the if ($items) idiom that silently misreads an empty array. The related trap when reading is that andalso and orelse short-circuit while and and or evaluate both sides — the short-circuiting pair is what you nearly always want.

PHP's constant table also only grows, and it is also global — but it is torn down with the request, so the worst a hostile client achieves is wasting memory for the length of one response. The BEAM runs for months, so calling list_to_atom/1 or binary_to_atom/2 on anything a client controls is a denial of service waiting to happen: enough distinct values and the node dies with system_limit. The safe version is list_to_existing_atom/1, which raises badarg rather than creating an entry, and the try-and-fall-back shape above is the idiom. The same hazard exists in Elixir with String.to_atom/1, and it is why Phoenix converts request parameters to atoms only at a controlled boundary.

Nothing in Erlang mutates, so a line calling a function and ignoring its result does nothing at all — and, unlike PHP, there is no sort-style exception to remember. The compiler warns about some of these but not once the call is inside a larger expression. The habit to build when reading is that any line not doing I/O should bind its result or be the last expression of a clause; if it does neither, it is dead code and possibly a bug somebody left behind.