Erlang.CodeCompared.To/Elm

That is the first sign of the change this page is about. io:format/1 is a side effect available anywhere in any Erlang function, and nothing in a function's shape says whether it performs one. In Elm no function can perform an effect at all, so there is nothing to call — the program produces a description and hands it over. The msg in Html msg is a type variable meaning "this markup emits no messages", which is right for a page with no interaction.

The catch is that Debug.toString is a development tool: an optimized production build refuses to compile if it appears anywhere. That is deliberate — showing a value to a human is a design decision the compiler wants you to make explicitly, so real code writes a function producing a String for each type it displays. Every text example on this page uses text with a hand-built string for that reason, and reaches for Debug.toString only where the shape itself is the point. The nearest thing to ~p that survives a production build is the one you wrote.

Two conventions worth adopting on day one, because elm-format will impose them anyway: two blank lines between top-level definitions, and a body on its own line indented four spaces. Nearly every Elm project runs elm-format on save, so the community has no style debates at all — a considerable relief coming from a language where ; versus , is a real decision. Note also that lowercase names are values here and uppercase names are types or constructors, which is the exact reverse of Erlang's rule that uppercase is a variable and lowercase is an atom.

The difference is only in when you are told. Rebinding in Erlang is a badmatch at run time, because = is the match operator and Count = 2 is a perfectly legal assertion that happens to be false. In Elm it is a compile error, because = in a let is a definition and defining a name twice is not a thing you can write. Elm also forbids shadowing outright — an inner scope may not reuse an outer name — which Erlang permits with a warning.

Notice what the declaration buys. The Erlang match {ok, Value} = Result is an assertion that fails at run time if the result was {error, Reason}, so the error branch is something you have to remember to write. The Elm case will not compile unless every constructor is handled, so forgetting the failure branch is impossible. Elm ships this exact shape as Result error value with constructors Ok and Err, used throughout the Errors section below — the type is hand-rolled here only so the parallel with the tuple is visible.

The two differences are small and both are improvements. Erlang's if takes guards rather than arbitrary expressions, which is why the fall-through branch is spelled true -> and why an if that matches nothing raises if_clause — Elm requires an else, so there is no such case. And both branches of an Elm if must have the same type, which Erlang has no way to check. Erlang's case is closer to what you will actually use, and it maps to Elm's case almost exactly, minus guards.

The Elm version is not a caught error — it is a build failure, so the program containing that call does not exist. Erlang reaches reliability from the other direction, with supervision restarting whatever fails, and that is a genuinely different and genuinely good answer for a long-running distributed system. For a front end there is nothing to supervise: a JavaScript exception in a browser tab does not restart anything, it just stops the page working. The trade Elm makes is to eliminate the failures beforehand instead, which is why "let it crash" has no counterpart here — and why the Errors section below has no catch in it.

Dialyzer's design goal is no false positives: it reports discrepancies it can prove, and stays quiet about everything it cannot, so a clean Dialyzer run is not a statement that the code is type-correct. Elm's inference goes the other way — every expression has a type whether annotated or not, and anything that does not fit is rejected. The practical difference shows up during a change: alter a function's signature in Elm and the compiler lists every call that no longer fits, which is refactoring with a checklist. In Erlang the same change is found by grep, tests, and eventually production.

There is no class here and no constructor — an alias is only a name for a shape, and any record with those exact fields is a Person. Two consequences. maps:get(nam, Person) raises badkey when it runs, while person.nam does not compile, naming the field and listing the ones that exist. And the alias doubles as a constructor function: Person "Ada" 36 builds one positionally. Erlang's -record is the closer analogue, and it is compile-time-checked too — but records are a preprocessor trick that does not survive to expression level, which is why the anchor column here uses a map.

Elm has no atoms. The replacement is a custom type whose constructors are declared, so the set is closed: Susppended is not a value, it is an unknown name, and the compiler says so with a suggestion. Two more things follow from the set being closed. A case that misses a constructor does not compile, so function_clause has no counterpart. And adding a fourth Status immediately lists every case in the codebase that no longer covers it — the change Erlang finds when a request happens to hit the gap.

The Erlang version has three unchecked assumptions: that only these two tags exist, that a square tuple has exactly two elements, and that the second is a number. Nothing verifies any of them, and Area({square, "3"}) gets as far as badarith. The Elm declaration states all three, so the case is exhaustive, the arities are fixed, and Square "3" does not compile. This is where custom types stop resembling an enum and start replacing what other languages give to a class hierarchy — a closed set of alternatives with different fields each.

Total ordering is what makes lists:sort/1 work on a mixed list, and it is also a trap: 1 < a is true rather than an error, so a comparison bug returns a plausible boolean instead of complaining. Elm's < requires both sides to be the same comparable type, so the same mistake does not compile. The narrower rule costs you the mixed-list sort, which is rarely what you wanted, and buys the guarantee that a comparison compared what you thought.

Maybe String is not a String, so no function expecting a String will take it and the compiler forces the absent case to be handled before the value can be used. Compare what the Erlang column has to do: remember to case on undefined, and remember it again at every call site, with nothing checking that you did — string:uppercase(undefined) is a run-time badarg. This is the same shape as the {ok, Value} convention you already use, promoted from convention to type. Maybe.withDefault is the unwrap at the edge.

The habit worth building is to stay inside the Maybe and unwrap once, at the edge, rather than threading an undefined check through every function. Maybe.andThen is the version for a step that itself returns a Maybe, which is where a nested case would otherwise appear — the same relationship Result.andThen has in the Errors section. Note that Erlang's version has to repeat undefined in two roles, as the thing matched and the thing returned, with nothing connecting them.

Three differences, all small. There is no ; between branches and no end, because layout does that work. Patterns match declared constructors rather than arbitrary terms, so the branch set is checkable — the compiler rejects a case that misses one, where Erlang raises case_clause at run time. And the branches must all return the same type, which is what makes describe's signature possible at all.

This is the one place where an Erlang developer gives something up and gets nothing directly back, and it is worth naming rather than glossing. What softens it is that half of what Erlang guards do is type dispatch — is_integer, is_list, is_atom — and in Elm the type is already known, so those guards have nothing to test. The Erlang column here classifies a value of unknown type, which is a function Elm cannot express at all: classify takes an Int, because a function that accepts anything and behaves differently per type is what custom types exist to replace.

Erlang cannot offer this and it is not an oversight: an atom set is open by construction, so there is no "every" for a compiler to check against. The result is that case_clause is a normal Erlang production error, usually arriving as a crash report about a value nobody expected. In Elm the compiler names the missing constructor before the build finishes. The habit this changes is defensive catch-all branches — _ -> exists in Elm too, and using it throws the guarantee away, so idiomatic code lists the cases and lets the compiler maintain the list.

The parentheses come back the moment an argument is itself a call — String.fromInt (double 21) needs them, since String.fromInt double 21 would mean passing two arguments to String.fromInt. Note also that ++ here is string concatenation, where in Erlang ++ joins two lists and works on strings only because an Erlang string is a list. That difference is the subject of a Gotchas row below, and it is a bigger one than it looks.

This is the second real loss on this page, after guards, and the two compound: an Erlang clause head can pattern-match and guard, so F(0) -> 1; F(N) when N > 0 -> … says a great deal in two lines. The Elm equivalent is longer and, for a recursive function over a custom type, usually a case on the constructor — which does read well. What you gain is that there is one place a function's behavior is decided, so there is no equivalent of adding a clause above an existing one and silently changing what an old call does. Note that Elm functions are recursive by name with no fun F ceremony needed.

So greet "Hello" is a complete expression of type String -> String, and calling a function with fewer arguments than it appears to want is ordinary rather than an arity error. Erlang is strict about arity — Greet("Hello") is a badarity — so pre-filling means the wrapper fun in the anchor column. This is also why sayHello can be defined with no parameter at all, which looks wrong until the currying clicks. The payoff shows up in List.map (greet "Hi") names, where the partially applied function is exactly what map wants.

That is the opposite of most pipes, and it follows directly from currying. List.map String.trim is a partially applied function still waiting for its list, so piping a list into it completes the call — which works only because the list is the last parameter. The whole standard library is ordered that way: List.map f list, String.join separator list, Dict.get key dict. Erlang's convention is the reverse (lists:map(Fun, List) takes the data last, but string:trim(String) takes it first), which is exactly why a pipe never took hold there. Put the data last in your own Elm functions or your pipelines will not compose.

That one rule is what makes List.sum and the rest safe with no run-time checks. When you genuinely need a mixture, the Elm answer is a custom type naming the alternatives, which forces every consumer to handle each case — where an Erlang mixed list is discovered by whatever function chokes on it first. Note the second Elm branch: matching a list means handling the empty case too, so [] is not optional, which is the exhaustiveness rule applied to lists. Erlang would raise badmatch on [H|T] = [] at run time.

A lambda is \parameter -> body, which is the Erlang fun(X) -> ... end with the ceremony removed. List.foldl (+) 0 shows an operator used as a function by wrapping it in parentheses — Erlang has no equivalent, since + is not a fun and fun erlang:'+'/2 is not a thing you write. Note modBy 2 number rather than an infix rem: the argument order is deliberate so that modBy 2 partially applies to "is even", which is the currying rule showing up in the standard library's design.

This is a fair trade rather than a loss: the comprehension is more compact, and the pipeline is easier to extend, because adding a sort or a limit is one more stage rather than a rewrite. .name on its own is worth pointing out — a record field accessor is an ordinary function of type { a | name : b } -> b, so List.map .name needs no lambda. Note also that the Erlang generator pattern {Name, Age} <- People silently skips elements that do not match, which is the one place a failed match is not an error; Elm has nothing that does that, and filtering is always explicit.

A record has a fixed field set fixed by its type, so person.age is checked and { person | nickname = "A" } does not compile — the update syntax cannot add a field, only change one, which is exactly Erlang's := against => distinction promoted to a compile-time check. A Dict has keys of one type and values of one type, and Dict.get returns a Maybe because the key might be absent, where maps:get/2 raises badkey. Choosing between them is the useful discipline: if you can list the fields, it is a record.

So a function can only report failure by returning it, and the type says so — Result String Int is visible to every caller. Note what the Erlang column had to do: list_to_integer/1 raises rather than returning a tuple, so the tagged-tuple convention has to be added by hand with a try. Elm's String.toInt returns a Maybe to begin with, because a standard library with no exceptions cannot do otherwise. That is the general shape: the convention you follow by discipline in Erlang is the only thing available here.

The Elm pipeline lists the steps in order and handles failure once, at the end. Result.fromMaybe is the adapter that turns "there was nothing" into "there was nothing, and here is why", which is the everyday job of attaching a reason to a Maybe; Result.map is the version for a step that cannot itself fail. Erlang's maybe expression, added in OTP 25, is the closest thing the language has to this and is worth knowing if you have not met it — it exists for exactly the same reason.

Elm has neither half of that. There are no processes, so nothing can die in isolation, and no supervisors, so nothing would restart it — and in a browser tab there is nothing meaningful to restart anyway. What replaces it is the other end of the same problem: the failures a supervisor exists to absorb are largely badmatch, case_clause, function_clause and badarg, and every one of those has been made unrepresentable by the type system. Neither approach is the better one in the abstract; they are answers to different deployment shapes, and the Erlang one is unarguably better for a system that must stay up for years.

What replaces them is narrower and worth understanding on its own terms. Concurrency in Elm means asking the runtime to do several things and receiving each answer as a message into update — an HTTP request is a Cmd value the runtime performs, and its response arrives as a Msg. That is a mailbox with exactly one process reading it, and the process is the application. Genuine parallelism means a Web Worker on the JavaScript side, reached through a port. For a front end this is rarely a real constraint; for anything resembling what you use Erlang for, it is a wall.

Read the correspondence directly: Model is the loop state, Msg is the set of messages the server accepts, and update is handle_call — with the crucial difference that Msg -> Model -> Model is a complete description, so update cannot perform an effect the way a handle_call can. When an effect is needed the signature becomes Msg -> Model -> ( Model, Cmd Msg ) and the Cmd is a value the runtime executes, with the reply arriving as another Msg. That is a gen_server whose side effects are data. And because Msg is a closed custom type, there is no equivalent of an unmatched handle_info quietly accumulating in a mailbox.

Effects still happen — they are Cmd values returned from update and performed by the runtime, so an HTTP request is a value describing a request rather than a call that makes one. For someone maintaining code the consequence is large: a function of type Int -> Int cannot have surprised you, so reviewing it means reading it, and testing it needs no mocks and no started applications. The cost is that a quick io:format dropped in to debug something is not available; Debug.log exists for exactly that and is stripped from optimized builds.

Erlang's iodata list is a genuinely good way to assemble output — nothing is copied until it is written — and it is also just a nested list of bytes, so an unclosed tag is a runtime-invisible bug and an interpolated value containing <script> is markup. In Elm the structure is well-formed by construction because you are calling functions, and text produces a text node, so a string is never parsed as HTML and there is no escaping step to remember. What you give up is the ability to hand a template file to somebody who does not write Elm.

That is the whole templating story, which is why Elm has no template syntax at all. Every tool that works on lists works on markup: List.filter to hide items, List.sortBy to order them, ++ to append a footer row, and an ordinary function returning Html msg to factor out a partial — with a type signature, so calling it wrongly does not build. The Erlang version is close in spirit and differs in exactly one way that matters: its result is bytes, so nothing downstream can check it.

The cost is real: a decoder is more code than jsx:decode/1, and for three fields it feels like ceremony. What it buys is that the boundary is the only place a shape can surprise you. A server that renames age to years makes maps:get/2 raise badkey somewhere downstream, on whichever request first hits that path; here the decode fails immediately with Expecting an OBJECT with a field named `age`, and Ok/Err forces you to decide what happens. Past that boundary every field is guaranteed present and correctly typed for the rest of the program.

That is the difference between "this field was missing this time" and "this field is optional". Erlang's three-argument maps:get/3 supplies the default at the point of use, so the same field can be treated as required in one place and optional in another with nothing noticing — and a required field that is absent looks exactly like a genuinely optional one. Here the type carries the fact everywhere the value goes. Decode.oneOf handles a field arriving in more than one shape, and Decode.map3 through map8 extend this to larger records; beyond that the community uses NoRedInk/elm-json-decode-pipeline.

The practical relief is large — no list_to_binary, no unicode:characters_to_list, no deciding which representation an API wants, and no ~s versus ~p confusion when a "string" turns out to be a list of small integers. The practical loss is that String is opaque: you cannot pattern-match a string the way you match a list, so String.uncons is the explicit way to get the first character and the rest, returning a Maybe ( Char, String ). String.toList gives you a List Char when you genuinely want to work character by character, and String.fromList goes back.

Elm has no numeric promotion: Int and Float are separate types, and mixing them needs toFloat or round/floor/truncate going the other way. That is stricter than Erlang and stricter than almost anything else, and it catches a real class of bug — the average that came out as an integer because both operands happened to be. Note the argument order of modBy: it is modBy divisor value, the reverse of rem's reading order, deliberately so that modBy 2 partially applies. Elm also has a number type variable, so a literal 10 can be either until context decides.

This is the capability gap that runs furthest in Erlang's favor, and it is not a small one — hot code loading is why Erlang systems are measured in years of uptime. Nothing in Elm corresponds, because the entire call graph is resolved at compile time; that is also precisely what makes the dead-code elimination so effective and the type guarantees whole-program rather than per-module. During development, the Elm debugger and elm-live give you a fast reload with the model preserved across it, which covers the everyday case and none of the operational one.

When you publish an Elm package the tooling compares the new public API against the previous release and computes the bump itself — add a function and it must be minor, change a type signature and it must be major. You cannot publish a patch release containing a breaking change, because the tool will not let the number be that. The second rule is the restrictive one: reaching JavaScript means a port, where you send a value out and write the JavaScript side yourself, and there is no equivalent of a NIF to escape into. That is what makes the no-runtime-exceptions guarantee hold for the whole program — and it is also why the ecosystem is thousands of packages rather than hundreds of thousands.