Elm.CodeCompared.To/Roc

A Roc main! is a function of the program arguments that returns a Try (Ok({}) is success), and echo! is the one output effect the platform on this page provides. Where Elm renders main through its managed runtime, Roc runs main! on a platform that supplies each effect — the ! suffix is how the type system tracks which functions perform them.

greet is pure in both, and its type signature reads almost identically. The difference is echo!: any function that calls an effect must itself end in !, so effectfulness is visible right in the name and checked by the compiler — a lighter-weight version of the discipline The Elm Architecture enforces by routing all effects through update.

Roc drops Elm's let ... in keywords: inside a block, a plain name = value introduces a binding, and the block's final expression is its result. Both forbid rebinding, so neither has var or mutation. Note the string handling already diverging — Elm concatenates with ++, Roc interpolates with ${...}.

The only surface change is the numeric type name — Elm's Int is one of Roc's several fixed-width integers, here I64 — and the definition's |n| lambda. Roc converts a number to a string with the method .to_str() where Elm calls String.fromInt.

Roc writes the alias with a single colon and no type alias keywords: Person : { ... }. Record fields use : in the type and in the literal, where Elm uses : in the type but = in the literal. When you want a nominal type that will not unify with a look-alike record, Roc uses := instead — shown under Custom Types.

Roc has string interpolation — "${expr}" — which Elm deliberately omits, so Elm joins pieces with ++ and explicit String.fromInt conversions. Note Roc still converts the number by hand inside the braces (year.to_str()); interpolation splices strings, it does not stringify for you.

Elm writes String.join sep list; Roc offers the same as Str.join_with(list, sep), which can also be called method-style. Measuring size differs on purpose: Elm's String.length counts characters, while Roc has no String.length at all — "length" is ambiguous for Unicode, so you ask for exactly what you mean, here .count_utf8_bytes().

// is integer division in both. Where Elm has just Int and Float, Roc has I8…I128, U8…U128, F32/F64, and the fixed-point Dec. That precision has a catch: an unannotated literal defaults to Dec and prints as 1.0, so integers whose output matters need an annotation (whole : I64) or a suffix (42.I64).

The operations are the same idea with different names and shape: Elm's List.filter is Roc's .keep_if, and both have .map. But Elm threads the list through with the |> pipe, while Roc chains methods with dots — because this build of Roc has no |> operator at all (see The Pipe Operator). Lambdas are \n -> in Elm, |n| in Roc.

Elm's List.foldl and Roc's .fold are the same operation; Roc puts the starting accumulator first, then the combining function. Roc also ships shortcuts Elm's core lacks, like .sum(). And where Elm passes the bare operator (+) as a function, this Roc build wants an explicit |accumulator, n| closure.

Elm's List.head returns a Maybe, matched with Just/Nothing. Roc's .first() (and .get(i)) returns a Try instead, matched with Ok/Err — Roc has no Maybe type, so it reuses Try for "present or absent" as well as "succeeded or failed".

Dot access is the same. The one keystroke that differs: a record literal uses = in Elm ({ name = "Alice" }) and : in Roc ({ name: "Alice" }). Both are pure data with no methods, no this, and structural typing, so two records with the same fields are the same type.

The idea is identical; the syntax differs. Elm writes the record first and the changes after a bar: { alice | age = ... }. Roc spreads the original with two leading dots and lists the changes after: { ..alice, age: ... }. Both reuse the original's memory when nothing else references it, so the "copy" is often free.

Elm requires the type declared up front (type Light = Red | ...); Roc's tags are structural and need no declaration at all — writing Red gives the value the inferred type [Red, Yellow, Green]. Both check the case/match for exhaustiveness. Elm's Debug.toString and Roc's Str.inspect both render a value for display.

The payload rides along in both. Two differences: Roc wraps a variant's data in parentheses (Circle(radius)) where Elm uses juxtaposition (Circle radius); and here := declares Shape as a nominal type — one that will not unify with a look-alike tag union — which is Roc's opt-in when it wants Elm's default nominal behavior.

Instead of Elm's single built-in Maybe with its fixed Just/Nothing, Roc writes an ad-hoc tag union like [Found(I64), Missing] — no declaration needed, and the "absent" case gets a name that means something. When absence is really a failure, Roc uses Try instead; either way the missing case is a tag the compiler makes you handle.

The shape is the same — Ok on success, Err on failure, matched by pattern — so this transfers almost verbatim. Roc's type is spelled Try(ok, err) where Elm's is Result err ok (note the order flips), and Ok/Err take parenthesized payloads. Roc reuses this one type for both "might fail" and, as the previous rows showed, "might be absent".

Elm chains fallible steps explicitly with Result.andThen (or nested case). Roc's postfix ? does the threading for you: it unwraps an Ok and early-returns any Err to the caller, with ? |_| "not a number" here mapping the underlying error into our own. It is the ergonomic step Elm intentionally leaves as an explicit function call.

Same tool, lighter syntax: Elm's case x of with -> arrows becomes Roc's match x { } with => arrows and braces instead of indentation. List patterns line up closely — Elm's head/tail first :: _ is Roc's [first, ..]. Both compilers reject a match that misses a case.

The building blocks match, but the notation differs in two places: Roc's lambda wraps its parameters in pipes, |n| n * 3, where Elm uses a backslash and arrow, \n -> n * 3; and Roc separates a function's argument types with commas (I64, I64 -> I64) where Elm chains arrows (Int -> Int -> Int). Both curry, so partial application works in each.

This build of Roc has removed |> entirely. The same left-to-right reading is recovered with method-call chaining — value.first().second() instead of value |> first |> second — which works because Roc lets any function be called as a method on its first argument. It reads similarly, but a longtime Elm developer will reach for |> by reflex and have to stop.

Elm centralizes effects: your code returns Cmd values and the runtime performs them, so every effect flows through update. Roc marks effects at the function level with ! and hands the actual implementations to a platform the program is compiled against — the same Roc source can target a CLI, a web server, or this page's echo platform. Elm has one platform (the browser); Roc makes the platform a swappable choice.

The code looks the same and both keep values immutable, but underneath they differ sharply. Elm relies on the JavaScript runtime's tracing garbage collector. Roc uses automatic reference counting decided at compile time, and — because it can see when a value is no longer shared — it mutates in place instead of copying (opportunistic mutation), giving immutable code the performance of mutable code with no runtime GC pauses.