Lua.CodeCompared.To/Roc

The _args parameter is named with a leading underscore because it is required by the signature and unused by the body. Ok({}) is the return value, where {} is the empty record — Roc's way of returning nothing.

Roc makes the same arrangement part of the type system. An application declares which platform it is built against, and reaching for an effect that platform does not provide is a compile error rather than an attempt to index a nil value at run time.

Because the status is the function's return value, the compiler checks it like any other value. Lua's os.exit is unavailable in the browser runtime here anyway, which is a good illustration of the point above: what a host does not provide, a script does not have.

The count : I64 line is a type annotation. Writing it is optional — Roc would infer a type — but it pins down which number type this is, and that decides what gets printed.

Two differences in three lines: Roc indexes from zero, and get returns a Try rather than nil. The single element type is the bigger change — a Roc list cannot hold a number and a string at once.

This is the biggest change of habit. A typo in a field name stops being nil — flowing onward until something tries to index or add it — and becomes a compile error naming the field and the line.

A Dict knows its own size, so there is no counting loop. insert returns a new dict rather than changing the old one, which is why the calls chain, and ?? does the job Lua's or does here without the falsy-value trap.

The Lua version needs a final error for the case that should be impossible, and nothing checks that the branches match the shapes. The Roc version needs no such branch — add a third variant and the match becomes incomplete, so the program stops compiling until it is handled.

The second Lua line is the one worth staring at: passing a string does not fail, it coerces, and the arithmetic goes ahead as though nothing happened. The result is also a float rather than an integer, so a calculation that looked like integer arithmetic quietly stopped being any such thing.

The Roc version has two cases and needs no fallback, because its type says there are exactly two. The Lua version needs a third branch it can never fully trust, and that branch is where nil lands.

Point is an alias, not a class: nothing is constructed and nothing is registered. A missing field in Lua produces nil and then an error somewhere else; in Roc it is a compile error naming y.

Nothing is mutable at the top level either, so there is no equivalent of a module that changes a global and no setfenv-style sandboxing problem. A missing local cannot be a bug because there is nothing to omit.

Shadowing is not available either, so each step of a calculation needs its own name. That rules out the family of bugs where a variable quietly means something different fifteen lines further down.

A var is local to its function and cannot escape it, so a mutable value can never be shared between two parts of a program that do not know about each other.

The Lua column prints 99 because original and other were always the same object. The Roc column prints 2 then 99: set produced a separate list, and the compiler mutates in place only when it can prove nobody else is holding the old one.

Lua has to name each key twice because a table has no destructuring form. Where Lua's multiple assignment pads with nil when the counts disagree, a Roc tuple's length is part of its type and cannot disagree.

The Roc signature tells you at a glance that this might not find anything, and the compiler will not let the caller skip the Missing case. In Lua, forgetting the ~= nil check produces attempt to concatenate a nil value at a line that is not the one with the bug.

Roc has no such collision, because absence is an ordinary tag. Unset is a value you can store, pass, compare and match on, and Times(0) sits beside it in the same union — so "not configured" and "configured to zero" are different values rather than the same nil. The Lua column's third line proves the point: it is indistinguishable from the first.

The difference is what is being tested. Lua's or tests truthiness, so a legitimate false is replaced by the default — the third line prints 3. ?? tests whether the operation succeeded, so a successfully-fetched false stays false.

What you give up is if value then as a shorthand for "is this present". What you get back is that every condition says what it is testing, so nobody has to recall which of 0, "" and {} counts as true in which language.

Choosing U8 is a claim that the value fits in a byte, and the compiler holds you to it — byte = 256 would not compile. There is no automatic widening either, so mixing sizes means converting explicitly rather than hoping the subtype rules agree with you.

The first line of each column is the familiar binary-floating-point answer. The second is where they part: Lua rounds for display and still holds the wrong number, while the Roc value is exact and stays exact through the next hundred operations.

Both languages give 3.4 here, and they would part on a value like 1 / 3 printed to enough places. Lua's / always produces a float even when both operands are integers, which is the rule // exists to escape.

Lua's tonumber returns nil on bad input, which is the right shape and the wrong value — it is indistinguishable from a table lookup that missed. I64.from_str returns a Try naming the failure, and ?? supplies the fallback.

The Lua column prints true: adding one to the largest integer produces the smallest one, silently, which is exactly the behavior a checked arithmetic type exists to prevent. Underscores as digit separators are a Roc convenience Lua does not have.

Lua's .. does convert, which is convenient until a nil arrives and the error names the concatenation rather than whatever produced the nil. "${age}" in Roc is a type error naming I64 where Str was expected.

The two forms are the same function: "a".concat("b") is resolved at compile time to Str.concat("a", "b"). Method syntax in Roc is sugar over a function call, with no metatable lookup and no __concat to define.

The first Lua line is the standard trim idiom, and it is a pattern with four metacharacters in it. Lua's patterns are more powerful than any of these four functions; the trade is that the common cases need no pattern at all. Str.inspect turns a non-string value into something printable.

Lua has no split function at all, which is why every Lua codebase contains the gmatch loop above. Roc has no pattern language to make up for it, though: splitting on a literal string is the only option here.

The difference is what else is available. Lua adds a utf8 library for character counting and offsets; Roc has no Char type and no way to subscript a string by position at all, so text is taken apart with operations that respect UTF-8 by construction.

Reading past the end is where the two really differ, though. Lua answers nil for any index it does not have, including 0, so an off-by-one becomes a nil that travels. Roc answers Err, which the compiler makes you handle at the point of the read.

That permission is not theoretical: this very example prints 3 on some Lua implementations and 1 on others, from identical source, and both are conforming. A Roc list stores its length, so len() is a fact rather than a search and it is constant-time — and there is no way to create a hole in the first place, because there is no way to assign nil into the middle of anything.

keep_if is filter and drop_if is its opposite. Each call returns a real list rather than a lazy view, so there is no iterator protocol to understand and no ipairs-versus-pairs decision to make.

The starting value is not optional, so there is no empty-list special case to get wrong. sum exists for this particular fold because it is so common, and Lua has no equivalent of either in its standard library.

The last Roc line shows numbers unchanged after two sorts. table.sort has no such option — it always rearranges the table you gave it, which matters when that table came from somewhere else.

Lua's nearest equivalent is table.move with four index arguments, which is powerful and easy to get wrong by one. Naming the operation removes the arithmetic from the call site.

The Lua idiom for "the first match, or nothing" leans on nil twice — once as the sentinel and once in the and/or that reports it — and breaks if a legitimate element is false. find_first returns a Try, which has no such hole.

Note that the printed indices differ, and that is the zero-based change rather than anything about the method: ipairs starts at 1 and map_with_index starts at 0.

Lua has no spread, so the copy is a loop, and there is nothing stopping custom.retrys = 5 from adding a fourth key. In Roc the same typo names a field the record does not have, and the program does not compile.

The Lua constructor function is doing two jobs: documenting the shape and enforcing the field order. Neither is needed here, and equality and Str.inspect work on the Roc record without being asked, because they work on every record.

Lua's multiple returns are adjusted silently to the context — extra values dropped, missing ones filled with nil — so a function that returns two things and a caller expecting three both "work". A Roc tuple's length is part of its type and cannot disagree.

Lua compares tables by reference unless a __eq metamethod says otherwise, and defining one correctly for a nested structure is real work. Because a Roc value cannot be mutated, there is no reference to compare instead, so structural equality is the only thing == could mean.

The table-of-constants idiom is the closest Lua gets, and the second line is its weakness: a misspelled member is nil rather than an error. Color.Gren in Roc does not compile.

Lua's stand-in is a string, and a string is a poor discriminant: "mornign" compares false and nothing complains. Roc knows the union is exactly [Morning, Afternoon], so a misspelling is an error and so is a missing branch. Note also that the Lua and/or idiom breaks entirely if the "then" value is ever false.

This is the part with no Lua analogue. A function accepting "a string or a table or something" has a type nobody can write down; here the openness is stated in the signature, and the compiler still checks the closed part exhaustively.

Both columns do the same work; the difference is what can be built. A malformed Lua tree — a node missing its right — is nil at whatever depth it sits, and the error names the arithmetic rather than the structure. A malformed Roc tree cannot be constructed.

Because it is an expression, the whole thing sits on the right of one =, every branch must produce the same type, and a branch that forgets to produce anything is an error. The Lua column has to declare message first and hope every path assigns it.

The Lua column is not wrong, but its shape hides something: nothing checks that the ladder is complete, and the final return is doing the work of a wildcard without being marked as one.

Lua has no way to match on shape, so the same logic becomes length comparisons and indexing. Roc's compiler rejects a match whose patterns miss a possible list, so these three arms are required rather than conventional.

The Lua column prints nil for blue, because a function that falls off its end returns nothing. Adding a member to a table of constants breaks nothing at the point of addition and everything later; adding a variant in Roc breaks every incomplete match immediately.

This is a small win on numbers and a large one on tags with payloads, where each Lua alternative would otherwise repeat both the field access and the comparison.

Two things change. The signature announces that this function can fail and names how, so no caller has to guess whether pcall is needed. And the error is a typed tag rather than a string, so matching on it does not mean parsing prose.

One character marks every place a function can exit early, so reading the body tells you its failure paths. In Lua any call at all might raise, which is why a pcall boundary tends to be drawn around whole subsystems rather than individual operations.

Lua can raise a table rather than a string — the workaround above — but nothing checks its shape, so the handler's result.text is a guess. Choosing U16 in the Roc column also makes the range check part of the parse, so the bounds are not restated by hand.

Lua's assert is close in spirit and weaker in practice, since a pcall anywhere up the stack will catch it and carry on with whatever state caused it. A crash has no handler to reach for.

This will feel familiar: Lua's local function f() is already sugar for assigning an anonymous function, and functions are first-class values in both languages. The parameter list uses | rather than parentheses, which is the only visual change.

Roc closures capture values, so that whole idiom is unavailable and the state has to be passed along explicitly. This is a genuine loss of expressiveness in exchange for a genuine guarantee: nothing that was captured can change afterwards, so no two closures can disagree about it.

The Lua column shows the cost of the alternative: three lines of or defaulting before the function does any work, and a nil in the middle of the second call because there is no way to skip a positional argument. Adding an option in Roc is a change to one record rather than to every call site.

A Lua function is generic by accident, because nothing checks it. A Roc one is generic on purpose, and the signature is a promise: a -> a cannot inspect the value, because nothing at all is known about it.

This is the closest thing Roc has to an interface, and it is structural: no type declares that it satisfies the clause, it simply has the method or it does not. Nothing has to be added to a metatable for it to qualify.

Lua's cond and a or b idiom exists precisely because its if is a statement, and it is subtly broken whenever a can be false or nil. Roc needs no such trick, because if already is the expression form.

There is one loop form rather than Lua's numeric-and-generic pair, and no index to discard — so the _ in ipairs disappears. The same loop can also be written as a method, words.for_each!(|word| echo!(word)), which is the form that chains.

There is no repeat ... until and no goto, so a loop that wants either is usually asking to be a fold instead.

Lua requires return to be the last statement in a block, which is why its guard clauses sometimes need an extra do ... end. Roc has no such restriction, and a function cannot fall off its end producing nothing.

This is one of the few places Lua and Roc simply agree, and both columns print 100000. Lua guarantees proper tail calls too, which is why return f(x) in Lua is genuinely different from local y = f(x); return y — the second one is not in tail position and does grow the stack.

Adding an echo! to describe would not compile: its signature would have to change, and so would every caller. That is the same propagation Lua sandboxes try to achieve by removing functions from the environment, done in the type system instead.

For the generator case the replacement is to build the whole sequence, which is fine when it is small and wrong when it is large or infinite. For the cooperative-scheduling case there is no replacement in the language at all — concurrency belongs to the platform, and what a given platform offers is its own decision.

A failing expect prints every value that fed the expression, not just the expression that was false. Lua's assert prints only the message you remembered to pass it, which is why so many of them say nothing useful.

The Lua column closes the cycle and prints twice; the Roc column cannot, so it prints once. 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 counts are inserted by the compiler and there is no collector to tune, step or pause.

That is why writing in an immutable style costs less in Roc than the copy-the-table-first style costs in Lua. Here both lists are printed, so both must exist and a copy really is made; drop the second echo! and the copy disappears.

Lua does this work every time the chunk is loaded. Both languages start fast — Lua's tiny interpreter is one of its selling points — but a compiled Roc binary has no load step at all and needs no interpreter alongside it.

Method syntax works because the compiler resolves counter.describe() from the type it already knows, so there is no table to look up and no chain to walk. The colon-versus-dot distinction disappears with self, and so does the bug where one of them is written where the other was meant.

What you lose is the notation. What you lose along with it is __index, __newindex, __call and the rest — which means no value in a Roc program can behave differently from how it reads, and no library can change what an operator does to types it did not define.

This is the mechanism behind "parse, do not validate": once a value has been through UserId, every function downstream knows it was checked, and the compiler will not let an unchecked number take its place.

The fix is an annotation or a suffix: typed : List(I64), or 42.I64 on the literal. Lua 5.3 has a mild version of the same surprise — 7 / 2 is a float even when both operands are integers — so the instinct to check which numeric type you have is already there.

Annotating the binding, or writing Bool.True and Bool.False in full, pins it down. Note also that negation is ! rather than not, and that != replaces ~=.

Use get(index), and first() or last() for the ends. Remember that the index is zero-based and is a U64, so there is no negative index and no #numbers arithmetic to do.

Lua's standard library is famously small and this one is smaller. The compensation is in the other direction: Lua leaves you to write map, filter, split and a class system, all of which Roc provides.

A Roc platform and a Lua host answer different questions. A host embeds Lua so that behavior can be changed without recompiling; a Roc platform exists so that a pure application can be compiled against whichever set of effects a target needs. If your requirement is user-supplied scripts at run time, Roc has no answer for it.