Elixir.CodeCompared.To/Roc

Ok({}) is the return value, where {} is the empty record. An Elixir script is a sequence of expressions with no entry point to declare; a Roc application always has exactly one, because the platform has to have something to call.

This is the row that Elixir readers find most familiar and most different at once. An OTP release also bundles exactly the applications it needs — but any module in it can still call File.read!, and nothing in a function's signature says whether it will.

The count : I64 line is a type annotation. Elixir's nearest equivalent is @spec, which Dialyzer checks separately and the compiler ignores; a Roc annotation is checked by the compiler against what it inferred, and a wrong one is an error rather than a warning from another tool.

Because the status is a return value, the compiler type-checks it, and nothing deep in a library can end the program on its own. System.halt does exactly that, which is why the advice is System.stop instead — it at least lets the application shut down in order. On this page System.halt is described rather than run, because it takes the whole runtime down with it and the next example would find nothing there.

This is the whole axis of the page. Everything else — {:ok, _}, atoms as states, maps with the right keys — is a convention Elixir maintains by discipline and Roc maintains by type. Elixir's set-theoretic gradual types are moving toward the same ground from the other side, which makes this a live comparison rather than a settled one.

A wrong @spec is found by Dialyzer, if it is run, in a separate pass, with output that is famously hard to read. A wrong Roc annotation is a compile error naming the two types. The difference is not that one has types and the other does not — it is who checks them and when.

Elixir cannot check this, because color has no type saying which atoms it might be — any atom is a possible value, and there are infinitely many. Adding a fourth color to a Roc union breaks the build at every match that needs updating, which is the refactoring tool this row is really about.

The literals are almost identical — Elixir's %{name: "Ada"} and Roc's { name: "Ada" } — and what differs is entirely what is known about them. person.nmae in Elixir raises KeyError at the moment that line runs, which may be in production.

Elixir's nil is milder than most languages' null: it is just an atom, so passing it somewhere usually raises a clear FunctionClauseError rather than corrupting anything. It is still a value that can arrive anywhere, and the check is still yours to remember.

Elixir readers will notice how close these are, and the closeness is the point: {:ok, value} / :error is the right shape, and Roc's contribution is making it the only shape and giving it a type.

Elixir's rule is unusually sane — only nil and false are falsy, so 0 and "" behave as most people expect. Requiring a real Bool removes even that, along with the &&/and distinction that exists because one accepts any term and the other demands a boolean.

The case is spelled Fine rather than Ok only to keep it clear of the Ok that Try uses. Tags are capitalized where atoms are prefixed with a colon; otherwise this is the same idea.

The Elixir version is the same design without the type: nothing says that a shape is one of exactly two shapes, that a circle carries one number, or that the case is complete. That is the row where the tagged-tuple convention and the tag union visibly part company.

Elixir is open by default and cannot be closed; Roc lets a function choose, per signature, and checks whichever it chose. Openness is the thing Elixir programmers will miss least on this page, because they already have it — what is new is being able to ask for the other one.

Elixir got the shape right long before most languages, which is why this row reads as a formalization rather than a correction. What the type adds is that a caller who forgets the error case does not compile, and that Integer.parse returning {number, rest} rather than {:ok, number} — a real inconsistency in the standard library — could not happen.

with is one of Elixir's best ideas and it has a known rough edge: the else block sees every non-matching value from every clause, with nothing saying which clause produced it, so a careful else ends up re-tagging each step. ? propagates the error unchanged and the type records what it can be.

Both columns print the same thing and read almost alike. The difference is in the signature: the Roc one says Insufficient is the only failure, so a match that handles it is complete, and adding a second failure breaks every caller that now has a case to consider.

Elixir's pairs exist because raising is genuinely the right answer when a failure means the process should die, and writing both is the cost of offering the choice. Roc has no exceptions at all, so the choice does not arise — and the Processes section is where that stops being obviously an improvement.

Roc writes => where Elixir writes ->, and needs no end. Otherwise an Elixir programmer can read this without being told anything.

The deeper difference is what = means. In Elixir it is the match operator, so %{name: "Bob"} = person is a runtime assertion that raises if it fails. In Roc = only binds, and a pattern that could fail belongs in a match.

Roc's guards are ordinary expressions. Elixir's are restricted to a fixed list of functions that the compiler can prove side-effect-free, which is why String.length/1 is allowed in a guard and a function you wrote is not — the whole reason defguard exists.

Multi-clause heads are among the things Elixir programmers miss most in other languages, and the loss here is real — the Elixir version reads as a table of cases while the Roc one nests them one level deeper. What is gained is that the cases are checked for completeness, which a set of function heads is not.

An Elixir struct is a map with a __struct__ key naming its module, which is what makes it nominal — a %PersonStruct{} will not match a %Coordinate{} of the same shape. Roc's records are structural; := is how you ask for the nominal behavior.

Both refuse to add a field that is not already there — Elixir's update syntax raises KeyError for an unknown key, and Roc's is a compile error. That is one of the places Elixir's struct is doing real work, and the two languages agree.

Elixir has put_in, update_in and Access for exactly this, and they are genuinely more concise once the nesting is more than two deep. Roc's version is more typing and needs nothing imported; neither is obviously better, and this is the row where Elixir's standard library is ahead.

The Elixir column threads the function through itself because an anonymous function cannot call itself by name — a named function in a defmodule would read more naturally. The Roc side needs no such trick: a top-level definition can recurse, and Tree.Node(…) to construct against bare Node(left, right) to match is the asymmetry to remember.

These are the same shape rather than two different ideas. In both languages a method is an ordinary function taking the value as its first argument, and neither has inheritance or virtual dispatch. Elixir keeps the module and the struct as separate names and pipes between them; Roc attaches the block to the type, which is what buys the dot. What Roc gives up is everything that needs a runtime — no protocol to implement later, no defimpl for a type you do not own, and every call here resolved at compile time.

This is the closest row on the page, and worth noticing for that reason — a language with no shared ancestry arrived at the same operator with the same semantics. keep_if is Enum.filter, and a lambda's parameters go between vertical bars where Elixir writes fn … ->.

The argument order is flipped — Elixir passes the element first and the accumulator second, Roc the other way round — which is exactly the kind of detail that costs ten minutes the first time. Enum.reduce/2 without a seed raises on an empty list; Roc has no such variant.

That is a real loss for anything unbounded or expensive — Stream is how Elixir reads a large file line by line without holding it in memory, and there is no way to express that here. The compiler does fuse some chains, but fusing is not the same as never building the intermediate list.

Enum.find returning nil is the one place Elixir's otherwise excellent result conventions slip — a list that legitimately contains nil makes the answer ambiguous, which is why Enum.find_value and a default argument both exist.

This is stricter than Elixir, which allows rebinding freely while keeping values immutable — and it is the difference that catches Elixir programmers most often. The error message names self-reference rather than mutation, because counter = counter + 1 reads to the compiler as a definition whose body mentions itself.

The BEAM achieves the same end differently — persistent data structures that share everything unchanged, decided at run time. Roc decides at compile time and can therefore mutate outright, which is faster when it applies and gives up the structural sharing that makes a large map cheap to copy in Elixir.

This is a bigger change than it looks. An Elixir list is a cons cell chain, so prepending is free and indexing is a walk — which is why idiomatic Elixir builds lists backwards and reverses. Roc's array makes indexing cheap and prepending the expensive end, so the idiom inverts.

Elixir's split comes from Erlang, where named functions live in modules and have an arity, and anonymous ones are values. The dot is the visible cost; &Module.fun/1 capture syntax is the other half of it.

Both languages capture by value, and in both that is unambiguous because the captured value cannot change afterwards. The &IO.puts/1 capture in the Elixir column has no Roc counterpart — a function reference is just the name.

Another row where the two languages agree outright. They differ in the general form underneath: Enum.sort/2 takes a function returning a boolean and getting its sense backwards compiles and sorts incorrectly, while Roc's sort_with takes three named tags — Before, After or Same — which cannot be written the wrong way round.

Elixir's version goes through the String.Chars protocol, which is why a map or a tuple raises rather than printing something unhelpful. Roc has no protocols, so the conversion is a method call you write, and forgetting it is a compile error naming the type that arrived.

Elixir is unusually good here — binaries are UTF-8, String.length/1 counts graphemes and byte_size/1 counts bytes, and the names say which is which. Roc's standard library makes the byte count the one it names and hands the rest to a library, on purpose.

These correspond almost exactly. String.split/2 also accepts a list of separators or a regular expression; split_on takes one literal separator.

Arbitrary precision is a genuine Elixir advantage and it is not free: every integer carries a tag and may be boxed. A fixed-width integer is the trade Roc makes for values that fit in a register, and the abort is what keeps it from being silently wrong.

The two languages part on /. Elixir's 7 / 2 is 3.5 whatever the operands are; Roc's / follows the type, so on two I64 values it discards the remainder and gives 3. The unannotated case is saved by a default: a Roc number literal with no annotation is a Dec, so 7 / 2 written with bare literals is 3.5 in both languages.

Integer.parse/1 returning a remainder rather than a result is a deliberate choice — it supports parsing a prefix, as in "42kg" — and it is also why {number, ""} is the pattern everyone actually writes. Roc's from_str has no prefix mode, so trailing text is a failure rather than a remainder to inspect.

This is the section where the comparison runs out rather than resolving, and it is the largest thing on the page. Processes are not a feature of Elixir the way pipes are — they are what the language is for, and everything from GenServer to Phoenix LiveView is built on them. Nothing here replaces that.

That is the functional-core pattern Elixir programmers already write inside a GenServer — and the GenServer is the part that does not come across. What is lost is not the state handling but everything around it: a named process other code can find, a mailbox that serializes concurrent access, and a supervisor that can restart it.

These are opposite answers to the same question and both work. Elixir's bet is that you cannot anticipate every failure, so isolate it and recover; Roc's is that most failures can be made unrepresentable, so the ones left are worth handling explicitly. Elixir's bet pays off exactly where Roc has nothing — a long-running system with many independent activities, where something will go wrong that nobody typed.

Hot code loading and transparent distribution are the two things the BEAM does that almost nothing else does, and they are why telecoms built it. Neither is a gap Roc intends to fill — it is a different kind of program — but an Elixir programmer weighing the two should know they are not on the list. The columns differ by a colon because the Elixir one is printing a real atom and the Roc one a string: there is no node to ask.

The two are open in opposite directions. A protocol lets a new type be added without touching the function; a union lets a new function be added without touching the types. Elixir's String.Chars, Enumerable and Inspect are all the first kind, and a Roc program has to know its cases in advance.

A behavior declaration gives something a function parameter does not: the compiler warns when an implementing module is missing a callback, and the module can be named in configuration and swapped without touching call sites. That is how a GenServer, a Plug and an Ecto adapter are all wired, and it has no counterpart here.

Elixir gets this for free by not checking, and the difference shows in what each rejects. first_or.([1, 2], "none") compiles and runs in Elixir, returning an integer from a call whose fallback was a string; in Roc it does not compile, because a cannot be both.

Elixir is unusual in how much of itself is written as macros — if, unless, defstruct and |> among them — and a whole ecosystem depends on that, Ecto schemas and Phoenix routers most visibly. Roc's answer is that the language should have the constructs; whether that scales to a DSL is a question it has not had to answer yet.

use GenServer injecting default callbacks is the single most convenient thing in Elixir and the single hardest to read, because the module's behavior is not in the module. Removing it removes both halves, and an Elixir programmer will feel the loss before they feel the gain.

Elixir uses ! for something else entirely — "this raises instead of returning a tuple" — so the character is familiar and the meaning is not. What Roc's marker buys is a signature that is a guarantee: no ! means no reading, no writing, no printing, checked.

Elixir draws this boundary by discipline — a functional core with effects at the edges is the pattern every Elixir book teaches — and nothing enforces it. Roc enforces it and pays the usual price of colored functions: a pure helper that later needs to log must be renamed, and so must everything that calls it.

That matters for a command-line tool and matters much less for a server that starts once and runs for a year — which is what the BEAM was built for. The comparison is not "faster"; it is that the BEAM's startup cost buys preemptive scheduling, per-process heaps and observability that a native binary does not have.

The BEAM already solved the pause problem differently and well: per-process heaps mean a collection stops one process, which is why the BEAM has predictable latency under load. Roc's answer is no collection at all, which is stronger for one program and has nothing to say about ten thousand concurrent ones.

Observer, :recon and remote-shelling into a production node are among the strongest arguments for the BEAM, and this is the counterweight to the type system: Roc moves knowledge to compile time and has correspondingly less available at run time. Which you want depends on whether your hard problems happen before or after deployment. The columns differ by one colon, because the Elixir side is printing a real answer and the Roc side a string standing in for one it cannot get.

Elixir has had a stable core for a decade on a VM with a decade and a half more behind it, and the ecosystem to match. That is worth weighing against everything else on this page — a language is not only its design, and the Processes section already named what a rewrite would be giving up.

This is the first thing that surprises nearly everyone, and it surprises quietly — the arithmetic is exact and correct, but 6 prints as 6.0. Any example whose printed form matters should say which number type it means.

This catches Elixir programmers more than anyone, because rebinding is so ordinary there and looks identical. The idiomatic Roc version is usually a fold; var exists for when a loop genuinely reads better.

Elixir readers will recognize the idea: true and false there are atoms, and a Roc tag is the same kind of thing. Roc's True and False are the tags of its Bool type, so they behave as booleans until a tag from outside that type joins them in the same value.

An Elixir programmer is the least likely reader to be caught by this, because |> is already the habit and method syntax was never on offer. The trap is the other way round: seeing numbers.len() in the standard library and assuming your own functions work the same way.

Leaving the annotation off works too, since an inferred error type is open already. The failure mode is worth recognizing: the message names a payload type rather than the annotation, so it points at the ? and not at the signature that caused it.