필사 모드: Modern OCaml 2026 — OCaml 5.3 / Multicore / Effect Handlers / Dune / Opam / MirageOS / ReScript / Melange / Jane Street Deep Dive
English> "OCaml has always been industry's next quarter. The next quarter has now lasted twenty-five years." — anonymous PL researcher
This post is **a single-shot map of the OCaml ecosystem as of May 2026**. When OCaml 5.0 brought multicore and effect handlers in December 2022, the long-standing "single-core functional language" weakness disappeared, and through the 5.3 stabilization in January 2025 it returned to serious industrial conversation. Jane Street has run trading systems on OCaml for twenty-five years, Meta writes Hack and Flow in it, and Tezos implements the XTZ blockchain consensus layer in OCaml. On the frontend side, ReScript took over as BuckleScript's successor and Melange dragged that compiler back into the mainline OCaml world.
The post covers OCaml 5.x runtime changes (multicore, effect handlers), Dune and Opam tooling standards, MirageOS unikernels, the JS-compilation fork (js_of_ocaml, ReScript, Melange, Reason), concurrency libraries (Eio, Lwt, Async), web frameworks (Cohttp, Dream), industrial use cases (Tezos, Meta, Jane Street), academia (KAIST, Kyoto, Tokyo Tech), and a decision guide on who actually should learn OCaml — thirteen chapters end to end.
1. Modern OCaml in 2026 — The Multicore Era
OCaml started at INRIA in 1996 as an ML-family functional language. For nearly thirty years it was industry's "next quarter," but in December 2022 the GA of OCaml 5.0 brought one decisive change: **a multicore runtime** and **effect handlers**. Before that, OCaml was effectively single-core with a single-threaded GC. After 5.0, parallel execution at the domain level plus user-defined control flow via effects became possible.
In 2026, the OCaml ecosystem looks roughly like this:
- **Compiler**: OCaml 5.3 (January 2025) — the stabilized 5.x multicore line
- **Build**: Dune (Jane Street plus community) — the de facto standard
- **Packages**: Opam (OCaml Package Manager) — the de facto standard
- **Unikernels**: MirageOS — Anil Madhavapeddy plus Cambridge / Tarides
- **JS compilation**: js_of_ocaml (classic), ReScript (Hongbo Zhang, now its own thing), Melange (pulls the ReScript compiler back into OCaml), Reason (Facebook's syntax)
- **Concurrency**: Eio (effect-based, multicore), Lwt (classic event loop), Async (Jane Street)
- **Web**: Cohttp (HTTP basics), Dream (Rails-like full stack), Opium, Httpaf
- **Industry**: Jane Street (the largest OCaml employer in the world), Tezos (XTZ blockchain), Meta (Hack / Flow), Docker (early Docker was OCaml), Tarides (MirageOS / Tezos consulting)
- **Academia**: KAIST PL lab (Korea), Kyoto University PL lab / Tokyo Tech (Japan), Cambridge OCaml Labs, INRIA
One interesting fact. Between 2024 and 2025, Coq rebranded to Rocq (covered in its own post), and the OCaml-based formal-verification ecosystem regained visibility. Rocq's backend is still written in OCaml. Despite Lean 4's rise, OCaml has not lost its seat as "the language PL researchers actually use."
Another. In 2026 OCaml has a small but growing niche in **AI training infrastructure**. Tarides published Eio plus multicore benchmarks that hold up against Tokio and async-std for single-node throughput, and MirageOS-based unikernels are getting re-evaluated as candidates for sandboxed code-execution environments. The joke "OCaml is dead" has stopped being a joke and started being wrong.
2. OCaml 5.x — Multicore + Effect Handlers (GA Dec 2022)
OCaml 5.0 GAed in December 2022. The Multicore OCaml project ran out of Cambridge from 2014 onward, led by Anil Madhavapeddy, KC Sivaramakrishnan, and Stephen Dolan. It lived as a separate branch outside the OCaml mainline for roughly eight years, then went through 4.14 stabilization and merged into 5.0.
The two core 5.x additions:
**1) Domain-based parallelism.** OCaml now creates domains on top of OS threads, each domain owning its own minor heap. The major heap is shared but GC synchronizes at the domain boundary. The result is genuine multicore execution. `Domain.spawn` launches a new domain, and the `Atomic` module gives you lock-free atomic operations.
(* domain_demo.ml *)
let count = Atomic.make 0
let worker () =
for _ = 1 to 1_000_000 do
Atomic.incr count
done
let () =
let d1 = Domain.spawn worker in
let d2 = Domain.spawn worker in
Domain.join d1;
Domain.join d2;
Printf.printf "final = %d\n" (Atomic.get count)
**2) Effect handlers.** Effects are the biggest language-level addition in OCaml 5. A function performs an effect, and the caller either handles it or propagates it upward. The result is that user-space coroutines, generators, async/await, exceptions, and dependency injection can all be expressed through one mechanism. What other languages bundle as separate features OCaml unifies through effects.
open Effect
open Effect.Deep
type _ Effect.t += Yield : int -> unit Effect.t
let producer () =
for i = 1 to 5 do
perform (Yield i)
done
let () =
try_with producer ()
{ effc = fun (type a) (eff : a Effect.t) ->
match eff with
| Yield n -> Some (fun (k : (a, _) continuation) ->
Printf.printf "got %d\n" n;
continue k ())
| _ -> None }
Effects pay off most visibly in **Eio** (next chapter). Implementing async/await as a library, without dedicated keywords, is the headline consequence of effects.
5.x weaknesses:
- **C FFI compatibility**: just after 5.0 some C bindings broke under the multicore runtime. By 5.2 in 2024 most were cleaned up
- **Performance regressions**: a handful of microbenchmarks lost about 5 percent of single-thread throughput vs 4.14. Mostly recovered in 5.2
- **Effect learning curve**: there is no effect row in the static type system (unlike Koka). The compiler does not statically catch unhandled effects, so you get a runtime `Unhandled` exception
Even so, 5.x is OCaml's largest leap. Essentially every new project in 2026 is on 5.x.
3. OCaml 5.3 (January 2025) — Stabilization
OCaml 5.1 shipped in September 2023, 5.2 in May 2024, and 5.3 in January 2025. The 5.x line settled into a cadence of roughly one major update per quarter.
Highlights of 5.3:
- **Improved static checking around effect handlers**: 5.3 introduced `effect` as proper syntax (previously only library-level `type _ Effect.t += ...`), and the compiler now inlines some effect dispatch, lowering overhead
- **GC tuning**: minor GC behaves better across multiple domains. Cross-domain promotion costs are down about 30 percent vs 5.2
- **Statmemprof standardization**: the memory profiler moved into the standard library
- **Domain.recommended_domain_count**: an API to suggest a reasonable domain count for the system. Eio and Picos default to it
- **Port cleanup**: better support for musl libc, RISC-V 64-bit, and ARM 32-bit big-endian
- **Small additions**: `String.starts_with` and `String.ends_with` in stdlib, `In_channel.read_lines`, and so on
5.3 is generally treated as the first LTS-level release on the 5.x line. Jane Street, Tezos, and Tarides all moved production to 5.3 in mid-2025.
Standard 2026 OCaml install (via Opam)
opam init -y
opam switch create 5.3.0
eval $(opam env)
ocaml --version
The OCaml toplevel, version 5.3.0
5.4 and 5.5 have been in nightlies since autumn 2025. The most active RFCs are around introducing Koka-style effect row types. The OCaml core team is famously conservative about evolving the type system, so it is unclear whether effect rows will land in 5.5.
4. Dune — The Build System Standard
Dune is the OCaml build system originally built at Jane Street. It started as jbuilder and was renamed to Dune at its 1.0 release in 2018. By 2026, essentially every OCaml project uses Dune. `ocamlbuild`, `oasis`, and `omake` are effectively legacy.
Dune strengths:
- **Declarative build files**: `dune` files express libraries, executables, and tests as S-expressions
- **Automatic dependency extraction**: dependency analysis via ocamlfind and ocamldep
- **Incremental builds and caching**: caching at module and config level, not just file level
- **Multiple libraries in one directory**: one folder can host several libraries and executables
- **Cram and inline tests**: integrates with PPXes like `let%test`
- **Watch mode**: `dune build -w` rebuilds on file changes
- **Cross-compilation**: `dune build --workspace` can drive several compilers at once
Basic dune file:
(library
(name my_lib)
(public_name my_lib)
(libraries base core lwt cohttp-lwt-unix)
(preprocess (pps ppx_jane)))
(executable
(name main)
(public_name myapp)
(libraries my_lib))
dune-project file:
(lang dune 3.16)
(name myapp)
(generate_opam_files true)
(package
(name myapp)
(synopsis "A demo OCaml app")
(depends
(ocaml (>= 5.3.0))
(dune (>= 3.16))
eio
cohttp-eio))
**Diskuv case study**: Diskuv built the Windows-native OCaml developer experience. They drove the work that made Dune a first-class citizen on Windows, and from dune 3.14 in 2024 Windows support is officially supported. Before that, using OCaml on Windows without WSL was genuinely painful. Thanks to Diskuv's contributions, in 2026 you can install with a single `winget install Diskuv.OCaml`.
Dune weaknesses:
- **Error messages are giant S-expressions**: overwhelming on first encounter
- **Limited integration with external build systems**: no direct hook into Bazel or Buck
- **Monorepo scale ceiling**: very large monorepos can hit incremental build slowness. Jane Street uses an internally forked variant of Dune
There is effectively no alternative. New OCaml projects in 2026 default to Dune.
5. Opam — The Package Manager
Opam started in 2012 as a joint OCamlPro and INRIA project. The name is short for "OCaml Package Manager." By 2026 the opam-repository hosts more than 7,000 packages, with new releases landing every week.
Opam's core model:
- **Switch**: a compiler plus a package set. Each project can have its own switch. `opam switch create my-proj 5.3.0`
- **Repository**: a set of package metadata. The default is the public [opam-repository](https://github.com/ocaml/opam-repository). You can layer internal repositories on top
- **Pin**: pin a local directory or git URL as a package. `opam pin add my_lib .`
- **Lock files**: `opam lock` pins exact versions. First-class since 2.1
Day-to-day commands:
Create a new switch
opam switch create my-proj 5.3.0
Install dependencies
opam install dune eio cohttp-eio dream
Pin a local package
opam pin add my_lib .
Generate a lock file
opam lock .
Search the package set
opam search effect
The opam-repository lives on GitHub, and anyone can submit a PR to add a new package or version. CI validates builds and tests during admission, and that gatekeeping is a major reason the OCaml ecosystem has so few outright broken packages.
Opam weaknesses:
- **Slow**: dependency resolution is visibly slower than Cargo or npm. The solver is based on academic OPL / Mancoosi work
- **Solver nondeterminism**: the same dependency tree can pick different versions depending on the OS or platform
- **Global state**: switches are globally scoped, which gets confusing across many projects on one machine. The fix is local switches (`opam switch create . 5.3.0`)
The 2026 best practice is **a local switch per project plus opam lock**. Checking the lock file in CI gives you reproducible builds.
6. MirageOS — Unikernels
MirageOS is a unikernel project led by Anil Madhavapeddy at Cambridge OCaml Labs. The 1.0 release came in 2013, and by 2026 the 4.x line is stable.
The unikernel concept:
- **One application plus only the OS facilities it needs, in a single binary**: not Linux plus container plus app, but a hand-picked set of OS facilities and the app, compiled into one image
- **Boots directly on a hypervisor**: KVM, Xen, or Solo5. No guest OS in between
- **Small images**: typically 5 to 20 MB, with boot times in tens of milliseconds
- **Minimal attack surface**: roughly 99 percent of a general OS is gone. No shell, no package manager, no irrelevant syscalls
MirageOS builds unikernels in OCaml. It uses the module system (functors) to abstract pieces like "network stack," "file system," and "TCP/IP," and at build time it injects the right implementations for the target.
(* unikernel.ml *)
open Lwt.Infix
module Main (S: Mirage_stack.V4V6) = struct
let start s =
let port = 8080 in
let cb flow =
let ip, p = S.TCP.dst flow in
Logs.info (fun f -> f "client %a:%d" Ipaddr.pp ip p);
S.TCP.write flow (Cstruct.of_string "hello unikernel\n") >>= fun _ ->
S.TCP.close flow
in
S.TCP.listen (S.tcp s) ~port cb;
S.listen s
end
Build and run
mirage configure -t hvt # Solo5 hvt target
make depend
make
solo5-hvt --net:service=tap0 -- ./unikernel.hvt
**Who runs MirageOS in 2026**:
- **Robur** (German nonprofit, the main MirageOS contributor): runs TLS proxies, DNS resolvers, and OpenVPN as unikernels
- **Tarides** (French OCaml consultancy): explores MirageOS-based sandboxed build and execution environments
- **Tezos**: some node components are evaluated for MirageOS deployment
- **AI sandboxed execution**: from 2025 onward, MirageOS has been revisited as a way to safely run LLM-generated code. The isolation strength beats containers
MirageOS weaknesses:
- **Ecosystem size**: many ordinary OCaml libraries do not work as-is (they assume POSIX)
- **Debugging**: standard OS tools do not apply. You have to learn remote gdb attachment and so on
- **Operator scarcity**: very few SREs have actually run unikernels in anger
Still, MirageOS is one of OCaml's most distinctive achievements. The idea of assembling an OS from functorial modules actually runs in production.
7. js_of_ocaml — JS Compilation
js_of_ocaml (jsoo) is the OCaml-to-JavaScript compiler driven since 2010 by Jérôme Vouillon at INRIA. It takes **OCaml bytecode as input and emits JavaScript**. The OCaml compiler produces bytecode and jsoo translates that into JS.
Characteristics:
- **Full OCaml fidelity**: the standard library, Lwt, and effects almost all work. ML semantics are preserved
- **Large output**: typical bundles are 1 to 3 MB because the stdlib has to come along
- **Tree shaking**: dead-code elimination has improved a lot in the 5.x era, but bundles are still bigger than ReScript output
Basic usage
ocamlfind ocamlc -package js_of_ocaml -package js_of_ocaml-ppx \
-linkpkg main.ml -o main.byte
js_of_ocaml main.byte -o main.js
The strength of js_of_ocaml is that **you can run essentially any OCaml code in the browser as is**. The Tezos blockchain client runs parts of the OCaml node in-browser via jsoo. The jsCoq (Rocq) tooling is also jsoo-based.
The weakness is **bundle size** plus **awkward JS interop**. Converting OCaml types to JS objects gets verbose. The next chapter — ReScript — exists to fix exactly that.
8. ReScript (formerly BuckleScript, Hongbo Zhang) — JS-Friendly
BuckleScript was created in 2016 by Hongbo Zhang at Bloomberg (Chinese background, now at the ReScript Association). The philosophy is the inverse of js_of_ocaml: it takes the **OCaml AST and emits readable JavaScript**. The output JS maps nearly one-to-one to the input OCaml.
In 2020 BuckleScript rebranded as **ReScript** and made one big decision: **break OCaml syntax compatibility and adopt a syntax of its own**. Constructs like `;;`, `let rec`, and `module` look different in ReScript. The syntax moved toward something a JavaScript developer would find familiar — curly-brace blocks, JS-flavored let bindings, and so on.
// ReScript 2026 syntax
let greet = (name) => {
let msg = `Hello, ${name}!`
Js.log(msg)
}
let main = () => {
greet("ReScript")
}
main()
ReScript strengths:
- **Small, clean JS output**: human-readable JS, with bundles roughly 10x smaller than js_of_ocaml's
- **Strong TypeScript interop**: `genType` exports ReScript types as TS types
- **React-friendly**: official `rescript-react` is a first-class citizen
- **Fast hot reload**: the compiler is very fast, so the edit-reload loop is tight
Weaknesses:
- **Separated from OCaml**: ReScript is no longer OCaml. The dependency ecosystem is separate and opam packages do not apply
- **No PPX**: the OCaml macro system is not usable
- **Smaller market**: still tiny compared to TypeScript
Through ReScript 11 and 12 in 2024 and 2025, the toolchain matured. By 2026 it shows up in some Japanese startups (a few Mercari teams, smaller fintechs) and small European companies. It is essentially absent from the Korean job market.
9. Melange — The ReScript Compiler Back to OCaml
Melange is a project started in 2022 by Antonio Monteiro. The idea is straightforward: **since ReScript broke from BuckleScript and dropped OCaml compatibility, take the OCaml-compatible core of BuckleScript and pull it back into the mainline OCaml world**.
Melange forks BuckleScript's OCaml-to-JS backend and evolves it in a different direction from ReScript. The differences:
- **OCaml syntax preserved**: the source language is OCaml, not the new ReScript syntax
- **Dune integration**: builds go through Dune, not ReScript's own builder
- **Opam integration**: opam is the package manager, and many ordinary OCaml libraries just work
- **Reason syntax also supported**: you can write Reason (Facebook's syntax) as the frontend
(* Melange source — OCaml syntax *)
let greet name =
let msg = Printf.sprintf "Hello, %s!" name in
Js.log msg
let () = greet "Melange"
; dune file for Melange
(melange.emit
(target output)
(libraries my_lib)
(preprocess (pps melange.ppx)))
Melange's positioning is clear: **when an OCaml developer wants to emit JavaScript**. Where ReScript moved away from OCaml to attract JS developers, Melange keeps the OCaml developer on the same language and tooling all the way to the frontend.
Through 2024 and 2025 Melange matured through 1.0 and 2.0. By 2026 it shows up in small OCaml-leaning full-stack companies. Tarides ships some internal tools on Melange, and Ahrefs (originally an OCaml shop) is experimenting with Melange-based parts of its frontend.
10. Reason — Facebook's Syntax
Reason was created in 2017 by Jordan Walke at Facebook (the creator of React). The core idea: **the OCaml semantics are great but the syntax feels foreign to JavaScript developers, so keep the semantics and rewrite the surface to feel JS-like**.
Reason example:
/* Reason syntax */
let greet = (name) => {
let msg = "Hello, " ++ name ++ "!";
Js.log(msg);
};
let () = greet("Reason");
The OCaml equivalent:
(* OCaml syntax — same semantics *)
let greet name =
let msg = "Hello, " ^ name ^ "!" in
Js.log msg
let () = greet "Reason"
Reason compiles to OCaml, and OCaml in turn compiles to JS via BuckleScript or Melange. The flow is Reason then OCaml AST then JS.
Reason was adopted quickly inside Facebook between 2017 and 2020. Then BuckleScript split into ReScript in 2020 and Reason's position wobbled — ReScript picked its own syntax, leaving Reason between two stools. Facebook gradually pulled back.
Reason in 2026:
- **Still works as an OCaml frontend**: the compiler is alive and Dune supports it
- **Melange can use Reason syntax**: some Melange users still author in Reason
- **Few new adoptions**: most people pick ReScript or plain OCaml
Reason is not dead but it is past its peak. For a fresh project, Melange plus plain OCaml syntax is the sensible default.
11. Eio — Effect-Based Concurrency (Multicore)
Eio is the new concurrency / IO library built on top of OCaml 5's effect handlers. It has been under development since 2022 by Cambridge OCaml Labs and Tarides. In 2026 it sits just before its 1.0 — versions around Eio 0.17 are in production use.
Eio's design:
- **Effect-based**: no `async` or `await` keywords. Functions look ordinary and yield or resume via effects
- **Structured concurrency**: fibers spawned inside a `Switch` are all cleaned up when the switch closes, matching the Trio and Kotlin Coroutines philosophy
- **Multicore-friendly**: domain pools schedule fibers across domains, so CPU-bound work runs in real parallel
- **Backend abstraction**: `Eio_main.run` picks the right OS backend (io_uring on Linux, kqueue on macOS, IOCP on Windows)
open Eio.Std
let fetch url =
traceln "fetching %s" url;
Eio.Time.sleep (Eio.Stdenv.clock env) 1.0;
url ^ " — done"
let () =
Eio_main.run @@ fun env ->
Switch.run @@ fun sw ->
let a = Fiber.fork_promise ~sw (fun () -> fetch "https://a.example.com") in
let b = Fiber.fork_promise ~sw (fun () -> fetch "https://b.example.com") in
traceln "%s" (Promise.await_exn a);
traceln "%s" (Promise.await_exn b)
Eio strengths:
- **Explicit IO capability passing**: `env` carries the right IO capabilities, so arbitrary functions cannot do arbitrary IO. This helps both security and testability
- **First-class cancellation**: fiber cancellation has a clean definition, fixing a long-standing Lwt weakness
- **Multicore-aware**: Lwt is single-domain, while Eio distributes fibers across domains
Weaknesses:
- **Pre-1.0**: APIs may still break, with 1.0 expected in late 2026
- **Smaller ecosystem**: Cohttp-eio, Dream-eio, and friends are growing but not yet at Lwt's scale
- **Effect debugging**: tracing effect handler chains takes getting used to
In a 2025 Tarides benchmark, Eio plus multicore matched Tokio (Rust async) on throughput on the same hardware. That was the moment OCaml became plausibly competitive on single-node IO-heavy workloads again.
12. Lwt — The Older Concurrency
Lwt (Light-weight threads) is the classic OCaml concurrency library, built in 2003 by Jérôme Vouillon. It runs on a single-threaded event loop and composes promises (`'a Lwt.t`). The model is almost identical to JavaScript's Promise.
open Lwt.Syntax
let fetch url =
let* () = Lwt_unix.sleep 1.0 in
Lwt.return (url ^ " — done")
let () =
Lwt_main.run
(let* a = fetch "https://a.example.com" in
let* b = fetch "https://b.example.com" in
Lwt_io.printlf "%s / %s" a b)
Lwt strengths:
- **Maturity**: more than twenty years in service. Almost every OCaml network / IO library has an Lwt flavor (cohttp-lwt, irmin-lwt, and so on)
- **Single-threaded simplicity**: no race conditions, the same mental model as JS async
- **Protocol coverage**: TLS, SSH, HTTP/2, and effectively every protocol you might need
Weaknesses:
- **Single domain**: no real multicore use. CPU-bound work has to be split into separate processes
- **`promise.bind` overhead**: even with `let%lwt` or `let*` PPXes, the binding is still explicit
- **Weak cancellation**: the semantics of cancellation are not crisp. Eio fixes this
In 2026, Lwt is **legacy plus stability** and Eio is **new plus multicore**. New projects look at Eio, but existing production systems (Tezos, parts of Mirage) are still Lwt-bound and are migrating gradually.
**Async** (Jane Street): Jane Street's internal concurrency library, also promise-based like Lwt but on a separate codebase. Treat it as a Jane-Street-ecosystem-only option in practice.
13. Cohttp / Dream — HTTP / Web
Cohttp is the default OCaml HTTP library, started by Anil Madhavapeddy and a core piece of MirageOS. It ships Lwt, Async, and Eio backends.
open Lwt.Syntax
open Cohttp_lwt_unix
let server =
let callback _conn req _body =
let uri = Cohttp.Request.uri req in
Server.respond_string ~status:`OK
~body:(Printf.sprintf "you hit %s" (Uri.path uri)) ()
in
Server.create ~mode:(`TCP (`Port 8080)) (Server.make ~callback ())
let () = Lwt_main.run server
Cohttp is low-level. Routing, middleware, and templating you have to assemble yourself. That gap is what **Dream** fills.
Dream was created in 2021 by Anton Bachin. Its philosophy is "OCaml's Rails or Flask." A single file can hold routing, middleware, templating, WebSockets, and sessions.
let () =
Dream.run
@@ Dream.logger
@@ Dream.router [
Dream.get "/" (fun _ -> Dream.html "Hello Dream!");
Dream.get "/users/:id" (fun req ->
let id = Dream.param req "id" in
Dream.html (Printf.sprintf "user %s" id));
Dream.post "/login" (fun req ->
let%lwt body = Dream.body req in
Dream.html (Printf.sprintf "got %s" body));
]
Dream features:
- **Single-file start**: a small demo fits in 50 lines, full stack
- **WebSocket and SSE first class**: both ship in the core
- **Sessions, CSRF, cookies**: secure defaults included
- **Templates baked in**: `dream-eml` for HTML templates
- **Lwt-based**: still Lwt in 2026, with an Eio port in progress
Alternative web frameworks: **Opium** (Sinatra-like, light), **Httpaf** (low-level high-performance HTTP/1.1), **H2** (HTTP/2 implementation).
In 2026 the OCaml-web default is **Dream plus Cohttp-lwt** (or **Dream plus Eio** once the port lands). For small microservices, Opium is a solid pick.
14. Tezos (XTZ) — The Blockchain Written in OCaml
Tezos is a Proof-of-Stake blockchain that launched mainnet in 2018. Both the consensus layer and the node are written in OCaml, and in 2026 XTZ sits roughly inside the top-30 by market cap.
Tezos is written in OCaml for a clear reason: **on-chain governance automatically applies protocol amendments**. Stakeholders vote on a proposed protocol, and if it passes, every node pulls in the new code and activates it. That mechanism demands **type safety and amenability to formal proofs**, and OCaml is the industrial language that supports both best.
Tezos node structure:
- **Shell**: the node proper. P2P, mempool, and RPC, all on Lwt
- **Protocol**: consensus, governance, and smart-contract semantics. Functorized so amendments can replace it cleanly
- **Michelson**: the smart-contract VM. Stack-based, strongly typed, written in OCaml
- **Storage**: Irmin, a Git-like content-addressable store written in OCaml
(* Tezos snippet — Michelson interpreter excerpt *)
let step_instr (instr : ('bef, 'aft) Script.instr) (stack : 'bef stack) :
'aft stack tzresult Lwt.t =
match instr, stack with
| Add_int, Item (Int a, Item (Int b, rest)) ->
return (Item (Int (Z.add a b), rest))
| Push (ty, v), rest ->
return (Item (Cast.cast ty v, rest))
| _ -> fail Bad_stack
The Tezos ecosystem is OCaml's largest industrial deployment. Companies like **Nomadic Labs**, **Marigold**, **Tarides**, and **TriliTech** contribute to core development, all hiring full-time OCaml.
Between 2024 and 2025 Tezos evolved through **Adaptive Issuance** (dynamic inflation), **Smart Rollups** (Layer 2), and a **Data Availability Layer**. The 2026 line is **Quebec then Rio then Seoul**. The protocol amendment story is one of the most cited industrial examples of using OCaml's module system to the full.
15. Hack (Meta) / Flow (Meta) / Async (Jane Street) — Industry
**Hack** (Meta): A PHP descendant with gradual typing, generics, and async, open-sourced in 2014. Internally, much of Facebook's backend still runs on it. **The compiler and type checker are written in OCaml**. HHVM (the VM) is C++, but the typechecker, parts of the interpreter, and the static analyses are OCaml.
**Flow** (Meta): A JavaScript static type checker, also opened in 2014. Through the late 2010s it competed with TypeScript and lost on adoption, but inside Meta a lot of JS still runs through Flow. **Flow is also written in OCaml**. External adoption is small in 2026, but internally it lives on.
**Async** (Jane Street): Jane Street's in-house OCaml concurrency library. Promise-based like Lwt but a separate implementation. `Deferred.t` plays the role of Lwt's `'a Lwt.t`. The entire Jane Street codebase rides on Async.
open Core
open Async
let fetch url =
let%bind () = Clock.after (Time_float.Span.of_sec 1.0) in
return (url ^ " — done")
let main () =
let%bind a = fetch "https://a.example.com" in
let%bind b = fetch "https://b.example.com" in
printf "%s / %s\n" a b;
return ()
let () =
Command.async ~summary:"demo"
(Command.Param.return main)
|> Command_unix.run
All three demonstrate **that OCaml runs in real industrial production**. Hack carries Meta's traffic, Flow type-checks Meta's internal JS, and Async drives Jane Street's trading systems.
16. Jane Street — The Largest OCaml Shop
Jane Street, founded in 2000, is a quantitative trading firm headquartered in New York. By 2026 it has roughly 3,000 employees and more than 1,500 engineers. **It is the world's largest OCaml employer**.
Jane Street's OCaml codebase is estimated at around **25 million lines**. Trading systems, back office, data pipelines, internal tools — almost everything is OCaml. The shop uses other languages (C++, Python, Java) but the share is small.
Jane Street's open-source contributions:
- **Dune**: the build system (covered above)
- **Core**: an alternative standard library, richer and more consistent than OCaml's stdlib
- **Async**: the concurrency library
- **ppx_jane**: a PPX metaprogramming collection (deriving, expect tests, sexp, and so on)
- **Bonsai**: a React-like OCaml frontend framework based on incremental computation
- **Magic Trace**: an Intel PT-based backtrace visualization tool
- **Memtrace**: a memory profiler
(* Jane Street style — Core plus ppx_jane *)
open Core
let%test_unit "list sum" =
[%test_eq: int] (List.fold ~init:0 ~f:(+) [1; 2; 3]) 6
type point = { x: float; y: float }
[@@deriving sexp, compare, equal, fields]
let () =
let p = { x = 1.0; y = 2.0 } in
printf !"%{sexp: point}\n" p
Jane Street's hiring culture:
- **You can join without knowing OCaml**: the firm teaches it after you arrive, and runs OCaml bootcamps for interns and new hires
- **Interns at scale**: more than 200 interns per year, recruited heavily from MIT, CMU, Princeton, Harvard, and Stanford
- **Famously high compensation**: 500K to 1M dollar new-grad packages are commonly reported
Jane Street is OCaml's single largest patron and the decisive reason OCaml is treated seriously by industry. There is a running joke that if Jane Street dropped OCaml, more than half of the funding and people would vanish overnight.
17. Korea / Japan — KAIST PL Lab, Kyoto University PL Lab
OCaml is stronger in academia than in industry, especially in Programming Languages labs where it is a core working tool.
**Korea — KAIST PL lab**:
- **KAIST Programming Languages Laboratory** (Kwangkeun Yi and others): static analysis, abstract interpretation, and formal verification, with tools built in OCaml. Outputs include the Sparrow analyzer
- **SNU PL lab** (Chung-Kil Hur and others): compiler verification (building on CompCert), and Coq / Rocq plus OCaml for formal proofs
- **POSTECH** (Sungwoo Kang and others): type-systems and effect-type work
- **Korean industrial OCaml hiring**: nearly nonexistent. There is no Jane Street office in Korea, but a handful of Korean engineers work remotely
**Japan — Kyoto University / Tokyo Tech**:
- **Kyoto University PL lab** (Atsushi Igarashi group): type theory, dependent types, and gradual typing, all using OCaml tooling
- **Tokyo Tech** (Tokyo Institute of Technology, now Institute of Science Tokyo): functional programming and model checking, with OCaml as the standard tool
- **University of Tokyo IPL**: PL and SE research using Coq / Rocq plus OCaml
- **Japanese industrial OCaml hiring**: very small. Ahrefs (analytics SaaS, originally an OCaml shop) hires remotely from Japan, and some experimental usage exists at Mercari
Academia's continued use rests on two reasons. First, the ML family is the lingua franca of PL research. Second, formal-verification tools like Rocq, F*, Why3, and Cubicle are written in OCaml. A PL PhD in Korea or Japan more or less requires OCaml fluency.
18. Who Should Learn OCaml — FP / Verification / Compilers
In 2026 OCaml is not a language for everyone. The job market is narrow (especially in Korea), and the library ecosystem is smaller than JavaScript's or Python's. Even so, **some groups should absolutely learn OCaml**.
**1) PL and formal-verification researchers**: If your PhD is in PL, OCaml is mandatory. Rocq, F*, Why3, CompCert, Tezos — they are all written in OCaml, and most papers at POPL, PLDI, and ICFP are implemented in OCaml.
**2) Compiler engineers**: OCaml is the standard language for writing compilers. Pattern matching, algebraic data types, and the module system are ideal for ASTs. Parts of the Rust and Haskell compilers also drew on OCaml.
**3) People aiming at Jane Street, Tarides, or Tezos**: If you want to work at these companies, learn OCaml. You can pick it up after joining, but knowing it ahead helps the interview. Jane Street's intern program specifically runs an OCaml bootcamp and tests on it.
**4) Functional newcomers who find Haskell heavy**: OCaml is strict and has no implicit type classes. Compared to Haskell it is closer to "functional but ordinary." A great entry to the ML family. The only catch is that Korean and Japanese learning materials are richer for Haskell than for OCaml.
**5) Developers interested in formal verification, compiler verification, or static analysis**: Even outside academia, if you want to build a static analyzer, an interpreter, or a domain-specific language, OCaml is a fitting tool.
**Who can safely skip OCaml**:
- General backend or web development (Go, TypeScript, or Python is more reasonable)
- Mobile (Swift, Kotlin)
- Machine learning (Python plus Rust)
- Anyone targeting an OCaml job inside Korea — the market is effectively zero. Academia or a remote foreign company is the answer
Suggested learning path:
1. **Real World OCaml, 2nd ed** (Anil Madhavapeddy, Yaron Minsky, Jason Hickey) — free online, targeted at OCaml 4.13 but largely applicable to 5.x
2. **OCaml.org tutorials** — the official path, 5.x-ready
3. **Cornell CS 3110** (Michael Clarkson) — free lecture notes, the de facto undergraduate PL textbook
4. **Effects Unleashed** (Tarides blog series) — Eio plus effect handlers in depth
5. **Jane Street Tech Blog** — production case studies
19. References
- [OCaml.org](https://ocaml.org/) — official site
- [OCaml 5.3 release notes](https://github.com/ocaml/ocaml/releases) — GitHub release notes
- [Multicore OCaml](https://github.com/ocaml-multicore) — multicore project
- [Effect Handlers in OCaml 5](https://kcsrk.info/) — KC Sivaramakrishnan's blog
- [Dune docs](https://dune.readthedocs.io/) — official build-system docs
- [Opam](https://opam.ocaml.org/) — the package manager
- [opam-repository](https://github.com/ocaml/opam-repository) — the public package set
- [Diskuv OCaml](https://diskuv.com/) — Windows-native OCaml
- [MirageOS](https://mirage.io/) — unikernel project
- [Robur](https://robur.coop/) — MirageOS operations nonprofit
- [Tarides](https://tarides.com/) — OCaml consultancy (MirageOS, Tezos, Eio)
- [js_of_ocaml](https://ocsigen.org/js_of_ocaml/latest/manual/overview) — OCaml-to-JS compiler
- [ReScript](https://rescript-lang.org/) — Hongbo Zhang's OCaml-derived JS language
- [Melange](https://melange.re/) — pulling the ReScript compiler back into OCaml
- [Reason](https://reasonml.github.io/) — Facebook's OCaml syntax
- [Eio](https://github.com/ocaml-multicore/eio) — effect-based IO
- [Lwt](https://ocsigen.org/lwt/latest/manual/manual) — classic OCaml concurrency
- [Cohttp](https://github.com/mirage/ocaml-cohttp) — HTTP library
- [Dream](https://aantron.github.io/dream/) — OCaml web framework
- [Tezos](https://tezos.com/) — OCaml-based PoS blockchain
- [Nomadic Labs](https://www.nomadic-labs.com/) — Tezos core
- [TriliTech](https://trili.tech/) — Tezos / Etherlink development
- [Hack](https://hacklang.org/) — Meta's PHP successor (OCaml-based tooling)
- [Flow](https://flow.org/) — Meta's JS type checker (OCaml)
- [Jane Street](https://www.janestreet.com/) — largest OCaml employer
- [Jane Street Tech Blog](https://blog.janestreet.com/) — production case studies
- [Real World OCaml](https://dev.realworldocaml.org/) — 2nd edition, free online
- [Cornell CS 3110](https://cs3110.github.io/textbook/) — Michael Clarkson's notes
- [KAIST PL Lab](https://prl.kaist.ac.kr/) — Korean PL research
- [Kyoto University Igarashi Lab](https://www.fos.kuis.kyoto-u.ac.jp/) — Kyoto University PL research
현재 단락 (1/425)
This post is **a single-shot map of the OCaml ecosystem as of May 2026**. When OCaml 5.0 brought mul...