OCaml.CodeCompared.To/ReScript

OCaml's let () = … both runs the expression and asserts it has type unit. A ReScript module's top-level expressions execute when the module loads, which is JavaScript's model rather than OCaml's. Console.log comes from the standard library; Js.log is the older spelling and both work in 12.3. Note there is no semicolon and no in — the layout rules are closer to JavaScript than to either.

ReScript compiles each .res file to one JavaScript file, and "in-source": true puts that output next to the source, so Main.res becomes Main.res.js in the same directory. That is deliberate: the generated JavaScript is meant to be read, checked into git if you like, and imported by ordinary JavaScript with no bundler special-casing. There is no module graph for the build system to work out the way dune does, because every file is compiled independently and the imports are ordinary JavaScript imports.

js_of_ocaml compiles OCaml bytecode, so its output carries a translated runtime and is not meant to be read. ReScript compiles source to per-module JavaScript with no runtime for the core language — a variant becomes a plain object or a number, a record becomes a plain object, and a function becomes a function. That is what makes the output importable from JavaScript without a shim, and it is also why the type system has to be as strict as it is: there is no runtime representation to check anything against later.

OCaml writes a function by juxtaposing its parameters after the name and applies it by juxtaposition too. ReScript uses an arrow and parenthesized, comma-separated parameters, and application uses parentheses. Nothing about the language changed here — type inference works identically and add still has the type you would expect — but the visual difference is large enough that OCaml code does not read as ReScript at a glance. That was the point of the fork: it was meant to look approachable to JavaScript programmers.

The keyword is switch … {} rather than match … with, the arrow is => rather than ->, and a constructor's payload is parenthesized (Circle(radius)) rather than juxtaposed. Exhaustiveness is checked exactly as in OCaml — delete the Point branch and the compiler names it. Note also that ReScript kept OCaml's separate float operators: *. is still float multiplication, because ReScript has no overloading either.

This is a pure syntax change: ReScript modules nest, take signatures, and can be passed to functors exactly as OCaml's do. The naming convention shifts to camelCase for values, following JavaScript, while modules and constructors stay capitalized as in OCaml. A .res file is itself a module named after the file, and .resi is the interface file — the same arrangement as .ml and .mli.

In OCaml, [1; 2; 3] is a linked list and [|1; 2; 3|] is an array. In ReScript, [1, 2, 3] is an array — because it compiles to a JavaScript array, which is what JavaScript code will hand you — and a list requires the explicit list{1, 2, 3}. The consequence is that Array is the default collection in ReScript where List is the default in OCaml, which reverses which operations are cheap. Elements are also separated by commas rather than semicolons. Expect to be caught by this more than once.

ReScript took JavaScript's template-literal syntax, so a backtick now opens an interpolated string — which meant the polymorphic-variant sigil had to become something else, and # was chosen. Everything else about them is the same: no declaration needed, a value can belong to several types, and the inferred type records which tags may appear. Note the other consequence for anyone writing about ReScript: backticks in ReScript source are string delimiters, so a code sample stored in a JavaScript template literal has to escape every one of them.

A JavaScript template literal calls String() on any expression, so a mistake produces odd text rather than an error. ReScript's ${} accepts only a string, which is why Js.Int.toString appears above — the conversion is forced and visible. That is a smaller guarantee than OCaml's typed format strings, which check the whole directive list, but it is a much larger one than JavaScript offers. ReScript also has Printf-style formatting available, and it is rarely used.

ReScript kept OCaml's inference engine, so parameters need no annotations, polymorphism is inferred and generalized automatically, and there is no any — every expression has a known type or the program does not compile. TypeScript, by contrast, infers only inside a function and treats an unannotated parameter as any. Note the list pattern syntax: list{} for the empty list and list{head, ..._} where OCaml writes head :: _.

ReScript's option is OCaml's, with the same Some and None. What matters is what is absent: a ReScript type never includes null or undefined, so the check cannot be skipped. That is the sharpest contrast with TypeScript, where strictNullChecks is a flag you can turn off and where any value crossing an untyped boundary may be null regardless. At the JavaScript boundary ReScript has Js.Nullable for values that genuinely might be, and converting is explicit.

This is a nice piece of engineering worth understanding. JavaScript has a single numeric type — a double — so ReScript's int is that double constrained to 32-bit integer behavior, with the compiler emitting the truncation and bitwise operations needed to keep it honest. The types stay separate, so 7 / 2 is integer division giving 3 and 7.0 /. 2.0 is 3.5, and mixing them is a compile error just as in OCaml. The practical difference from OCaml is the width: 32 bits rather than 63, so large integers need float or a bigint binding.

ReScript kept OCaml's behaviour exactly: each let creates a fresh binding that hides the previous one, nothing is mutated, and the type may change on the way. That is worth noting because it is the one place F# diverges — a module-level let there compiles to a static class member and redeclaring the name is error FS0037. ReScript compiles a module-level binding to a JavaScript let with a generated suffix, so shadowing costs nothing and reads exactly as it does in OCaml.

An OCaml string is a sequence of bytes with no declared encoding, so this word occupies six of them and uppercase_ascii — which says in its own name that it only handles ASCII — leaves the accented letter alone. A ReScript string is a JavaScript string: UTF-16 code units, so the length is five, and toUpperCase is fully Unicode-aware. This is a straightforward improvement, and it comes free from the target platform rather than from any design decision.

This is the array-by-default consequence in practice: Js.String2.split returns array<string> because that is what JavaScript's String.prototype.split returns, so downstream code uses Belt.Array rather than Belt.List. OCaml's split_on_char gives a list, and String.concat takes one. The Js.String2 module is a thin, type-safe binding over JavaScript's own string methods — which is a good illustration of how much of ReScript's standard library is bindings rather than implementations.

ReScript still has OCaml's immutable linked list under list{} and Belt.List, and it is perfectly usable. But every JavaScript value that arrives from outside is an array, every binding returns arrays, and arrays are what JavaScript code expects back — so idiomatic ReScript uses array and Belt.Array throughout. The habit to change is the OCaml one of building a result by consing and reversing at the end; here you build an array. Note that ReScript arrays are mutable, so Js.Array2.concat above is what keeps the original intact.

OCaml names the raising function plainly (List.hd, List.nth) and suffixes the safe one with _opt, so the dangerous version is the shorter one and the one you reach for by reflex. ReScript inverts that at the language level: indexing an array returns an option, so the safe form is the one you get for free and the raising variant has to be spelled out as Js.Array2.unsafe_get. The same convention runs through its libraries — Belt.Array.get returns an option and Belt.Array.getExn is the one that can crash. ReScript ships three standard libraries in 12.3: Js (thin bindings over JavaScript's own), Belt (data structures, option-returning) and the newer Core.

ReScript's -> is the pipe-first operator: it inserts the left-hand value as the first argument of the call on the right. OCaml's |> is pipe-last, inserting it as the final argument. That difference exists because Belt takes its data first (so it reads well with -> and works with uncurried application), while OCaml's modules take data last (so it reads well with |> and partial application). ReScript also has |> for compatibility, and mixing the two is a common source of confusion. filter is spelled keep in Belt.

OCaml's Map.Make (String) builds a functor-instantiated module with a persistent balanced tree. ReScript has that too — Belt.Map.String — and it also has Js.Dict, which is a plain JavaScript object with string keys. The second is what a JSON parse produces and what most bindings return, so it appears constantly at the boundary, while Belt.Map is what you use once the data is inside your own code. Note that Js.Dict.get returns an option, so a missing key is handled rather than yielding undefined.

The braces are mandatory and the then keyword is gone, but the semantics are OCaml's: every branch must agree on a type, and an if with no else must have type unit. That is a real difference from the JavaScript being emitted, where if is a statement — the compiler turns the ReScript expression into a JavaScript conditional expression or a temporary, whichever fits. ReScript also has the ternary condition ? a : b, which is the same thing more compactly.

ReScript kept OCaml's for … to … and its downward downto, and dropped the done keyword in favour of braces. It also kept the constraint that made the ref necessary: there are no mutable local bindings, so a counter lives in a cell read through .contents. That is a slightly odd inheritance given the target — JavaScript has let — and it is one of the places ReScript chose OCaml's semantics over the platform's. Iterating a collection uses Js.Array2.forEach rather than a loop.

OCaml eliminates tail calls as a language property, so accumulator-passing recursion is safe at any depth and is the idiomatic way to write a loop. ReScript compiles to JavaScript, and although tail calls are in the ECMAScript specification no major engine implements them — so a hundred-thousand-deep recursion raises RangeError: Maximum call stack size exceeded. The compiler does turn a directly self-recursive tail call into a loop in many cases, but it is an optimization rather than a promise. Where you would write a tail-recursive helper in OCaml, write a loop here.

ReScript writes if where OCaml writes when, matching Rust's choice. Everything else is identical, including the rule that a guard does not count toward exhaustiveness — so the wildcard is required in both columns. This is worth contrasting with the TypeScript page: TypeScript's switch compares values with === and supports none of this, so a discriminated union plus a manual never check is the closest it gets.

ReScript versions before 11 were curried like OCaml, and that produced JavaScript output full of arity-adapting helpers — a two-argument function called with one argument had to build a closure at runtime, which JavaScript engines could not optimize. Uncurrying by default makes add(3, 4) compile to a plain add(3, 4) call. Partial application did not disappear: add(10, ...) asks for it explicitly, and the compiler generates the closure only where you said so. The practical effect is that point-free OCaml pipelines need rewriting, and everything reads a little more explicitly.

The ~ for a label and the = for a default are OCaml's, and so is the trailing (), which exists for the same reason: a function with optional arguments cannot otherwise be known to be fully applied. F# has optional parameters only on class members, and Haskell has nothing at all, so this is a place where ReScript is the closest of the three to OCaml. Note that labels survive into the emitted JavaScript as positional arguments — they are a compile-time feature with no runtime cost.

This transfers with no adjustment beyond the syntax. Neither language needs the Fn/FnMut/FnOnce distinction Rust requires, because neither tracks ownership, and neither needs a type parameter with a bound the way Rust does. A ReScript closure compiles to a JavaScript closure, so it captures by reference in the JavaScript sense — which is invisible unless you are also mutating, and ReScript makes mutation explicit enough that it rarely surprises.

The correspondence is close to exact. Field definitions use : instead of : — the same, in fact — separated by commas rather than semicolons, and construction uses : where OCaml uses =. Functional update is JavaScript's spread syntax, {...origin, x: 5}, which does what { origin with x = 5 } does. Underneath, a ReScript record compiles to a plain JavaScript object with the same field names, which is what makes it directly usable from JavaScript and directly serializable to JSON.

ReScript kept mutable record fields exactly as OCaml has them — declared on the field, applying to every holder of the record. The assignment is written = rather than <-, following JavaScript, which is a small trap in the other direction since = in OCaml is comparison. ReScript also kept ref cells, with ref(0), := and .contents — and like OCaml they are just a record with one mutable field rather than a language feature.

OCaml lets a record be destructured directly in a function parameter and lets { name; age } mean { name = name; age = age } when the variables already have those names. ReScript does both, and the punning syntax coincides with JavaScript's object shorthand — which means the emitted code is the obvious thing. This is one of the places where an OCaml habit, a ReScript feature and a JavaScript idiom all line up, which does not happen often.

option and result are OCaml's, with the same constructors. The only change visible above is the guard keyword: ReScript writes if where OCaml writes when, following the same choice Rust made. Neither language has an equivalent of Rust's ? operator, so chaining several fallible steps means Belt.Result.flatMap or nesting — the same position OCaml is in without a let* binding operator, which ReScript does not have.

ReScript requires type rec to declare a recursive type, where OCaml's type is recursive by default. That is a deliberate reversal, matching let rec, so recursion is always marked. Everything else is the same: no Box as Rust needs, because both languages heap-allocate variant payloads. Note that in the emitted JavaScript, Leaf becomes the number 0 and Node(…) becomes a small object — constant constructors compile to integers, which is exactly what OCaml does at runtime too.

F# has no equivalent and Haskell has no equivalent, so this is a feature ReScript keeps that the two better-known ML descendants both abandoned. The semantics are OCaml's: no declaration, structural typing, and an inferred type listing exactly which tags may appear. The one thing to know is that a polymorphic variant compiles to a JavaScript string — #Red becomes "Red" — which is why they are the idiomatic way to bind a JavaScript API that takes a fixed set of string values.

A JavaScript API that accepts one of a fixed set of strings — a CSS alignment, an HTTP method, a chart type — is extremely common, and TypeScript models it with a union of string literal types. ReScript models it with a polymorphic variant, which compiles to precisely those strings with no runtime conversion, and gets exhaustiveness checking on top. That is a case where OCaml's most exotic feature turned out to be the practical one, and it is a good argument for why the fork kept it.

Module signatures, functors and functor application are all present, with sig … end becoming braces and the functor written as an arrow from a module to a module. F# has no functors at any level and Haskell has none either, so among the three descendants on this anchor ReScript is the only one that kept OCaml's module system essentially intact. The one thing to check before relying on it is tooling: functors are less used in the ReScript community than in OCaml's, so editor support and library conventions assume them less.

The mechanism is the same: module(English) packs and unpack retrieves, giving runtime dispatch over modules that share a signature. This is the OCaml feature with no counterpart in most languages, and ReScript kept it. The syntax is arguably cleaner — unpack(greeter) reads better than (val greeter : Greeter), and the signature is inferred rather than repeated.

The type t declared without a definition is opaque to callers exactly as in OCaml, so Counter.t cannot be treated as an int from outside. A real project puts this in Counter.resi, which plays the role of Counter.mli — same idea, same effect on dead-code elimination, and the same discipline of writing the interface first. TypeScript has no equivalent: its export list controls visibility but cannot hide a type's definition while exposing its name.

ReScript exceptions are declared and matched exactly as OCaml's, with pattern matching in the handler and the payload bound. They compile to JavaScript exceptions, so they interoperate with throw from JavaScript — and that is the caveat: a JavaScript exception arriving from a binding is not one of your declared exceptions, so a handler needs a catch-all or Js.Exn to inspect it. The community leans on result more heavily than OCaml's does, largely because the JavaScript boundary makes exceptions less predictable.

Both languages use the same keyword to give a foreign function a type the compiler trusts without checking, and both print 42 here. The difference is what it costs to point that keyword at something real. The anchor column uses "%identity", a compiler primitive — the one kind of OCaml external that links to nothing; a genuine C binding needs a stub compiled and linked, with the value representation and CAMLparam root registration correct or the collector corrupts memory. ReScript's binding is one line with an attribute: no stub, no build step, and the worst failure is a type that does not match, which produces wrong behavior rather than a corrupted heap. Attributes such as @val, @module, @send and @get say where the thing lives.

Both columns print ocaml, and reached it differently: OCaml has Filename.basename in its own standard library, while ReScript imported Node's path module in one line. That is the comparison in miniature — where OCaml's answer is not already in the standard library, binding a C library means writing stub functions, declaring them in dune, and getting the header and the library onto the compiler's and linker's paths. Binding a JavaScript module is a type annotation and an attribute — the compiler emits an ordinary import and the bundler does the rest. There is a large repository of pre-written bindings (rescript-webapi and the like), and writing one for a small API is a few minutes' work. The trade is the same as any FFI: the type you write is unverified, so a wrong binding fails at runtime.

The record's field names survive into the emitted object, so JSON.stringify produces exactly what you would expect and OCaml's ppx-deriver step is unnecessary. Parsing is the asymmetric half: Js.Json.parseExn gives you an untyped Js.Json.t, and turning that into a person requires a decoder that actually checks the shape — the same discipline TypeScript needs, and for the same reason. Asserting the type instead is possible and is the one place ReScript lets you be unsound.

Both columns print ADA and 007. OCaml calls two ordinary functions, because it has no notion of a method at all. @send declares that the first parameter is the object the method is called on, so "ada"->toUpperCase emits "ada".toUpperCase(). That is why the pipe-first operator exists: with data first, a chain of method bindings reads in call order. The companions are @val for a global, @module for an import, @get and @set for properties, and @new for a constructor. Together they cover almost every JavaScript API shape, and none of them needs a stub file, a build step, or anything linked.

ReScript's async/await compiles to JavaScript promises, so it inherits JavaScript's function coloring: an awaiting function must be async, its return type becomes a promise, and every caller wanting the value must await and therefore be async too. OCaml 5's effect handlers avoid that entirely — task is an ordinary unit -> int that suspends anyway, because the handler decides what suspension means. Note the trailing ->ignore: ReScript warns about an unused promise, which is a small guard against the forgotten-await bug.

OCaml 5's Domain is an operating-system thread with its own minor heap, so several genuinely run at once. JavaScript is single-threaded: Promise.all starts several asynchronous operations and waits for all of them, which overlaps waiting on the network or a timer but never overlaps computation — and a CPU-bound loop blocks the whole event loop. Real parallelism means Web Workers or Node's worker_threads, which communicate by message passing and share no memory. That is a genuine capability an OCaml program has and a ReScript one does not.

OCaml compiles to native code, to bytecode, to JavaScript through two separate projects, and to WebAssembly — so one codebase can serve a command-line tool, a server and a browser. ReScript targets JavaScript and nothing else, deliberately, and its whole design follows from that: uncurried application for clean output, arrays as the default collection, records as plain objects. If the program needs to run outside a JavaScript host, ReScript is the wrong tool and Melange is the interesting middle — it compiles real OCaml to JavaScript with the same npm interop, so the same source can also target native.

The set of libraries written in ReScript is modest. The set reachable from it is all of npm, through bindings you either find or write — and writing one for a small API is genuinely quick, as the interop section showed. Which of those two numbers matters depends on the work: a React frontend is well served, because the React bindings are first-class and maintained by the core team, while something needing a specific typed library will more often mean writing the binding yourself. OCaml's opam ecosystem is smaller than npm and every package in it is already typed.

GADTs let a constructor refine the type parameter, so Int produces an int expression and Bool a bool expression, and the type a. annotation lets one function return a different type per branch — which is how typed interpreters and heterogeneous structures get written in OCaml. ReScript has no GADTs, so the ReScript column has to drop the Bool case entirely and return one type. Also absent: the let* binding operators, effect handlers, and objects. For most application code none of these come up; for a compiler or a proof-adjacent library they come up constantly.

TypeScript is deliberately unsound: any, as assertions and untyped data at the boundary all let a value carry a type it does not have, and since types are erased with nothing checked, the mismatch surfaces as undefined rather than an error. That was the right call for describing fifteen years of existing JavaScript, and it means a TypeScript type is a claim rather than a fact. ReScript has no any and no assertion operator — the only place unsoundness can enter is an external binding you wrote, which is a small, greppable surface rather than a property of the language.

ReScript checks exhaustiveness the way OCaml does — automatically, on every switch, with an error naming the unhandled constructor. TypeScript's equivalent requires assigning the narrowed value to a never-typed variable in the default branch of each switch, which works and is idiomatic and is opt-in per site. Forget it once and adding a case to a union silently changes behavior instead of failing the build. For a codebase built around variants, that difference compounds.

Everything else in this section is an argument for ReScript, and it is a good argument — the type system genuinely is better than TypeScript's in the ways that matter to someone coming from OCaml. The reasons to choose TypeScript anyway are real and are all social: your team reads it, every npm package ships .d.ts files written for it, and the hiring pool and the documentation assume it. If those do not bind — a solo project, a team already sold on ML, or a frontend for an OCaml backend — ReScript is the stronger tool. And if the deciding factor is wanting to keep writing OCaml itself, Melange is the option this page has been pointing at throughout: real OCaml, real dune and opam, compiled to the same readable JavaScript.

@genType generates TypeScript declaration files for the annotated values, so a .res module can be imported from TypeScript with accurate types and no hand-written bindings. That makes incremental adoption real: one module at a time, with the boundary checked in both directions. It is also the answer to the strongest practical objection on the previous row — you do not have to convince the whole team at once. Nothing equivalent exists for OCaml consumed from another language; there the boundary is a C FFI in both directions.