Python.CodeCompared.To/Roc

The _args parameter is named with a leading underscore for the same reason it would be in Python: the value is required by the signature and unused by the body. Ok({}) is the return value — {} is the empty record, Roc's equivalent of returning nothing.

The platform on this page provides exactly one effect, echo!, which is why none of these examples open a file or a socket. A different platform gives the same application code a filesystem, a web server or a microcontroller, chosen when the program is built rather than imported at run time.

Because the exit status is the function's return value rather than a side effect, the compiler checks it like any other value. There is no way to forget to report failure and no way to report it with the wrong type.

The count : I64 line is a type annotation, and unlike a Python type hint it is checked by the compiler rather than ignored at run time. Writing it is optional here — Roc would infer a type — but it pins down which number type this is, which matters for what gets printed.

The Python call double("ab") succeeds and prints abab, which is exactly the kind of accident duck typing permits. The Roc equivalent is rejected at compile time with a message naming both types.

The Python version happily repeats a list, because a hint constrains nothing at run time. Note also that the count is a U64: Roc distinguishes signed from unsigned integers, and a repetition count cannot meaningfully be negative.

I64.from_str returns a Try because the text might not be a number, and ?? supplies the fallback. That is the whole conversion story: parse, then handle the failure, with no third option.

Point here is an alias, not a new type — the literal { x: 1, y: 2 } is already a Point because it has those fields with those types. Nothing was constructed, registered or subclassed.

This is stricter than it first looks: each step of a calculation needs its own name, which rules out the whole family of bugs where a variable quietly means something different fifteen lines further down. A duplicate definition is a warning rather than an error, and that is deliberate: Roc runs code that has problems so you can try something quickly, and the roc command then exits with status 2, so the rebinding cannot survive a continuous-integration check. This page runs the program regardless and shows it as a success, with the name taking the new value from that point on.

A var is local to the function it is declared in and cannot escape it, so there is no Roc equivalent of a mutable global or a mutable default argument.

The Python version prints [1] then [1, 2], which is the famous gotcha. The Roc version prints [1] then [2], because empty is still empty after the first call and always will be.

The Python tuple prints as (1, [2, 3, 4]) despite being "immutable". In Roc, append produced a separate list and the original is untouched, which is why the two printed lines differ.

Note that the Python version has to name each key twice, because a dict has no destructuring form. Roc's { name, age } = person is closer to unpacking a dataclass, except that it needs no class.

Choosing U8 is a statement that the value fits in a byte, and the compiler holds you to it — byte = 256 would not compile. There is no automatic widening, so mixing sizes means converting explicitly.

The first line of each column shows the familiar binary-floating-point answer; the second is exact. In Roc the difference is one annotation, and Dec is the default rather than the opt-in.

Python's 17 / 5 gives 3.4 as a binary float; Roc's gives 3.4 as an exact decimal, because the exact binding is a Dec. The two would diverge on a value like 1 / 3 printed to enough places. They also part on integer operands: Python's / always produces a float, while Roc's / on two I64 values discards the remainder.

This is a genuine capability Python has and Roc does not. Arbitrary-precision arithmetic in Roc means a library implementing it over lists of digits, which is what Python's runtime is doing for you underneath.

The Python int("42") raises ValueError on bad input; the Roc I64.from_str returns a Try and ?? supplies the fallback, so nothing is thrown and nothing is ignored.

Underscores as digit separators work in both languages, which is why the same enormous literal is readable in each column. The Python line prints the next integer up, because int has no ceiling to hit.

Python's f-string calls str() on whatever it finds. Roc will not, so "${age}" is a type error naming I64 where Str was expected — an annoyance at first and a guarantee afterwards that nothing is stringified by accident.

The two Roc 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 object and no lookup at run time.

Python's in operator does substring search for strings and membership for collections; Roc keeps those separate, as Str.contains and List.contains, so the reader always knows which is meant.

Python's separator.join(parts) reads oddly to newcomers precisely because the separator is the receiver. Roc's ordering, Str.join_with(parts, separator), puts the thing being joined first.

There is no Char type in Roc and no way to subscript a string by position, which sounds restrictive until you remember how often a Python character index is wrong for text outside the Basic Multilingual Plane.

A heterogeneous list is not a Roc list at all: the values would have to share a type, which in practice means wrapping each in a tag. That is more typing, and it is also the compiler forcing the question of what the mixture actually means.

keep_if is filter and drop_if is its opposite. Because each call returns a new list rather than a lazy iterator, there is no generator-versus-list distinction to keep track of.

The argument order differs from functools.reduce: the starting value comes first, then the function. sum exists for the common case in both languages.

The ?? operator supplies a default and is the common case, which makes the whole thing about as short as Python's numbers[1] while still being total. There is no version of this that can raise.

The last line shows numbers unchanged after two sorts. The compiler may still reorder the elements in place when it can prove nothing else holds the list, so "returns a new list" costs nothing here.

Naming the operation removes the question of what a negative index or an omitted bound means. There is also no step argument, so numbers[::2] becomes a keep_if over the index.

Python's idiom for "the first match, or nothing" is next(...) with a sentinel, and the sentinel is the weak point — a legitimate None in the data is indistinguishable from no match. find_first returns a Try, which has no such ambiguity.

The argument order is element first, index second — the reverse of what enumerate yields. That is worth reading twice the first few times, because getting it backwards still type-checks whenever both happen to be numbers.

This is the single biggest change of habit for a Python programmer. "Pass a dict of options around" becomes "pass a record", and a typo in a field name stops being a KeyError discovered in production.

In Python, {**defaults, "retrys": 5} silently produces a four-key dict with a typo in it. In Roc the same mistake names a field the record does not have, and the program does not compile.

Nothing constructs an Employee here: the literal already is one. Equality and Str.inspect work on it because they work on every record, which is the part @dataclass(frozen=True, eq=True) is emulating.

insert returns a new dict rather than changing the old one, which is why the calls chain. get returns a Try, so ?? 0 is the direct equivalent of the second argument to Python's dict.get.

Because the index is part of the syntax rather than a runtime value, pair.2 is a compile error rather than an IndexError. There is no tuple unpacking with a star, and no variable-length tuple type.

Attaching the hex string to the variant, as Python's Enum does, would be a payload; keeping it in a function instead means the mapping is exhaustively checked. Add a fourth color and to_hex stops compiling, which is the thing an Enum cannot do for you.

The Python version needs a final raise for the case that should be impossible, and nothing checks that the three branches agree with the three shapes. The Roc version needs no such branch: a fourth variant makes the match incomplete and the program stops compiling.

Python's stand-in is a string, and a string is a bad discriminant: "mornign" compares false and nothing complains. The Roc match knows the union is exactly [Morning, Afternoon], so a misspelling is a compile error and a missing branch is too.

This is the part with no Python analogue. A Python function accepting "a string or a tuple or something" has a type nobody can write down; here the openness is in the signature, and the compiler still checks that every closed part is handled.

The two columns do the same work, and the difference is what the compiler knows. A malformed Python tree — a node missing a right key — is a KeyError at whatever depth it happens to be; a malformed Roc tree cannot be constructed.

Because it is an expression, every branch must produce the same type, and a branch that forgets to produce anything is an error. In Python, a case that forgets to assign message leaves it unbound and fails later.

The Roc version is a single expression, so there is no return in each branch and no risk of falling off the end of the function. A guard does not count toward exhaustiveness in either language, which is why the wildcard is still required.

This is one of the places where Python 3.10's structural pattern matching and Roc agree almost exactly, which makes it a good landmark when the rest of the syntax feels unfamiliar.

Python's match on a list that matches no case falls through and returns None, silently. Roc's compiler rejects a match whose patterns do not cover every possible list, so the three branches here are not a convention — they are required.

The Python column prints None for blue, which is what a missing case produces. Adding a variant to a Python Enum breaks nothing at the point of addition and everything later; adding one in Roc breaks every incomplete match immediately.

The Roc signature tells you at a glance that this function might not find anything. The Python one does not, unless someone remembered to write -> str | None — and even then nothing forces the caller to check.

Python's value or default is the shortcut people reach for, and it is wrong whenever the value can legitimately be 0, "" or an empty list. ?? tests whether the operation succeeded, not whether the result is falsy, so it has no such failure mode.

The important difference is not the syntax but the signature: parse_score announces that it can fail and names how. A Python caller has to know from documentation, or from being bitten, that int() raises ValueError.

One character marks every place a function can exit early, so reading a Roc function tells you its failure paths. In the Python column, numbers[0] looks like a plain subscript and is in fact a hidden exit from the function.

Notice that the Roc function cannot accidentally let a second, undeclared failure escape: choosing U16 makes the range check part of the parse. The Python version has to catch two unrelated exception types and keep that list in step with the body.

Python's assert is close in spirit and weaker in practice, since AssertionError is catchable and -O removes the check entirely. In Roc there is no flag that deletes a crash and no handler that swallows one.

Python's lambda is limited to a single expression, which is why it is unusable for anything substantial. Roc's closures have no such restriction — a body in braces may hold as many statements as it likes.

The Python loop-variable trap — building closures in a loop and finding they all see the last value — cannot happen here, because what was captured cannot afterwards change.

This is more ceremony than a Python signature and it buys two things: the option set has a name and a type, and adding an option is a change to one record rather than to every call site.

A Python 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 is known about it.

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

Because every branch must produce a value of the same type, an else is mandatory whenever the result is used. There is no way to write an if that leaves a name unbound, which is what the Python column risks if a branch is added later.

The same loop can be written as a method, words.for_each!(|word| echo!(word)), which is the form that chains. In pure code neither is available and the equivalent is fold or map, which produce a value rather than performing an action — not a restriction so much as a consequence, since there is nothing for a pure loop body to do.

There is no else clause on a Roc loop, so Python's while ... else has no equivalent — which is no great loss, given how few Python programmers know what it does.

Writing return on the last line would also work. Leaving it off is the convention, and it is the same convention that makes every if and match an expression.

Python's truthiness is convenient until the day if count: silently skips the zero case, or if value: treats an empty result the same as a missing one. Naming the test — is_empty() — costs a few characters and removes that whole family of bug.

CPython has no tail-call optimization and a default recursion limit of 1000, so the Python column has to raise the limit and is still consuming a stack frame per step. This is a case where the functional style is genuinely cheaper in Roc than it is in Python.

Adding an echo! to describe would not compile — the signature would have to change, and so would every caller. That propagation is the point: a function's purity is visible in its type rather than in a comment or a naming convention.

A failing expect prints every value that fed the expression, not just the expression that was false. That is a deliberate design goal of the compiler, and it is the thing most worth stealing whether or not you ever ship Roc.

The Python column closes the cycle on its third line 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 reference counting alone is sufficient — so there is no gc module to import, tune or disable.

Roc has no async keyword and no thread API of its own either. What concurrency a program can do is decided by the platform it is built against, which is a real limitation today given how few mature platforms exist.

This is why writing in an immutable style in Roc does not carry the cost it would in Python. Here both lists are printed, so both must exist and a copy really is made; drop the second echo! and the copy disappears.

Python does this work at import time, every time the module is imported, and the cost is paid on each process start. The Roc version has no startup cost at all, which is part of why a Roc binary starts in microseconds.

Method syntax works because the compiler resolves counter.describe() to Counter.describe(counter) from the type it already knows. There is no dictionary lookup, no method resolution order and no inheritance — there is no way to subclass a Roc type.

This closes off the whole dynamic-patching style that libraries like mock depend on, and with it the failure mode where a method appears or disappears depending on which modules were imported. The replacement is an ordinary function, which is what shout already was.

NewType exists only for the benefit of a separate type checker; at run time UserId(42) is the integer 42. Roc's distinction is enforced by the compiler that produces the program, so there is no mode in which it is skipped.

The fix is an annotation or a suffix: typed : List(I64), or 42.I64 on the literal itself. Once anything in the expression pins the type down, the rest follows.

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

This is the honest answer to "should I use Roc today": the language design is worth studying now, and the library is not ready for work you have to maintain. What is here is small, coherent and moving quickly.