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 only the structural kind. 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 optional documentation; deleting it changes nothing. 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 Roc has no closed alternative to fall back on, so this is the sum type. Exhaustiveness is still checked: each match must cover the tags its own inferred type admits, so deleting a branch is still an error. What you give up is the ability to say "these three cases and no others, forever, everywhere".

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 there is one mechanism: Bool.True, Ok and Err are all tags, and the same matching and inference apply to them as to anything 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 an x and a y fits anywhere one is expected. The update syntax is the same idea under different punctuation — { ..origin, x: 5 } for { origin with x = 5 }. What is lost is the ability to keep two same-shaped things apart, which is what OCaml's nominal typing buys and what the branded-type trick tries to recover in TypeScript.

Both languages build a variant of a default by copying and overriding, and neither has named arguments with defaults on a plain function, so this is the idiom in both. 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 rejects it — a duplicate definition is a compile error, the same rule Erlang enforces, and for the same reason: the language wants a name to mean one thing in a scope. The practical effect is the same as Erlang's, 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. Two practical notes from the pinned build. A numeric literal whose type nothing else determines stays an unresolved variable, and calling a method on it fails with "unresolved type variables have no methods" — hence the .I64 suffix above. And the compiler rejects a match whose value it can fold at compile time as an "unconditional condition", so an example that matches must get its value from somewhere less obvious.

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 UTF-8, so its operations are Unicode-aware, 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 manipulated with operations that work on whole grapheme boundaries or on explicit code points. 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 whose key requirement is an ability the compiler checks, 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. Note that this build's List is sparse — there is no sort of any spelling in it.

The semantics are OCaml's: every branch must agree on a type and the whole thing produces a value. Two syntactic notes on the pinned build. 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; this row uses if chains because the compiler rejects a match on a value it can fold at compile time.

OCaml's List.iter takes a function returning unit, which is the same idea: a loop whose purpose is its effects. Roc's for is available where effects are, and a pure transformation uses List.map, List.fold or a comprehension-free pipeline. Because purity is tracked by the ! naming rather than by a monad, the split between "loop for effect" and "fold for value" is visible in the syntax without any type-level machinery.

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, is compiled out of release builds, and when one fails the compiler prints the value of every expression involved rather than just reporting that a boolean was false. That is the same diagnostics-first instinct as the error messages, applied to tests, and it is a small thing that changes how much a failing test tells you.

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 is a file with an export list, and it cannot be parameterized, passed as a value or constrained by a signature. What stands in for a functor is an ability, which is a constraint on a type variable saying it supports certain operations — the same idea as a Haskell type class or a Rust trait, 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 generate Inspect, Eq and Hash, and the abilities system makes them available on every type that has not opted out. 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 abilities it must implement, and the compiler supplies them — the example above is written at a concrete type because the where-clause spelling this build accepts differs from the one Roc's documentation shows, and the page reports what the compiler took rather than what the docs say. The built-in abilities — Eq, Hash, Inspect, Encode, Decode — are derived automatically for structural types, so most constraints are satisfied without anyone writing an instance. 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, and the vendored build uses that name rather than Result. 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 can define a let* binding operator and flatten the chain to one line per step, which the anchor column does. Roc's own documentation describes a ? operator for exactly this — parse(first)? propagating the error — and the build this page is written against does not accept it, so the target column nests instead. Whether that is because the operator is newer than this build or because it is spelled differently here, the page does not claim to know: what it shows is what the installed compiler accepts, which is the only thing it can verify.

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 rebuilds it from source when a newer one passes every example, so the page teaches whichever build is installed; the error-composition row above shows what that costs, since the documented ? operator is not one this build accepts. 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: Inspect, Eq, Hash, Encode and Decode are derived automatically for 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 writing this page. 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 because its type system has no closed alternative; 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.