JavaScript.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 — {} is the empty record, which is Roc's way of returning nothing.

The difference is that the list is checked. A Roc application cannot reach for an effect its platform does not provide, so there is no equivalent of code that works in Node and throws ReferenceError: window is not defined in the browser.

Because the exit status is a return value rather than a mutable global, the compiler type-checks it. There is no way to set it from three places and lose track of which one won.

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.

The third JavaScript line is the one worth staring at: NaN is not an error, it is a value, and it propagates silently through every subsequent calculation. Roc has no value that means "this arithmetic did not work".

The Roc version has two cases and needs no fallback, because the type says there are exactly two. The JavaScript version needs a third branch it can never fully trust — and typeof null === "object", a bug too old to fix, is exactly the kind of thing that lands in it.

Point is an alias, not a class: nothing is constructed and nothing is registered. The missing field in the second JavaScript call produces undefined and a plausible-looking string; in Roc it is a compile error naming y.

Everything the JavaScript column prints is a fact you had to memorize. In Roc there is nothing to memorize: an equality between different types does not compile, so there is no coercion table and no [] == false.

The JavaScript workaround in the second line is a well-known bad idea: it depends on key order and cannot represent undefined, functions or cycles. In Roc there is no reference to compare instead, so structural equality is the only thing == could mean.

JavaScript's falsy set — 0, "", NaN, null, undefined, false — is why if (count) silently skips zero and why an empty array being truthy surprises everyone once. Naming the test, is_empty(), removes the whole family.

Roc has no assignment to a field, so there is no shallow-versus-deep distinction to keep in your head. The original record is still intact on the second printed line, which is the guarantee Object.freeze is reaching for and only partly delivers.

Shadowing in a nested scope draws the same warning, which is stricter than const 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 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 its function and cannot escape, so there is no Roc equivalent of a mutable module-level binding, and no hoisting for it to interact with.

There is no default-value syntax (const { retries = 3 } = options) and no rest element in a record pattern, because a record's fields are known at compile time — a missing field is an error rather than something to supply a default for.

The second JavaScript line prints 9007199254740992, an integer one less than the one written. Choosing U8 in Roc is a claim that the value fits in a byte, and the compiler holds you to it: byte = 256 would not compile.

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

JavaScript's % is a remainder rather than a modulo, which is why -7 % 3 is -1 and catches people writing a wrap-around index. Roc's % returns a non-negative result for a positive divisor.

Roc has no such value in its integer types. A conversion that can fail returns a Try, so the failure is visible at the point it happens rather than surfacing as a NaN three functions later with no clue where it came from.

Underscores as digit separators work in both languages. The JavaScript column prints 9223372036854776000 for both lines — the literal was rounded to the nearest representable double on the way in, so adding one to it changes nothing and nobody is told.

A JavaScript template literal calls String() on whatever it finds, which is how [object Object] gets into log lines. "${age}" in Roc is a type error naming I64 where Str was expected.

The last two JavaScript lines are the reason this matters: + means addition or concatenation depending on operand types, and it associates left, so the answer depends on where the number sits. Roc's + has exactly one meaning.

Method syntax here is sugar: "ab".repeat(3) is resolved at compile time to Str.repeat("ab", 3). There is no prototype chain being walked and no method that could be missing at run time.

JavaScript's split also accepts a regular expression and a limit; split_on takes one literal separator.

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

A heterogeneous list is not a list in Roc: the values would have to share a type, which in practice means wrapping each one in a tag. That is more typing, and it is also the compiler asking what the mixture is supposed to mean.

drop_if is the opposite of keep_if and has no JavaScript counterpart short of negating the predicate. Because each call returns a real list rather than a lazy view, there is no iterator-versus-array distinction to hold in mind.

The starting value is not optional in Roc. JavaScript's reduce without one throws TypeError on an empty array, which is a runtime failure for a case the type system could have ruled out — and sum covers the common case in both languages anyway.

The third JavaScript line is the point: undefined is not an error, so it flows onward and becomes NaN, and the stack trace you eventually get names neither. ?? supplies a default when that is what you want, which keeps the Roc version about as short.

JavaScript's sort without a comparator converts every element to a string, which is why 10 lands between 1 and 2 — and it mutates the array while returning it, so both printed lines are the sorted one. The Roc column's second line shows the original untouched.

Naming the operation removes the question of what a negative or out-of-range bound means — a question slice and splice answer differently from each other, which is its own small trap.

find returns undefined when nothing matches, which is indistinguishable from finding an element that happens to be undefined. find_first returns a Try, so "no match" and "matched a value" are different shapes rather than the same one.

This split is deliberate. In JavaScript the extra parameters to map are the cause of the classic ["1","2","3"].map(parseInt) puzzle, where parseInt silently receives the index as its radix.

This is the biggest change of habit. A typo in a field name stops being undefined — flowing onward to become NaN or [object Object] somewhere else entirely — and becomes a compile error naming the field and the line.

The JavaScript column prints 4 for the typo case, because spread-then-override is really spread-then-add and the language cannot tell the two apart. Roc can, because it knows the field list.

The JSDoc comment in the JavaScript column is the closest equivalent, and it is a comment: it helps an editor and changes nothing about what runs. Equality and Str.inspect work on the Roc record without being asked, because they work on every record.

Roc's ?? is JavaScript's nullish coalescing operator doing the same job on a different shape: it takes the value out of an Ok and supplies the fallback for an Err. insert returns a new dict, which is why the calls chain.

Because the index is syntax rather than a runtime number, pair.2 is a compile error rather than undefined. The length is part of the type, so a two-tuple can never arrive with one element in it.

The JavaScript version needs a default branch for a case that should be impossible, and nothing checks that the branches match the shapes. The Roc version needs no such branch — and adding a third variant makes the match incomplete, so the program stops compiling until it is handled.

The frozen-object idiom is the closest JavaScript gets, and the second line shows its weakness: a misspelled member is undefined rather than an error. Color.Gren in Roc does not compile.

JavaScript's stand-in is a string, and a string is a poor discriminant: "mornign" compares false and nothing complains. Roc knows this union is exactly [Morning, Afternoon], so a misspelling is an error and so is a missing branch.

This is the part with no JavaScript analogue at all. A function that accepts "a string or an object or something" has a type nobody can write down; here the openness is in the signature, and the compiler still checks the closed part.

Both columns do the same work; the difference is what can be built. A malformed JavaScript tree — a node missing its right — is undefined at whatever depth it happens to sit, then NaN at the top. A malformed Roc tree cannot be constructed.

There is no fall-through and therefore no break to forget — the single most common switch bug simply has no way to occur. Every arm must also produce the same type, so an arm that forgets to produce anything is an error rather than an undefined later.

The JavaScript column is not wrong, but the 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.

JavaScript expresses the same thing by deliberately falling through empty cases, which reads identically to the accidental fall-through that comes from a forgotten break. Roc has one spelling and it means only the intended thing.

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

The JavaScript column prints undefined for blue, because a switch that matches nothing simply falls out of the function. Adding a member to a frozen-object enum breaks nothing at the point of addition and everything later; adding a variant in Roc breaks every incomplete match immediately.

JavaScript has two empty values with different histories and slightly different behavior, which is why every codebase has an opinion about which to use and a helper that treats them the same. Removing both removes the question and, with it, Cannot read properties of null.

There is no ?., because there is nothing to guard against — a record field always exists, so point?.x would be asking a question with only one answer. The chains of ?. that appear in real JavaScript are guarding against a shape the type system here does not permit.

The difference that matters is the signature. parse_score announces that it can fail and names how; a JavaScript caller has to know from documentation, or from being bitten, that this function throws — and catch gives you an any that might not even be an Error.

One character marks every place a function can exit early, so reading the body tells you its failure paths. In JavaScript any call at all might throw, which is why a try block tends to grow until it wraps everything.

Choosing U16 makes the range check part of the parse, so the Roc function has one failure and cannot grow a second one silently. The JavaScript version has to restate the bounds by hand and its catch will also swallow a TypeError from anywhere in the block.

A thrown Error is catchable by definition, which means someone three frames up can turn a genuine invariant violation into a logged warning and carry on with corrupt state. A crash has no handler to reach for.

The three JavaScript forms differ in ways that have nothing to do with adding numbers: hoisting, this, arguments, and whether the function can be a constructor. Roc's single form has none of those distinctions to learn.

The JavaScript column prints [3, 3, 3] — the classic var loop-capture bug, fixed in modern code by using let and by nothing in the language itself. The Roc version cannot express the bug: what was captured cannot afterwards change.

Both Roc lines print the same answer, because the two spellings are the same call. The JavaScript column's second line prints count is undefined: detaching the method lost its receiver, and nothing complained. That is why bind, call, apply and the arrow-function-to-preserve-this trick exist — and none of them is needed here, because the receiver is a parameter and a parameter cannot go missing.

This is more ceremony than a JavaScript 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. It also removes the destructuring-with-defaults-in-the-signature form, which is where JavaScript signatures become unreadable.

A JavaScript 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 prototype for it to qualify.

JavaScript needs the ternary precisely because its if is a statement, and a chain of them is the form everyone argues about formatting. Roc's braces make the nesting explicit without changing the operator.

The same loop can be written as a method, words.for_each!(|word| echo!(word)), which is the form that chains. There is no for...in to confuse it with, and no C-style counting loop at all.

There are no labeled breaks and no continue, so a loop that needs either is usually asking to be a fold or a keep_if instead.

Writing return on that last line would also work; leaving it off is the convention, and it is the same convention that makes if and match expressions. A Roc function cannot fall off the end and produce nothing, the way a JavaScript one returns undefined.

Both columns are the same function with the same limit, so the printed answers are the whole story: Roc gives 5000050000 and JavaScript gives RangeError. Proper tail calls are in the JavaScript specification and implemented by almost nothing — V8 shipped them behind a flag and removed them — so every frame is real, and the try exists only to make the failure visible instead of fatal.

Adding an echo! to describe would not compile: its signature would have to change, and so would every caller. That propagation is exactly what async does to a JavaScript call stack — the same coloring, applied to all side effects rather than only to time.

This is a genuine limitation as much as a simplification: what concurrency a Roc program can do is entirely decided by the platform it is built against, and the set of mature platforms is small. There is no language-level answer to "run these two requests at once".

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

The JavaScript 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 is sufficient — so the counts are inserted by the compiler and there is no collector, no generation, and no pause.

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

JavaScript does this work every time the module is loaded, and the cost is paid on each process start — which is a large part of why Node startup is measured in tens of milliseconds and a Roc binary starts in microseconds.

Method syntax works because the compiler resolves counter.describe() from the type it already knows. There is no prototype to walk, no method resolution order, and no inheritance at all — a Roc type cannot be subclassed.

Patching a built-in prototype is how two libraries end up defining incompatible versions of the same method, and how a method appears or disappears depending on import order. The replacement is an ordinary function — which is what shout already was before it was attached to anything.

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. Once anything in the expression pins the type down, the rest follows.

Writing Bool.True and Bool.False in full is never wrong, and it is the spelling Roc's own documentation favors; the bare tags are the same values.

What is here is small, coherent and moving quickly.

Roc's answer is that a young language has to earn that, and that the platform model makes it harder rather than easier: effects belong to the platform, so a library cannot simply reach for the network the way an npm package does. Read the language for its ideas; do not plan a production system around it yet.