OCaml.CodeCompared.To/TypeScript

OCaml's let () = … binds the unit pattern, which runs the expression and asserts it produces nothing. TypeScript has no such notion: a module's top-level statements execute in order when it is loaded. console.log is not part of the language at all — it comes from the host, which is the browser here and Node when you run tsx, and that distinction between the language and its host matters more in JavaScript than in most places.

OCaml's format string is a typed value: the compiler reads %s and %d and demands exactly a string then an integer, so a mismatch is a compile error. A TypeScript template literal calls String() on whatever each expression evaluates to, so there is nothing to mismatch — swapping name and year would produce different text and no complaint. In exchange the syntax embeds arbitrary expressions inline, which OCaml needs sprintf and separate arguments for.

"strict": true is not optional in practice, and it is worth knowing before reading anyone's code. Without it, null and undefined are members of every type, function parameters default to any, and most of what makes TypeScript worth using is switched off. It bundles several flags, of which strictNullChecks is by far the most important — see the nullability section. The other structural difference from OCaml is that node_modules is per-project by default, so there is no switch to activate and no global state to get wrong.

OCaml records and variants are nominal: a type is the one you declared, and two declarations with identical contents are unrelated. TypeScript is structural: a type is a description of a shape, and any value with that shape belongs. That means no adapter code to pass a value from one library to another, and it also means the Fahrenheit above sails into a function that wanted Celsius. OCaml has structural typing too — in its object system and its polymorphic variants — but not for records and variants, which is where all the real code lives. The TypeScript workaround is a "branded" type, which fakes nominality by adding a field that exists only in the type.

This follows directly from structural typing and is usually what you want — a function asking for { x, y } should accept anything that has them. There is one exception worth knowing: an object literal written directly at the call site gets excess-property checking, so describe({ x: 0, y: 0, label: "origin" }) is rejected while the variable above is accepted. That inconsistency exists to catch typos in literals, and it surprises everybody once. OCaml has no such question: a record literal has exactly the fields of exactly one declared type, and a misspelled field is an error naming it.

The implements clause above is documentation, not the mechanism — because typing is structural, NumberBox would satisfy Describable even without it, and any object with a describe(): string method would too. Deleting the clause changes nothing but the error message when the class stops matching. The thing an OCaml signature does that an interface cannot is carry an abstract type: type t in the anchor column names a type the implementation chooses and callers cannot see through. TypeScript has no equivalent; the nearest approximations are generics and branded types.

OCaml erases types too — there is no runtime type information — but it does so after proving the program well-typed, so erasure costs nothing. TypeScript's type system is deliberately unsound: as assertions, any, and untyped data crossing a boundary all let a value carry a type it does not have, and since nothing is checked at runtime the mismatch surfaces as undefined rather than an error. That is a design decision, not a bug — it is what lets TypeScript describe fifteen years of existing JavaScript. The habit an OCaml programmer needs is to treat every as as an unchecked assertion and to validate data at the boundary with a schema library rather than asserting it.

any disables checking for a value and everything reached through it — assignments, property access, calls — and it spreads, because anything derived from an any is also any. unknown is the type-safe counterpart: it accepts any value and permits nothing until you narrow it with a typeof check, an instanceof, or a type guard. OCaml has no equivalent of either; the closest thing is Obj.magic, which is deliberately hard to find and would be a code-review event. Prefer unknown and narrow, and treat every any in a codebase as a hole where the checker stops.

This is control-flow-based narrowing, and it is one of TypeScript's genuinely clever pieces: a typeof, an instanceof, a truthiness check, or a comparison against a literal all refine the type for the rest of the block. OCaml achieves the same effect through pattern matching, which is more uniform and comes with an exhaustiveness proof. TypeScript can prove exhaustiveness too, but only for a union and only with the never trick shown in the discriminated-unions section — it is not automatic the way match is.

The return type value is Person is a type predicate: when the function returns true, the compiler narrows the argument to Person for the rest of the block. That gives you the same shape as an OCaml parse — untyped data goes in, a known type comes out, and the failure case is visible — with one crucial difference: nothing verifies that the guard actually checks what it claims. A guard whose body is return true type-checks perfectly and lies. In practice most codebases delegate this to a schema library (zod, valibot, ArkType) that derives both the type and the validator from one declaration, which is much closer to what a ppx deriver does for OCaml.

OCaml's let … in introduces a new scope for each binding, so shadowing in sequence is natural and idiomatic. TypeScript's const is scoped to the enclosing block, and declaring the same name twice in one block is an error — so shadowing requires an actual nested block, as the second half shows. const means the binding cannot be reassigned, not that the value is immutable: const items = [1]; items.push(2) is perfectly legal. let allows reassignment; var is function-scoped, predates both, and should not be used.

OCaml runs Hindley–Milner over the whole program, so a function's type is discovered and writing it down is optional. TypeScript infers return types, local variables, array element types and generic instantiations, but not parameters — an unannotated parameter is an implicit any, which strict mode makes an error. That is the same trade Rust makes and for the same reason: an error gets reported at the function that is wrong rather than wherever unification finally failed. TypeScript's inference is also, unlike OCaml's, not principal — there are places where it picks a reasonable answer rather than the most general one.

The spread { ...origin, x: 5 } is exactly OCaml's { origin with x = 5 }, and readonly makes assignment a compile error. Two caveats an OCaml programmer should hold onto. It is erased, so nothing prevents mutation from JavaScript that was never type-checked, and a readonly value passed to a function expecting a mutable one is accepted in some positions. And it is shallow: readonly on an object does not freeze what its fields point at. as const goes deeper for literals, and Object.freeze is the runtime version.

OCaml distinguishes int from float at the type level and gives them separate operators (/ and /.), so integer division is the default for integers and mixing the two is a compile error. TypeScript's number is a double, so 7 / 2 is 3.5 and integer division needs Math.trunc or Math.floor. Integers above 2^53 lose precision — Number.MAX_SAFE_INTEGER is that boundary — and 0.1 + 0.2 prints the famous 0.30000000000000004. bigint exists for arbitrary-precision integers, written 42n, and does not mix with number.

An OCaml string is a sequence of bytes, so this word occupies six of them and String.length answers 6. A JavaScript string is a sequence of UTF-16 code units, so it answers 5 — closer to a human count for European text, and still wrong for anything outside the basic plane, where an emoji counts as 2. Note also that OCaml's uppercase_ascii says in its name that it only handles ASCII, which is honest; toUpperCase is Unicode-aware. String methods live on the value in TypeScript and in a module in OCaml, which makes them discoverable by typing a dot.

unshift, push, splice, sort and reverse all modify the array in place and are the methods people reach for first — sort in particular surprises everyone, since it returns the array it just mutated. The spread form [0, ...base] is the non-destructive equivalent of consing and is what to reach for when the original matters. Recent JavaScript added toSorted, toReversed and with, which are the non-mutating versions of the classic methods and are worth preferring.

Map takes keys of any type, preserves insertion order, has a size, and does not inherit anything — which makes it the right default. A plain object used as a dictionary coerces every key to a string, inherits Object.prototype (so "toString" in object is true even for an empty one), and is what JSON gives you. Note the lookup shape: Map.get returns undefined for a missing key, which is TypeScript's option, and under strict the return type is number | undefined so the check above is enforced.

OCaml's |> works because the module functions are curried and take their data last. TypeScript's methods live on the array, so chaining needs no operator — and it is why JavaScript never adopted a pipeline operator despite years of proposals. Both versions build an intermediate array at each step; JavaScript's lazy equivalent is a generator or the newer iterator-helper methods. One thing to watch: reduce without an initial value throws on an empty array, exactly as OCaml's fold_left does not — the seed is mandatory there.

The destructuring reads almost identically. The difference is what the value is: an OCaml tuple is its own kind of thing, while [number, number] is an ordinary JavaScript array that the type system promises has exactly two numbers. Since the promise is erased, tuple.push(3) compiles in some positions and the array then has three elements. TypeScript tuples can also have optional and rest elements ([string, ...number[]]) and named positions for documentation, neither of which OCaml has.

OCaml's Set.Make (Int) builds a module specialized to integer elements, and its union returns a new set leaving both operands untouched. JavaScript's Set is a builtin that preserves insertion order and compares members with === — which means two objects with identical contents are different members, since === on objects is identity. That makes Set useful for primitives and awkward for structured values, where OCaml's structural comparison just works. The set-algebra methods (union, intersection, difference) are a recent addition; older code does the same work with spreads and filters.

TypeScript has no pattern matching. switch compares values with === and nothing more: no guards, no destructuring of the matched value, no binding of sub-parts, and no exhaustiveness unless you construct it manually. Or-patterns become stacked case labels relying on fallthrough, and a guard becomes a conditional in the default. Destructuring exists but only in bindings and parameters, not as a dispatch mechanism. A TC39 proposal for a real match expression has been in progress for years. Until it lands, the closest thing to OCaml's match is a discriminated union plus a switch on the tag, which the next section covers.

OCaml has no mutable local bindings, so a while counter must live in a ref and be read with !. TypeScript's let is a genuine mutable binding. TypeScript also has for … of for iterating values and for … in for iterating an object's keys — the two are easy to confuse and for … in over an array gives you string indices, which is almost never wanted. Note also that OCaml has no break or continue, so a loop that needs to stop early is written as a recursive function or with an exception.

OCaml's = compares any two values structurally by walking their representations, so two equal lists are equal. JavaScript's === compares primitives by value and objects by identity, so two arrays with the same contents are never equal — which is why the JSON.stringify comparison above exists as a common hack, and why libraries ship a deepEqual. == additionally coerces its operands and produces results like 0 == "" being true; every style guide bans it. OCaml's == is physical identity, and it is the one people reach for by mistake in the other direction.

OCaml destructures a record in an ordinary binding, and destructures a list only through a match — because let first :: rest = … is a partial pattern and draws an inexhaustive-match warning naming the empty case. That is the difference worth seeing: TypeScript's array destructuring never warns, and const [first] = [] silently binds undefined. What TypeScript adds is renaming (name: who) and per-field defaults inside the pattern, which OCaml has no syntax for. Destructuring is also how TypeScript gets named function arguments, as the optional-parameters row showed.

In OCaml add 10 is ordinary application, because add genuinely has type int -> int -> int. TypeScript's arrow syntax makes the curried form short to write — (a) => (b) => … — and TypeScript infers its type correctly, but a normal function declaration is not curried and calling it with too few arguments is an error. The knock-on effect is that OCaml's point-free pipelines do not translate: TypeScript chains methods on the data instead, which is why the array methods read the way they do.

OCaml labels an argument with ~ and defaults it with ?, and the trailing () exists because a function with optional arguments cannot otherwise be known to be fully applied. TypeScript has positional defaults (function greet(name: string, greeting = "Hello")) and marks a parameter optional with ?, but callers cannot name a positional argument. Destructuring an object parameter, as above, gets you named arguments with defaults and is completely standard — with the bonus that the options object is a value you can build up, which OCaml's form cannot be. Note the ? on greeting in the type: optional there means "may be absent", which is subtly different from "may be undefined".

OCaml has no implicit receiver at all: bump counter takes the record as an ordinary argument, so passing the function around cannot break it. In JavaScript, counter.bump() passes counter as this because of the dot, and the same function called without one gets undefined. That is why detached methods break, why callbacks need .bind(this), and why the class-property arrow form exists — an arrow function captures this from where it was defined, so it survives detachment. This is a JavaScript inheritance, not a TypeScript decision, and it is one of the language's sharpest edges.

OCaml has no variadic functions — every function has a fixed arity, and a variable number of things is a list. That is arguably cleaner, and it means Printf.printf's apparent variadicity is a piece of compiler magic around the format type rather than a general feature. TypeScript's ...numbers: number[] collects the remaining arguments into a typed array, and the spread total(...values) goes the other way. Rest elements can also appear in tuple types ([string, ...number[]]), so a function's exact argument shape can be described precisely.

The spread { ...origin, x: 5 } creates a new object with the listed field overridden, which is { origin with x = 5 } under different punctuation. Two differences underneath: TypeScript's object is mutable unless every field is readonly, and its type is structural, so any object with an x and a y is a Point. Note also that a spread is shallow — nested objects are shared between the original and the copy, exactly as OCaml's with shares its unchanged fields, which is invisible in OCaml because nothing can mutate them.

OCaml's objects are structurally typed and genuinely interesting, and real OCaml code uses records, variants and modules instead. TypeScript classes are JavaScript classes with type annotations, plus a few compile-time-only additions: public, private and readonly on a constructor parameter declare and assign the field in one line, which is what public readonly owner above does. private is erased and enforced only by the compiler; the runtime version is a #field, which is genuinely inaccessible from outside.

JSON is JavaScript's own object literal syntax, so JSON.stringify and JSON.parse are builtins and serialization is free. OCaml has no JSON in its standard library; yojson plus a ppx deriver gets you there with a dependency and a little ceremony — and gets you something TypeScript does not have, which is a checked conversion. JSON.parse returns any, so the as Person above is an unverified assertion: if the text is missing age, nothing complains and parsed.age is undefined. Validate at the boundary with a schema library rather than asserting; the next row shows the hand-written version.

A discriminated union is a union of object types sharing a literal-typed tag field, and switching on that tag narrows each branch to exactly one member — so shape.radius is available in the circle case and nowhere else. That is the same guarantee OCaml's match gives. Two real differences: the tag is a field you invent and maintain rather than a constructor the language provides, so nothing stops two unions using different tag names; and exhaustiveness is not automatic — this function compiles because every branch returns, and the next row shows how to demand more.

The trick is never, the type with no values. When every case is handled, TypeScript narrows status in the default branch to never, and assigning it to a never variable is fine. Add a fourth member to Status and that assignment becomes an error naming the unhandled case — which is exactly OCaml's warning, obtained by construction rather than by the compiler's own initiative. It is idiomatic and widely used, and it is opt-in per switch: forget it once and adding a case silently changes behavior. This is the single biggest reason to be careful when translating a variant-heavy OCaml design.

OCaml's polymorphic variants are the nearest thing: they need no declaration and a value can belong to several types. But they still wrap — a `Text "hi" is not a string, and unwrapping is required. TypeScript's string | number contains the plain values themselves, so no construction or destruction happens at all and any existing value fits. This is the piece of TypeScript's type system that has no OCaml counterpart, and it is what lets the language describe JavaScript APIs that genuinely accept several unrelated types. The cost is that narrowing depends on a runtime test rather than a tag the language guarantees.

OCaml has no way to make a value into a type: North is a constructor of the direction type, and getting its name as a string means writing a converter. TypeScript's "north" is a type whose only value is that string, so a union of them is an enumeration whose members are already strings — no conversion needed, and they serialize to JSON directly. Record<Direction, Direction> additionally requires a key for every member, so leaving one out is a compile error, which recovers some of the exhaustiveness OCaml gives for free. TypeScript does have an enum keyword; string-literal unions are generally preferred over it.

Named & Aged is the type of values that have both a name and an age, formed without declaring anything new. OCaml's record types are nominal and closed, so combining two means writing a third that repeats both sets of fields, or nesting — and either way the resulting type is unrelated to the originals. Intersections make TypeScript's mixin patterns and extension objects possible. Their edge case is worth knowing: intersecting two object types that disagree on a field's type produces a field of type never, which is legal and uninhabitable rather than an error.

OCaml infers 'a list -> 'a -> 'a with no annotation, because parametric polymorphism is the default rather than a feature. TypeScript needs <T> written out, and then infers T at each call from the arguments — so the explicit <string> above is only needed because the empty array gives it nothing to infer from. Both are resolved entirely at compile time and erased. TypeScript adds constraints (<T extends { length: number }>) and defaults (<T = string>), which have no OCaml analogue on a plain function.

Partial<T> is a mapped type: it iterates the keys of T and produces a new type with each field optional. The standard library ships Partial, Required, Readonly, Pick, Omit, Record and ReturnType, and you can write your own with keyof, indexed access, conditional types (T extends U ? X : Y) and template literal types. The result is a Turing-complete type-level language, which is powerful and also the reason some TypeScript codebases have types nobody can read. OCaml keeps the type language deliberately small; what it offers instead is the module system, where the abstraction happens at the value level.

typeof settings in a type position means "the type this value was inferred to have", and keyof turns a type into the union of its key names. Combined with an indexed access (Settings[K]), the get above returns string for "theme" and number for "fontSize" — a different type per argument, derived rather than declared. OCaml has no bridge between the value and type worlds at all: a field-name list is a separate value that can drift out of step with the record, as the anchor column shows. This is a real capability TypeScript has and OCaml does not.

OCaml modules nest, can be defined inline, can be constrained by a signature, passed to a functor and packed into a value. ES modules are files with an export keyword on each public declaration and an import naming the ones you want. There is no nesting, no signature, and no functor — TypeScript's old namespace keyword offered nesting and is deprecated for new code. One import gotcha worth knowing: under NodeNext resolution the specifier keeps the .js extension even though the source is .ts, because that is what the emitted file will be.

An OCaml functor takes a module of types and operations and produces a module. TypeScript has no module-level parameterization at all — the substitutes are generic functions taking their operations as ordinary parameters, as above, and generic classes or interfaces. The common case comes out shorter. What is lost is what functors are actually for: bundling a type with its operations so that the pairing is checked, and instantiating that bundle once rather than threading the operations through every call. TypeScript has no way to say "this type comes with these operations" and have the compiler supply them.

undefined is what a missing property, an unset variable or a function with no return gives you; null is an explicit "no value" someone assigned. Both are in the type system separately, so string | undefined and string | null are different types, and code that handles one may not handle the other. The ?? operator supplies a fallback for either — unlike ||, which also fires on 0 and "" and is a common bug. The typeof null answer of "object" is a bug from 1995 that can never be fixed. Under strict, neither value is a member of other types, which is the setting that makes this section tractable at all.

a?.b?.c evaluates to undefined the moment any link is null or undefined, without evaluating the rest — so a five-deep chain needs one ?. per link and no nesting. OCaml needs Option.bind at each step, or a let* binding operator defined first, and each step costs a line. The syntax also covers calls (callback?.()) and indexing (items?.[0]). What TypeScript does not give you is the discipline: nothing forces the check, so a type that is not marked optional is simply trusted, and untyped data at the boundary can violate that.

OCaml catches by pattern, so | Too_large value -> both selects the exception and binds its payload, and the compiler knows the type. In TypeScript the caught value is typed unknown under strict, because JavaScript permits throwing anything — a string, a number, an object with no relation to Error. So every handler that wants the payload has to narrow with instanceof first. Neither language records in a function's type which exceptions it may raise, but OCaml at least gives the handler a typed pattern to match against.

The three-line Result above narrows correctly: after outcome.ok is checked, outcome.value is available in one branch and outcome.error in the other, with no assertion. That is real ML-style error handling and several popular libraries ship a fuller version. What is missing is the ecosystem convention — the standard library and nearly every npm package throws, so a codebase using Result is converting at every boundary. There is also no ? operator, so chaining several fallible steps means nesting or a helper, exactly as it does in OCaml without let*.

TypeScript's async/await compiles to a state machine and colors functions: a function that awaits must be async, its return type becomes a Promise, and every caller that wants the value must await it and therefore be async too. Introducing one asynchronous call at the bottom of a call chain means changing every signature above it. OCaml 5's task is an ordinary unit -> int that suspends anyway, because the handler decides what suspension means rather than the callee — which is why OCaml 5 needs no async keyword and why libraries like Eio present blocking-looking APIs that do not block.

OCaml 5's Domain is an operating-system thread with its own minor heap, so several genuinely run at once on separate cores. JavaScript is single-threaded: Promise.all starts several asynchronous operations and waits for all of them, which overlaps waiting — for the network, a timer, a file — but never overlaps computation. A CPU-bound loop blocks the entire event loop, including rendering. Real parallelism means Web Workers in a browser or worker_threads in Node, which communicate by message passing and share no memory by default.

This is the part of async/await that works better than it has any right to: try/catch around an await catches a rejection exactly as it would a synchronous throw, so error handling reads the same in both worlds. The trap is what happens when you do not await — a rejected promise nobody handles becomes an unhandled rejection that may be reported asynchronously, long after the code that caused it, or crash the process in Node. OCaml has no equivalent hazard because there is no deferred computation to lose track of; an unhandled exception unwinds immediately.

js_of_ocaml compiles OCaml bytecode to JavaScript and is mature and widely used. Melange compiles OCaml source to readable JavaScript modules with a focus on interoperating with npm packages. Both keep the whole language — the module system, functors, exhaustive matching, sound inference — and both let you call JavaScript and be called from it. The reason to write TypeScript instead is rarely the language: it is that your colleagues read it, that the type definitions for every npm package are written in it, and that hiring, tutorials and Stack Overflow all assume it. Those are real reasons. They are just not claims about the type system.

ReScript started as BuckleScript, a JavaScript backend for the OCaml compiler, and for years you wrote OCaml and got JavaScript. It has since forked its syntax — curly braces, switch for match, #Tag for a polymorphic variant — and made application uncurried, so it is now its own language rather than an OCaml dialect. But it kept far more than its reputation suggests: functors, module signatures, polymorphic variants, labeled and optional arguments, exceptions and first-class modules all still work, which is more than F# or Haskell can say. It also kept the part that matters most here: sound type inference with no any, real variants with exhaustive matching, and no null in any type. If the reason for learning TypeScript is "I need to ship to the browser" rather than "my team writes TypeScript", ReScript and Melange are worth an afternoon before committing.