OCaml.CodeCompared.To/Roc

The ! suffix marks something effectful — main! performs effects and echo! is one, and the naming is enforced rather than conventional. _args is the command-line arguments, which this program ignores. The Ok({}) is the program's exit status as a value: Ok of the empty record means success, and returning an Err is how a program fails. The whole shape is decided by the platform the application is built against, which is the subject of the next row and the most unusual idea in the language.

A Roc platform owns the entry point, the effects and the memory allocator; an application is pure code plugged into one. That inverts the usual arrangement, where a program owns main and calls libraries for I/O. The consequences are real: an application cannot perform an effect the platform did not provide, so the set of things it can do is bounded by construction; platform authors write the unsafe, host-specific half in Rust or Zig once; and the same application can target a command-line tool, a server or a microcontroller by changing one line. It is the same problem OCaml 5 addresses with effect handlers, answered at the build-system level instead of the language level.

Roc treats compile speed as a feature to design for, which is part of why the type system is structural — there is no separate declaration to resolve — and why it monomorphizes rather than boxing. OCaml is itself fast by the standards of optimizing compilers, and a large dune project still takes real time. Whether Roc holds this at scale is unproven; the language has no large codebases yet. It is worth knowing as intent, not as measurement.

OCaml has two kinds of sum type — declared variants, which almost all code uses, and polymorphic variants, which are structural, need no declaration, and are reached for occasionally. Roc has both, and makes the structural kind the ordinary one: a nominal union, declared with := as in Shape := [Circle(I64), Square(I64)], is there for when you want a closed, named type, and most code never writes one. A tag is written where it is used, two unrelated functions can accept overlapping sets, and the inferred type is the exact set of tags that can appear. The annotation above is checked documentation, and here it also does work: delete it and the example stops compiling, because nothing else says what type radius is, and the compiler reports to_str being called on an unresolved type variable. That is a genuinely different design bet from every other language on this anchor, and for an OCaml programmer it is the most familiar-looking unfamiliar thing here.

area handles two tags and name handles three, with nothing declaring either set and nothing relating them. A value built as Circle(2) can be passed to both. In OCaml that is exactly what polymorphic variants do, and it is why they are useful for open, extensible sums — the difference is that in Roc this is the everyday sum type, and the closed alternative — a nominal union declared with := — is the one reached for occasionally. Exhaustiveness is still checked: each match must cover the tags its own inferred type admits, so deleting a branch is still an error. Saying "these three cases and no others, everywhere" takes a nominal union, which is how Bool and Try themselves are declared.

This is where the structural approach pays off in ordinary code: the union exists only as the annotation on describe, so a state machine can be sketched and changed without maintaining a separate type declaration alongside it. Roc also uses tags where other languages use dedicated types — Bool.True and Bool.False are tags, and so are Ok and Err. Note the string interpolation, "${expression}", which OCaml has never grown and which reads better than sprintf for short cases.

In OCaml, bool, option and result are declared types in the standard library, and polymorphic variants are a separate mechanism used for other things. In Roc they are all tags: Bool is the nominal union [False, True] and Try the nominal union [Ok(ok), Err(err)], declared in the standard library with the same := any program can use, and matched exactly like tags you write. That uniformity is the argument for the design — there is less language to learn, because the primitives are made of the same parts as your own code.

An OCaml record is nominal: type point and type coordinate with identical fields are different types, and a value belongs to exactly one of them. A Roc record's type is simply its set of fields, so any record with exactly those fields fits anywhere one is expected — a record with an extra field is a different type and is rejected. The update syntax is the same idea under different punctuation — { ..origin, x: 5 } for { origin with x = 5 }. Keeping two same-shaped things apart takes a nominal type declared with :=, and two such types are not interchangeable even when their fields match: the default is structural and nominal is opt-in, the reverse of OCaml.

Both languages build a variant of a default by copying and overriding. OCaml also has optional labeled arguments with defaults (?(retries = 3)); in Roc, a defaults record like this one is how the same effect is written. What Roc adds is Str.inspect, which renders any value structurally with no declaration and no deriver — the equivalent of Haskell's deriving Show or Rust's #[derive(Debug)], available by default because the type system is structural and the compiler always knows the shape. OCaml needs a ppx deriver for the same thing.

Both languages destructure a record directly in a function parameter, and both allow field punning so { name, age } binds those names. The difference is the annotation: OCaml names a declared type, Roc writes the field set inline because the type is that set. That makes small functions self-describing without a type declaration nearby, and it means two functions taking "a thing with a name and an age" need no shared definition.

OCaml's let creates a new binding that hides the old one, so refining a value under one name is idiomatic. Roc discourages it: a duplicate definition, shadowing included, draws a warning, and the roc command exits with status 2 so the rebinding cannot pass a continuous-integration check. The language wants a name to mean one thing in a scope, much as Erlang does. The practical effect is a chain of slightly different names, and the practical benefit is that reading unfamiliar code you never have to ask which binding of a name you are looking at.

This is one of the places Roc sits closer to OCaml than any of the mainstream targets on this anchor — Rust, Go and TypeScript all stop inference at the function boundary, and Roc does not. One practical note: a number literal whose type nothing else determines becomes a Dec, and prints with a decimal point — hence the .I64 suffix above.

OCaml has one integer type at 63 bits and one float, with separate operator families (+ versus +.) because it has no overloading. Roc has sized integers from I8 to I128, unsigned versions, F32/F64, and Dec — a fixed-point decimal with exact arithmetic, so 0.1 + 0.2 is exactly 0.3, which no other target on this anchor offers by default. One operator set covers them all, resolved by type. Integer overflow is a runtime error rather than a wrap, and the compiler rejects a literal that cannot fit its type.

0.1 + 0.2 in binary floating point is 0.30000000000000004, which is true in OCaml, Rust, Go, Python, JavaScript and every other target on this anchor. Roc ships Dec, a 128-bit fixed-point decimal, and makes it the type a bare decimal literal defaults to — so the common case is exact and you opt into F64 when you want speed or transcendental functions. OCaml needs a library (decimal, or zarith rationals) for the same guarantee.

OCaml has no interpolation syntax and reaches for sprintf, whose format string is typed and checked. Roc's ${…} requires its expression to already be a Str, which is why year.to_str() is spelled out rather than happening silently — the same discipline ReScript enforces, and stricter than JavaScript or Python, where anything is stringified. A Roc Str is guaranteed to be valid UTF-8, where an OCaml string is bytes with no declared encoding.

OCaml's char is one byte, so indexing a string gives a byte and an accented letter comes apart — the mojibake seen on several pages of this anchor. Roc refuses the question: there is no Char, no indexing by position, and a Str is taken apart with operations such as split_on and join_with, or turned into its UTF-8 bytes with to_utf8; grapheme-aware work is left to a Unicode library, which is also what asking a string for .len() tells you. That is stricter than Rust, which has char as a Unicode scalar, and much stricter than OCaml. The cost is that character-by-character algorithms need rethinking; the benefit is that the wrong answer is not available.

OCaml's list is a singly linked list, so :: is constant time and List.length is a traversal. Roc's List is a contiguous array — len is free, indexing is free, and prepending is not. It is still immutable in the language's semantics: List.prepend produces a new list and leaves the original intact, which is why both lengths print. What makes that affordable rather than ruinous is the memory model in a later section — the compiler mutates in place when it can prove nobody else holds a reference.

OCaml's |> is pipe-last and works because the List functions are curried with the data last. Roc's is pipe-first — x |> f(y) is f(x, y) — which is the same choice ReScript made with -> and for the same reason: the standard library takes its data first. keep_if is filter. Note also the method-call style available alongside it, numbers.len(), which is static dispatch resolved at compile time rather than anything dynamic.

OCaml's numbers.(9) raises Invalid_argument, and the safe form is a different function you have to know about — the same inversion Belt corrects in ReScript. Roc has no raising version at all: get returns a Try, so the out-of-bounds case is in the type and cannot be skipped. ?? supplies a default in one character for the common case. That is a small design decision with a large effect, and it is the same one Rust makes with Option for slice::get.

OCaml's Map.Make (String) builds a module specialized to string keys. Roc's Dict is an ordinary generic type, so there is nothing to instantiate. Lookup returns Try rather than an option-shaped type of its own, which is the same uniformity the tags section described: one mechanism for "this might not be there", used everywhere.

Reversing produces a new list in both, and the original is still usable — where Go's slices.Reverse and JavaScript's Array.reverse modify in place and the original ordering is gone. What makes the immutable version affordable in Roc is the memory model two sections down: if the refcount shows nobody else holds the input, the compiler reuses its allocation rather than copying. So the semantics are immutable and the execution frequently is not.

The semantics are OCaml's: every branch must agree on a type and the whole thing produces a value. Two syntactic notes. Braces are required and there is no then. And match arms are written Pattern => value with no leading | and no separator, which reads cleanly but is one more thing to retrain. Guards exist in match too.

OCaml's List.iter takes a function returning unit: a loop whose purpose is its effects. Roc's for is a statement that works in pure functions too — updating a var as it goes, as in a running total — and List.map and List.fold are there for when the result is the point. What keeps a pure function pure is not the absence of loops but the ! rule: a loop in a function whose name has no ! still cannot print.

A function's value is its final expression in both, so there is nothing to return from and no early exit to write. That is unremarkable to an OCaml programmer and is worth stating because every other target on this anchor except Haskell has a return — and because it is the reason both languages push you toward expressions that produce a value rather than statements that assign one. Roc adds crash for the genuinely unreachable case, which terminates rather than returning.

OCaml's assert is for invariants and testing means choosing a framework. Roc's expect is syntax: it can appear at the top level or inside a function, it is skipped in optimized builds, and roc test runs every top-level one and reports each failure by showing the expect itself. There is no framework to choose and nothing to install before the first test.

OCaml writes int -> int -> int, arrows all the way down, because a two-argument function is a function returning a function — so add 10 is ordinary application. Roc writes I64, I64 -> I64: one function taking two arguments, and calling it with one is an error. That was a deliberate decision for the same reason ReScript made it — uncurried calls compile to direct calls with no closure allocation, which matters for a language aiming at systems work. Partial application means a closure, written out.

Capture works the same way and the values are immutable in both, so there is no question about whether a closure sees a later change — there are no later changes. The syntax is Rust's pipes rather than OCaml's fun … ->. Str.inspect renders the result structurally, which is worth noticing again: it works on any value, including a record or a tag union, with no declaration and no deriver, because the compiler always knows the shape of a structural type.

Roc resolves numbers.len() at compile time from the type of numbers, so it is exactly List.len(numbers) with no dynamic dispatch, no vtable and no object model. The value is readability: a chain reads left to right in call order without needing a pipeline operator, which is the ergonomic win object-oriented languages get and functional ones usually give up. OCaml has |>, which gets there for pipelines and not for a single call.

A Roc module cannot be parameterized, passed as a value or constrained by a signature. What stands in for a functor is a where clause, which constrains a type variable by naming the methods it must have — a.is_gt above, which is what > calls — close to a Haskell class constraint or a Rust trait bound, and resolved statically. That covers "one type with a standard capability" and does not cover bundling a type with several operations and instantiating it more than once. This is the same loss F#, Haskell, Go and Rust all impose; ReScript is the only target on this anchor that kept functors.

Haskell needs deriving (Show, Eq), Rust needs #[derive(Debug, PartialEq)], and OCaml needs a ppx deriver or a hand-written function. Roc needs nothing: because a type is its structure, the compiler can always print and compare it, so Str.inspect and == work on any structural type with no declaration. OCaml gets close with its polymorphic =, which compares anything by walking runtime representations — at the cost of raising on functions and looping on cyclic values, both of which Roc rejects at compile time.

OCaml has no constraint mechanism on a plain function: a type variable is either fully general or the operations are passed in explicitly, which is what a functor formalizes. Roc constrains a type variable with a where clause naming the methods the type must have, and the compiler checks each call against it — == is the method is_eq, so the clause above is what lets count_matching compare. Structural types come with equality and printing, so both calls work without anyone declaring anything. That is the payoff of structural typing showing up again.

OCaml's double has type int -> int while printing, and nothing warns a caller. Haskell puts the effect in the type as IO Int, which is precise and colors every caller. Roc splits the difference: an effectful function must be named with a trailing ! and its arrow is => rather than ->, so effects are visible at every call site and the compiler rejects a pure function that tries to perform one. It still colors callers — double! can only be called from something effectful — but the marker is in the name, where you read it, rather than in a wrapper type you have to unwrap.

OCaml 5's handler is chosen at the call site, in ordinary code: the same task can be run under a handler that logs, one that collects, one that mocks, and the choice is a value. That is why effect handlers subsume schedulers, generators and async I/O. Roc's platform is chosen at build time: the whole application is compiled against one set of effects, with the platform author supplying the implementation in Rust or Zig. Roc's is coarser and buys something OCaml's does not — the platform also owns memory allocation and the entry point, so an application can target a microcontroller with no runtime at all.

Neither column performs an effect, and the Roc version says so structurally — no ! in the name means the compiler will reject any attempt to print, read a file or reach the outside world from inside it. That is the same architecture Haskell's IO enforces and the same one careful OCaml achieves by discipline, with the marker in the name rather than in a wrapper type. The majority of any Roc program looks like this; the effectful shell is thin, which is the point of pushing effects to the platform.

Roc's Try(ok, err) is OCaml's result under a different name. The interesting half is the error type: [NotANumber, NotPositive] is a structural tag union written inline, so the exact set of failures a function can produce is part of its signature without declaring an exception type or an error enum. The OCaml column uses polymorphic variants to get the same shape, which is possible and unusual; a typical OCaml codebase would declare a variant or use strings.

OCaml needs a binding operator to get here — let*, defined by hand once and then usable — and the anchor column defines one. Roc's ? is the same flattening built in, and the error type it propagates has to fit the function's own, which is why total declares [NotANumber]. When you annotate an error type that a ? inside main! must satisfy, leave the union open with ..; a closed one will not unify with what the platform declares.

OCaml uses one mechanism for both: failwith and a declared exception are the same kind of thing, and whether a raise is expected or catastrophic is a matter of convention. Roc splits them — a failure a caller should handle is Err in a Try, and a state that cannot occur is crash, which is not catchable at all. That is the same distinction Rust draws between Result and panic!, and Go between error and panic, and it is worth adopting in OCaml even though the language does not enforce it.

OCaml uses a generational tracing collector: allocation is cheap, deallocation is invisible, and collections pause the program — briefly and incrementally, but they exist. C makes you write every free. Roc reference counts, with the counts inserted by the compiler, so memory is released deterministically at the moment the last reference goes away and there is no pause. Because the language is pure there are no reference cycles to leak, which is the usual fatal flaw of refcounting and the reason Rust needs Weak. The cost is the counting itself, which the next row is about.

In a pure language, updating a structure means building a new one — which is why functional code is often assumed to be slower. Roc's answer is that the reference count already knows whether anyone else can observe the old version: if the count is one, mutating in place is unobservable, so the compiler does it and copies nothing. Write a fold that updates a list a million times and, if the intermediate values are not retained, it runs as an in-place loop. That is the same insight Rust encodes as ownership, obtained at runtime from the refcount instead of at compile time from the type system — less predictable, and requiring nothing from the programmer.

Reference counting's classic failure is a cycle: two values pointing at each other keep each other's count above zero forever, which is why Rust has Weak and Swift has unowned. Roc cannot build one — creating a cycle requires mutating something to point back at a value that already exists, and there is no mutation. So refcounting is complete rather than a best effort, with no tracing collector needed and no cycle detector. OCaml's tracing collector handles cycles without being asked, which is what lets it offer mutable fields in the first place.

Roc has no 1.0, no stability promise, and a history of significant syntax changes — when became match, the backpassing syntax was introduced and then removed, and the effects design has been revised more than once. This site pins a nightly, and moves to a newer one only when every example still runs and prints what it printed before, so the page teaches the build that is installed. None of that is a reason to ignore the language — the ideas are worth knowing now and the compiler is genuinely pleasant — but it is a reason not to start a production system in it this year.

A Roc application cannot run without a platform, and the platform supplies every effect it can perform — so the question is not only "is there a library for this" but "is there a platform that can do this at all". The set of mature platforms is small, and writing one is a much larger undertaking than writing a library, since it means implementing the host in Rust or Zig against a C ABI and taking responsibility for memory allocation. OCaml's opam ecosystem is modest next to npm or crates.io and is enormous next to this.

Roc has no async, no threads, no channels and no effect handlers in the language. Concurrency belongs to the platform, so an application that wants it needs a platform that provides it — and the platform author implements it in Rust or Zig. In principle that is elegant: no colored functions, and the concurrency model is chosen with the deployment target. In practice it means the answer to "how do I run two things at once" is "depends on your platform", and for a language this young that is a thin answer. OCaml 5's effect handlers put the same flexibility in the language, where it can be used without writing a host.

OCaml's ppx rewrites the parse tree at build time and is how deriving, inline tests and embedded DSLs are written — genuinely powerful and genuinely hard to write. Roc has no macro system of any kind, and the most common use of one is unnecessary: printing and equality come with every structural type. What is left with no answer is the DSL case and anything wanting to generate code from a schema, which in Roc means a build step outside the language.

The message quoted in the comment is verbatim from the compiler this page runs on. It names the problem, points at the expression, explains why the situation is impossible, and suggests two concrete fixes. Roc's compiler treats that as a feature to be designed rather than a byproduct of type checking, and the difference from a unification failure reported wherever unification happened to fail is large. This is the thing most worth stealing from Roc regardless of whether the language succeeds, and Elm made the same argument first.

Two things transfer immediately. Use polymorphic variants where the set of cases is genuinely open — error types are the clearest case, since a function's exact failure set belongs in its signature and a closed variant forces every caller to know about failures that cannot reach them. And make the error type as precise as the success type: Error of string throws away everything the caller could have matched on. Roc makes both the default; OCaml offers both and its culture leans nominal, which is worth revisiting rather than assuming.

Because the platform supplies the allocator and the entry point, a Roc application carries no runtime of its own and can be built for an environment that has none. The Roc column you are reading was compiled to WebAssembly and is running in the browser with no server. OCaml compiles to WebAssembly too — through js_of_ocaml, Melange or the newer wasm backend — and carries its runtime and collector along, which is the right trade for most programs and the wrong one for a microcontroller. This is the clearest thing Roc's architecture buys.

For production work today, no: no 1.0, a syntax that has changed repeatedly, few platforms, and a small ecosystem. For an OCaml programmer's attention, yes — because Roc is the only language making structural tags and structural records the default, and it is worth seeing what a language looks like when your most exotic feature is its ordinary one. The platform split, the refcount-driven in-place mutation, and the diagnostics-first compiler are each worth understanding independently of whether Roc succeeds. That is a different question from whether to build something in it.