TypeScript.CodeCompared.To/Roc

The ! suffix on main! and echo! marks them as effectful functions — Roc tracks purity in the type system. main! receives the program arguments as a list and returns a Try: Ok({}) means success. There is no ambient console object; echo! is an effect provided by the platform hosting this program.

This is the deepest difference between the two worlds. A TypeScript program assumes a runtime — Node, Deno, or a browser — whose entire API surface is ambiently available to every module. A Roc program cannot perform any I/O on its own: it is embedded by a platform — a host written in another language — and the platform decides exactly which effects exist. This page runs your code on the minimal "echo" platform, whose only effect is echo!. The upside is that a platform can make hard guarantees: a Roc plugin literally cannot touch the filesystem unless its host offers that effect — a sandbox npm install can only dream of.

In Node you signal failure by assigning process.exitCode or throwing from the top level. Roc's main! returns a Try: returning Err(SomeTag) makes the program exit with code 1, and Ok({}) exits cleanly. {} is Roc's empty record — the closest thing to void, except it is a real value you can pass around.

Roc annotations live on their own line above the definition — name : Type — rather than inline after a colon. Both languages make annotations optional thanks to inference, but Roc's are never erased: they are checked, drive code generation, and cannot be silenced with an as cast. Note the capitalized builtin names: I64, Str, Bool, List(a) — generics use parentheses, not angle brackets.

Roc uses full Hindley–Milner inference: parameter and return types are inferred from use, so double needs no annotation at all — the result : I64 annotation downstream pins the number type. TypeScript infers in one direction (from values to variables); Roc's inference flows both ways through the whole program, which is why idiomatic Roc code annotates top-level functions for documentation, not necessity.

TypeScript's type system is deliberately unsound: any, as, and ! assertions let values escape checking, and the erased types can lie at runtime. Roc has none of these — there is no way to tell the compiler "trust me." The payoff is that a Roc type is a guarantee, not a suggestion: if a value claims to be I64, it is one.

Here TypeScript developers have a head start on everyone else: Roc records are structurally typed, exactly like TypeScript objects — any record with the right fields satisfies the type, and a type alias (single colon) just gives the shape a name. Coming from Java or Rust this is a big adjustment; coming from TypeScript it is home turf.

TypeScript's const only freezes the binding — the array behind it mutates freely, and true immutability needs readonly, as const, or Object.freeze discipline. In Roc, a plain name = value binding is deeply immutable: there is no push, no property assignment, no way to mutate a shared value, period. Local mutation exists but is opt-in and visually loud (next row).

Roc's var declares a reassignable local, and the $ sigil must appear on every use, so mutation is impossible to miss when reading code — imagine if every use of a let variable had to be spelled differently from a const one. A var is local-only: it cannot be captured by a closure or escape the function, so mutation never becomes shared state.

Destructuring works the same way in both languages — note that Roc uses parentheses for tuples where TypeScript reuses array syntax. One Roc twist: the pattern must be exhaustive. You can destructure a tuple or a record directly, but you cannot write Ok(item) = list.first() as an assignment, because the Err case would be unhandled — use match for that.

TypeScript inherits JavaScript's single number type — a 64-bit float where integers are only safe up to 2⁵³ − 1 — plus bigint. Roc offers the full menu: I8/U8 through I128/U128, floats F32/F64, and Dec. That I128 literal holds a value number could never represent exactly. Underscore digit separators work in both languages.

Roc's flagship number type Dec is a 128-bit fixed-point decimal — and it is the default for unconstrained fractional literals, so 0.1 + 0.2 is exactly 0.3 out of the box. IEEE 754 floats (F32/F64) are still available when you want hardware speed, and they reproduce the familiar 0.30000000000000004. JavaScript's long-promised decimal proposal has been stuck in committee for years; Roc just made it the default.

In TypeScript, 17 / 5 is 3.4 and integer division requires Math.trunc. Roc spells integer division // (like Python) because plain / is reserved for exact division on Dec and floats. The remainder operator % matches. Dividing an integer by zero with // is an error in Roc — not Infinity, and not NaN.

TypeScript numbers are all one type, so mixed arithmetic just works — and string templates call toString() implicitly. Roc never converts numbers implicitly: dividing an I64 by a float requires an explicit .to_f64(), and interpolation requires an explicit .to_str(). Noisier, but no "5" + 3 class of surprise can exist.

JavaScript numbers drift silently past MAX_SAFE_INTEGER — big + 1 === big + 2 is genuinely true. Roc integers never lose precision: overflow is a hard error, and because Roc evaluates compile-time-known expressions during compilation, the commented line is rejected before the program ever runs.

Roc borrowed JavaScript's ${...} interpolation syntax — but it works inside ordinary double-quoted strings, with no backtick needed. The catch: interpolation only accepts Str values. There is no implicit toString(), so numbers need an explicit .to_str() call.

Roc has no + for strings — concatenation is the concat method, callable in method style or as Str.concat. Losing string + also means losing its dark side: nothing in Roc can silently coerce a number into a string mid-expression.

The everyday methods map almost one-to-one, just in snake_case: trim, repeat, starts_with, ends_with, and contains (TypeScript's includes). Str.inspect is the debug formatter — the closest thing to JSON.stringify for quick output — used here because Bool has no .to_str() in the current build.

The shape is identical: split_on returns a List(Str), just as split returns an array. Joining goes through Str.join_with(list, separator) — note it lives on Str rather than being a method on the list, the reverse of JavaScript's array.join.

The escape syntax nearly matches — JavaScript's \u{1F680} versus Roc's \u(1F680) — but the underlying encoding differs: JavaScript strings are UTF-16 (which is why "💎".length is 2), while Roc strings are UTF-8. Roc has no ambiguous .length at all: the method is named count_utf8_bytes() so nobody mistakes bytes for characters, and prints 6 here because é is two bytes.

Roc's List is the one sequential collection — contiguous in memory, not a linked list, despite the functional-language name. The literal syntax is identical to an array literal. Str.inspect plays the role of console.log's object formatting for quick debugging output.

The chained transformation style transfers directly — filter is named keep_if (with siblings drop_if and count_if), and closures use pipes instead of arrows. Unlike JavaScript, where each step allocates a fresh array, Roc's compiler mutates in place whenever the intermediate list is unshared, so the functional style has no hidden allocation tax.

Roc's fold is reduce with the arguments flipped: the initial accumulator comes first, then the closure. Roc also ships the sum() shortcut JavaScript never got, plus fold_rev, fold_with_index, and fold_until (which can stop early by returning Break(value)).

TypeScript's numbers[9] types as number but is undefined at runtime — the canonical unsoundness (noUncheckedIndexedAccess exists precisely to patch it). Roc has no subscript operator at all: .get() returns a Try, so the out-of-bounds case is a value you must handle. Roc's ?? works on Try the way TypeScript's works on undefined.

JavaScript's default sort() compares stringified elements — [10, 9, 1].sort() gives [1, 10, 9] — and mutates in place, which is why the spread copies are needed. Roc's sort_with takes a comparator returning LT/EQ/GT tags and returns a new list; when the original is unshared, the "copy" happens in place anyway, so immutability costs nothing.

take_first and drop_first (plus take_last, drop_last, and sublist) cover what slice does, with names that say which end they work from. Conceptually they produce new lists, but reference counting lets them share structure, so slicing a large list is cheap.

The predicate helpers map cleanly: some → any, every → all, find → find_first, and findIndex → find_first_index. The one structural difference: find_first returns a Try instead of T | undefined, so "not found" is a tag you match on rather than a sentinel value that might collide with real data.

The literal syntax and dot access are identical. What is missing is the baggage: a Roc record has no prototype chain, no this, no methods-attached-to-data, and no reference identity — it is pure data, compared by value. Two records with the same fields are the same type, exactly as in TypeScript's structural system.

The spread-update idiom translates almost keystroke-for-keystroke — Roc's spread is two dots instead of three. One semantic upgrade: TypeScript's spread is a shallow copy of a mutable object, while Roc's produces a genuinely immutable value, and the compiler reuses the original's memory when nothing else references it.

TypeScript tuples are arrays wearing a type annotation — at runtime you can still push onto one. Roc tuples are a distinct value kind with parenthesis syntax, accessed as .0/.1 with a literal index the compiler verifies. Destructuring works the same way in both.

A Roc type alias (single colon) is TypeScript's type alias: transparent and structural, so any record with those fields satisfies it. Roc has no separate interface construct and no declaration merging — one way to name a shape. When you want a nominal type that will not unify with look-alikes (what TypeScript fakes with branded types), Roc has :=, covered under Tag Unions.

This is the feature TypeScript developers take to instantly. A tag union is a discriminated union where the language supplies the discriminant: no kind: field to invent, no string literals to keep in sync, and the payload is positional instead of a bag of named fields. match destructures and narrows in one step, with exhaustiveness checked by the compiler rather than by a never-typed default-case trick.

Structural tags spring into existence at the point of use: the if gives period the inferred type [Morning, Afternoon] with no declaration anywhere, and the match is still checked for exhaustiveness. It is the ergonomics of TypeScript's string-literal unions with actual named constructors that can also carry payloads.

The .. in [Go, Stop, ..] makes the union open: the function accepts those tags plus any others, provided a catch-all branch handles the rest. TypeScript approximates this with the notorious string & {} hack to keep autocomplete while accepting arbitrary strings; Roc expresses the idea directly in the type — and open tags can carry payloads, which the string hack never could.

Both languages handle recursive types, but compare the construction sites: the TypeScript tree is a thicket of kind: fields and braces, while the Roc tree reads like the data it represents. Roc's recursive tag unions are heap-allocated and reference-counted automatically behind the scenes.

Everything switch gets wrong, match fixes: it is an expression (so the result feeds a binding directly, no mutable let dance), there is no fallthrough and no break, and missing a case is a compile error rather than a silent skip. TC39's long-discussed pattern-matching proposal is essentially this construct.

A guard — pattern if condition => — attaches an arbitrary boolean test to a branch, replacing the early-return ladder TypeScript reaches for. A guarded branch does not count toward exhaustiveness, so the final catch-all is still required.

Where switch expresses "any of these" through deliberate case fallthrough — the same mechanism that causes bugs when a break is forgotten — match uses an explicit | between alternatives in a single branch.

TypeScript has rest destructuring but cannot branch on array shape — you check .length by hand and hope the destructuring matches the branch you are in. Roc's list patterns unify the test and the destructuring: [first, .. as rest] both matches "one or more elements" and binds the pieces, with the compiler verifying all shapes are covered.

Roc has no null, no undefined — and no built-in Option either. Where TypeScript writes string | undefined, Roc returns either a Try (when absence is an error) or an ad-hoc structural union like [Found(Str), Missing], which needs no declaration and names the absent case something meaningful. There is no strictness flag to enable: unhandled absence is always a type error.

Roc's ?? will feel like an old friend: it supplies a default, just like nullish coalescing. The difference is what it defaults over — TypeScript's ?? triggers on the values null and undefined, while Roc's unwraps a Try, substituting the default when it is Err. No value can ever be null in Roc, so the operator works on the result type instead.

Roc has no ?. because nothing needs it: a record type guarantees every field exists, so dot access cannot fail. Optionality is modeled in the data instead — a field whose value is a tag union like [Set(Str), Unset] — which forces the "what if it is missing?" decision to the one place that constructs the value, rather than sprinkling ?. at every use site.

Roc has no exceptions, no throw, and no try/catch. A fallible function returns Try(ok, err) — Ok or Err, handled by pattern matching. Note what the signature buys you: TypeScript's parseScore(text: string): number says nothing about the throw, and a caught problem is unknown. Roc's error type [BadScore(Str)] is right there in the signature, precisely typed, and the compiler will not let you ignore it.

The postfix ? unwraps an Ok or early-returns the Err to the caller — exception-style propagation, but visible at every call site and tracked in the type. Here main! simply passes show_first!'s Try along as its own result. It is the ergonomic middle ground TypeScript lacks between "throw and lose the type" and "thread result objects by hand."

Because Roc error tags are structural and unions are open, errors from different functions merge automatically: a function calling two fallible helpers with ? infers the union of both error sets, with no hand-maintained ConfigError type to update when a new failure mode appears. It is the composability TypeScript's discriminated-union error style always wanted.

Roc's crash is the one non-Try escape: an unrecoverable abort for states that should be impossible, with the platform deciding what happens next. Nothing can catch it — there is no catch — so it is reserved for genuine bugs, never expected failures. This row is display-only because the WASM host powering this page stops its instance on a crash (and the TypeScript side exits nonzero by throwing).

Roc has exactly one function syntax — |args| body, pipes instead of the arrow — and a top-level function is just a named value bound to a lambda, the way const alsoAdd = ... is. There is no function keyword, no hoisting, no this, and no arrow-vs-function distinction to remember, because there is no this to bind in the first place.

Closures capture their environment in both languages, and the code reads nearly the same. The semantic difference is subtle but important: a TypeScript closure captures mutable bindings — the classic loop-variable bug — while a Roc closure captures immutable values, so what a closure sees can never change behind its back.

Lowercase names in a Roc type annotation are type variables — a -> a is <Value>(value: Value) => Value with no declaration site needed. Unlike TypeScript generics, which are erased and enforced only at compile time, Roc monomorphizes: each concrete use compiles to its own specialized machine code.

Roc's where clause constrains a type variable by the methods it must provide — where [a.to_str : a -> Str] reads exactly like TypeScript's extends { toString(): string }: structural, no interface to implement. The difference is dispatch: TypeScript resolves the call through the object at runtime; Roc resolves it statically and generates specialized code.

TypeScript needs the ternary operator because its if is a statement; chain two and readability dies. Roc's if is an expression, so else if chains produce a value directly — the ternary's job with if's syntax. Both branches must have the same type, and the condition must be an actual Bool: no truthiness, no if (items.length) idiom.

Yes, the pure functional language has real while loops with break — mutation through var is local to the function, so it cannot leak or be shared, and the compiler is free to allow honest imperative iteration. You do not have to rewrite every loop as a fold to write Roc.

The langref specifies for word in words { } loops, but the pinned nightly build this page runs on rejects them (the iterator protocol is still being wired up) — so the idiomatic working form today is .for_each!(...), whose ! marks that its closure performs effects, like forEach with an honest signature. Expect for to light up in a future nightly.

Roc has a genuine return statement for early exits — rare among functional languages — but the happy path needs no keyword: the final expression of the function body is its value. The familiar "guard clause returns early, main logic flows to the bottom" style translates unchanged.

TypeScript developers already live with function coloring: async functions are marked, awaited, and infectious up the call stack. Roc applies the same discipline to all side effects — an effectful function carries a ! suffix and a => arrow in its type, and a pure function (->) cannot call one. Unlike async, the compiler enforces the color: no function can secretly log, fetch, or write.

A TypeScript module's top level is a script: it executes at import time, side effects and all — the source of many an initialization-order bug. A Roc module's top level is pure by construction, so the compiler evaluates every top-level value at compile time: squared is baked into the binary as 100, and a top-level expression that would crash becomes a compile error instead.

An inline expect checks a condition mid-program, like node:assert; if it fails, the program halts with a nonzero exit code. The same keyword doubles as Roc's unit-testing construct: top-level expect blocks are collected and run by roc test — the built-in answer to reaching for Vitest or Jest.

Roc has no garbage collector: the compiler inserts reference-count increments and decrements at compile time (the Perceus technique), so memory is freed the instant the last reference disappears — deterministically, with no collection pauses and no GC tuning. Because Roc statically rules out reference cycles, the classic weakness of reference counting cannot be expressed.

The aliasing bug on the left — mutating through one name and surprising every other holder of the reference — is impossible in Roc, because values cannot be mutated through references at all. Updates like append and record spread produce new values; whether memory is actually copied is the compiler's problem (it reuses the allocation when the value is unshared), not a correctness question.

In JavaScript, immutable-style updates (map, toSpliced, spread) always pay for a fresh allocation — the style has a runtime cost. Roc's set looks like it copies the list, but the compiler mutates in place whenever the reference count is 1, producing the machine code of the mutable version with the semantics of the immutable one. (set returns a Try because the index might be out of bounds, so ?? supplies the fallback.)

The number-one surprise: Roc's unconstrained numeric literals default to Dec, so the first line prints [1.0, 2.0, 3.0]. JavaScript's single number type at least prints integers as integers; Roc's decimal default changes the output. The habit to build: annotate any binding whose value you intend to display as an integer.

Template literals quietly call toString() on anything — objects included, hence [object Object]. Roc's interpolation accepts only Str, so every number needs its .to_str(). It feels noisy for a day and then becomes automatic — and [object Object] can never happen.

Because tags are structural, a bare False is just the tag False in an anonymous union — not necessarily a Bool — so operators like ! may fail to resolve without context. Annotate ready : Bool (or write Bool.False) and everything works. The same structural-tags superpower that removes discriminant boilerplate creates this one sharp edge.

Roc has exactly one equality operator, and it does what === never quite could: == compares values, structurally, at every depth — two lists with equal elements are equal. There is no coercing double-equals to ban in the style guide, and no "reference equality for objects" asterisk. Comparing values of different types is a compile error, not false.

Roc is pre-1.0 and this page pins a specific nightly compiler, so some familiar operations are missing or renamed: there is no Str.replace yet, string length is count_utf8_bytes(), list reversal is rev(), the pipe operator |> was removed in favor of method chains, and triple-quoted multiline strings are not implemented. Expect this table to improve as Roc approaches its first stable release.