Kotlin.CodeCompared.To/Roc

The _args parameter is named with a leading underscore because it is required by the signature and unused — Kotlin uses the same convention for an ignored lambda parameter. Ok({}) is the return value, where {} is the empty record: Roc's Unit.

The difference is that the list is checked at compile time rather than discovered at link time. A Roc application cannot reach for an effect its platform does not provide, which is the compiled-in version of what Kotlin Multiplatform's expect/actual declarations are reaching for.

Because the exit status is the function's return value, the compiler type-checks it. There is no way to call exitProcess from deep inside a library and skip every finally block on the way out.

The count : I64 line is a type annotation on its own line above the definition, rather than after the name as in Kotlin. Writing it is optional, but it pins down which number type this is — and that decides what gets printed.

The trade is readability at a distance, and Roc convention answers it the same way Kotlin's explicit-API mode does: annotate top-level functions. The difference is that the compiler checks a Roc annotation against the inferred type rather than taking it as the definition.

Point here is an alias, not a class — nothing is constructed and no name appears at the call site. When you want Kotlin's nominal behavior, := instead of : gives it to you; see the value-class row in Gotchas.

The Roc version has two cases and needs no fallback, because its type says there are exactly two. The Kotlin version needs a third branch for everything it was not designed for, and that branch is where a mistake lands silently.

The practical difference is that a Roc "nothing" can say which nothing. Missing, NotYetLoaded and Refused are three different values in the same union, where Kotlin would have one null for all three and a comment explaining which is meant.

Those two holes are the reason a Kotlin codebase can still throw NullPointerException. They exist for a good reason — interoperating with a hundred million lines of Java — and a language with no Java behind it does not need them.

The difference is what it tests. Kotlin's Elvis tests for null, so a function must choose null as its failure signal and cannot say why. ?? tests whether the operation succeeded, and the Err it discards could have carried a reason.

The Roc column is longer, and that is the honest trade: ?. chains are genuinely concise. What they hide is that each link silently short-circuits the whole expression, so a null four levels down and a null at the top are indistinguishable at the end of the chain — the match version has to say which.

The Kotlin column prints [1, 99, 3] twice, because updated and numbers are the same list; the Roc column prints the changed one and then the original, untouched. Kotlin's List versus MutableList split is a real improvement over a language with only one, and it is a read-only view: the same underlying list can still be mutated through another reference to it. In Roc there is no mutable version to be a view of.

Shadowing is unavailable too, which is stricter than val in a nested block. Each step of a calculation gets its own name, so a variable cannot quietly mean something different fifteen lines further down.

A var is local to its function and cannot escape, so there is no top-level mutable state and nothing a second part of the program could reach. Kotlin's var can be a property, a top-level declaration, or captured by a lambda.

Kotlin's destructuring is positional, driven by component1(), component2() and so on — so reordering two fields of a data class silently swaps them at every destructuring site. Naming the fields cannot go wrong that way.

What Roc removes is the hierarchy. There is no base class, no subclass per variant, no is check and no requirement that they live in the same module — the union is written where it is used, in one line, and the variants are values rather than types.

Kotlin needs the enum class line and the qualified Period.MORNING at every mention. The exhaustiveness guarantee is the same — both compilers reject a missing branch — but Roc gets it without a declaration, which changes how readily you reach for a union at all.

This has no Kotlin equivalent. A sealed hierarchy is exhaustive precisely because it is closed, so "these two, plus whatever else turns up" means falling back to Any and losing the check on the two you did name. Roc keeps the closed part closed and the open part open, in one type.

Both columns are checked and both are exhaustive; the difference is nine lines against six, and the absence of a class per case. A Kotlin Tree is also a reference, so every node is a heap allocation the collector has to trace; the Roc one is reference counted with no collector behind it.

The one asymmetry is where the check applies. Kotlin requires exhaustiveness when the when is used as an expression, and — before it was tightened — a statement-position when over a sealed type could silently do nothing. Every Roc match is an expression, so the question does not arise.

Neither language widens implicitly, so mixing sizes means converting. What Roc adds is Dec, a fixed-point decimal type with no Kotlin equivalent short of java.math.BigDecimal; what it removes is boxing, since a Roc number is never an object.

BigDecimal is the Kotlin answer and it costs a different type, methods instead of operators, and a constructor that must take a string or silently inherit the float error it was meant to avoid. The difference between the two Roc lines is one annotation.

That decision is the trap: 17 / 5 and 17.0 / 5.0 are different operations spelled almost identically, and changing a variable from Int to Double silently changes which one runs. Two operators cannot be confused that way.

The Kotlin column prints the smallest Long, because the JVM defines signed overflow as wrapping. That is predictable and it is still a bug every time it happens. Underscores as digit separators work in both languages.

Kotlin's interpolation calls toString() on whatever it finds, which is how a data class's generated toString ends up in a user-facing message. "${age}" in Roc is a type error naming I64 where Str was expected.

Kotlin's String.plus accepts Any?, so "count: " + someObject compiles for every object and prints whatever toString gives — including a default like Foo@1b6d3586. Requiring two strings makes that a compile error.

Method syntax here is sugar: "ab".repeat(3) is resolved at compile time to Str.repeat("ab", 3). That is the same relationship a Kotlin extension function has to its receiver, which is why the two read alike.

What is missing is the rest of it: no Regex, no joinToString prefix, postfix or transform arguments, and no trimIndent. Kotlin's string library is unusually rich and this build's is unusually thin.

Roc has no Char type and no way to subscript a string by position, which sounds restrictive until you count how much JVM string code is quietly wrong for anything outside the Basic Multilingual Plane.

Kotlin has List, MutableList, ArrayList, Array and the primitive arrays, and choosing between them is a real decision with real performance consequences. A Roc List(I64) stores the integers themselves, where a Kotlin List<Int> stores boxed Integer objects.

Roc has no Sequence and no asSequence(), so there is no eager-versus-lazy decision and no intermediate-collection question to think about. That is simpler and it is also less powerful — a chain over a large list really does build each intermediate result.

Roc has no trailing-lambda syntax and no it, so every parameter is named. That costs a few characters per call and removes the question of what it refers to in a nested chain.

That asymmetry is the whole difference. The safe Kotlin form is longer than the unsafe one, so the unsafe one is what gets written; in Roc the safe form is the only form, and ?? makes it about as short as a subscript.

Kotlin already made the right default here — sorted() on a read-only List returns a copy, and only MutableList gets sort(). Roc arrives at the same place by having nothing to sort in place.

firstOrNull on a List<Int?> cannot distinguish "no match" from "matched a null", which is a small hole and a real one. A Try has no such ambiguity because the wrapper and the value are different things.

Note the argument order is reversed: Kotlin gives the index first, Roc gives the element first. Getting it backwards still type-checks whenever both happen to be numbers, so it is worth reading twice the first few times.

Nothing constructs an Employee: the literal already is one, because it has those fields with those types. The cost is that Roc's version is structural, so any record with the same fields fits — which is a feature until you wanted the two to be distinct.

This is another place Kotlin is already there. The difference is that copy() is generated per data class, so it exists only where someone wrote data; the spread works on every record because every record has a known field list.

insert returns a new dict rather than changing the old one, which is why the calls chain — the read-only Map plus plus() shape rather than MutableMap. get returns a Try where Kotlin's [] returns a nullable.

The second Roc line shows what that buys — a list of pairs, with no type declared. Kotlin can write List<Pair<Int, Int>>, and at four elements it runs out of classes and you write a data class instead.

Both are expressions, both require every arm to produce the same type, and neither falls through. This is the row where a Kotlin programmer will feel most at home on the whole page.

The first arm shows why that matters: 0 is a pattern the compiler counts toward exhaustiveness, while every arm of a subjectless Kotlin when is a condition it cannot reason about. A guarded arm never counts in either language, which is why the wildcard is still required.

Kotlin has no list pattern, so the same logic switches on a size and then indexes, and the compiler cannot connect the two: numbers[0] in the size-1 arm is bounds-checked at run time like any other subscript. In the Roc version the binding is the check.

It matters more in Roc than in Kotlin, because the alternatives can be tags carrying payloads rather than only constants — and the bound names have to agree across them, which the compiler checks.

The important difference is the signature. parse_score announces that it can fail and names how; Kotlin removed checked exceptions deliberately, so toInt() gives no hint at the call site that a catch is needed. toIntOrNull() is the closest Kotlin gets, and it loses the reason.

The Roc version names its failure as a tag, so the signature lists exactly what can go wrong and a match that misses one does not compile. Result<Int> says only "an Int, or some Throwable", which puts the reader back to reading documentation.

One character marks every place a function can exit early, so reading the body tells you its failure paths. In Kotlin any call at all might throw — first() above looks like a plain accessor and is in fact a hidden exit.

Kotlin's require throws IllegalArgumentException, which a catch (error: Exception) three frames up will happily swallow — turning a genuine invariant violation into a logged warning and a program that carries on with the state that caused it.

Kotlin has two, and they differ in more than syntax: a fun can be an extension, can have default parameters and can be inlined, while a lambda cannot. Roc's single form has none of those distinctions and none of the corresponding capabilities.

The Kotlin column prints 1005, not 15. That is a deliberate Kotlin improvement over Java's effectively-final rule, and it is also a way for a lambda's result to depend on when it is called rather than on when it was made.

This is a genuine step backwards from Kotlin, whose default-and-named arguments are among its best features. What the record buys is that the option set has a name and a type, and that adding an option changes one record rather than every call site.

Roc's generics are also not erased. A Kotlin List<Int> is a List of boxed objects at run time, which is why reified exists and why is List<String> cannot be checked; Roc monomorphizes, so the type is real all the way down.

Nothing declares that Celsius satisfies the clause: it has the method, so it fits. There is no interface to define, no override to write, and no way for a type you do not control to be locked out of a function because its author did not think of your interface.

The only differences are punctuation: Roc drops the parentheses around the condition and requires braces around each branch. In both, an else is mandatory when the result is used.

There is no range syntax — no 1..10, no downTo, no step — so a counted loop iterates a list or uses while. The same loop can also be written as a method, words.for_each!(|word| echo!(word)), which is the form that chains.

There are no compound assignment operators, so count += 1 is written out. There are no labeled breaks and no continue either, so a loop that wants them is usually asking to be a fold or a keep_if.

There is no labeled return (return@forEach), which is the mechanism Kotlin needs because a lambda's return would otherwise leave the enclosing function. A Roc closure's return leaves the closure, with no ambiguity to label away.

The tailrec modifier is a good design: it is opt-in, and the compiler warns when a function marked with it is not actually tail-recursive. Drop the modifier from the Kotlin column and the same function overflows the stack.

The consequence is the one suspend has: a pure function that gains a print has to change its signature, and so does every caller. That propagation is the feature — it means a signature without ! is a guarantee rather than a convention.

The reasoning is the platform model: a platform written in Rust may well run an application's work across every core, and the application stays pure code that says what to compute rather than when. That is coherent, and next to kotlinx.coroutines it is also the largest single thing this page asks you to give up.

A failing expect prints every value that fed the expression, not just the expression that was false. That is what a Kotlin assertion library like Kotest's power-assert gives you as a compiler plugin, and it is built in here.

Method syntax works because the compiler resolves counter.describe() from the type it already knows, so there is no vtable and no virtual call. There is also no inheritance at all: no open, no override, and no way to subclass a Roc type.

This is a real loss. What softens it is that Kotlin extensions are already static dispatch under a method-call spelling, so the Roc version is the same call with the receiver moved to the front — and that a Roc where clause can accept any type carrying the right method, which covers a good share of what extensions are used for.

Both are zero-cost: Kotlin inlines the wrapper where it can, and Roc monomorphizes so the wrapper never exists at run time. The Kotlin version still leaks on the JVM boundary — a value class is boxed when used as a generic argument or a nullable — where the Roc one has no boundary to leak across.

Nothing in Roc can be made to point back at a value that already exists, which is exactly the condition under which counting alone suffices — so the retain and release calls are inserted by the compiler and there is no collector, no generation and no pause to tune. The Kotlin column needs a var and a nullable to build the cycle, which is the cost on screen.

That is why an immutable style costs less in Roc than toMutableList() costs in Kotlin. Here both lists are printed, so both must exist and a copy really is made; drop the second echo! and the copy disappears.

Kotlin has const val for the cases the compiler can fold, and it is limited to primitives and strings; anything else is a val initialized when its class is loaded. In Roc there is no distinction, and no class loading and no JVM startup behind it.

The difference is where the line falls. Kotlin's shared code may still perform effects — it is ordinary Kotlin — and expect/actual covers only what differs. A Roc application performs no effects of its own, so the line is not a judgment call, and the same application can target a command-line tool, a server or a microcontroller unchanged.

Kotlin/Native is the same ambition and it is a second target with a second memory model and a smaller library ecosystem — the JVM remains where the libraries are. Roc has one compilation model, and its equivalent question is which platform you build against.

The fix is an annotation or a suffix: typed : List(I64), or 42.I64 on the literal. Kotlin defaults an integer literal to Int and only widens on demand, which is the friendlier choice — but the habit of asking which numeric type you have transfers directly.

Annotating the binding, or writing Bool.True and Bool.False in full, pins it down. It is the same inference rule that turns untyped numbers into Dec, seen from another angle.

Use get(index), and first() or last() for the ends. Note that Roc's last() returns a Try where Kotlin's throws on an empty list, so the two spellings look alike and behave differently.

Every lambda parameter is therefore named, which costs a few characters and removes the question of what it refers to three levels into a chain. The scope functions mostly existed to work around nullability and to build objects with mutable properties, and neither problem exists here.

There is also no regular-expression support, no serialization, no date and time library, and nothing resembling the JVM ecosystem behind it. Kotlin's library is among the best-designed of any mainstream language; this is not a fair comparison and it is a real one.

So the honest summary is narrow. Roc goes further on exactly one axis — removing null entirely, dropping the declaration a union needs, allowing unions to stay open, putting all effects in the type system, and replacing the collector — and gives up coroutines, extension functions, default arguments, the JVM and fifteen years of libraries to do it. Read it for that axis.