Developers just released a new C++ backend for OCaml’s ocamlc compiler. It spits out standard C++11 code from OCaml source, letting you build binaries with tools like clang++ or g++. No more wrestling with OCaml’s native assembly backend or LLVM dependencies. This lands at a time when OCaml 5.0 emphasizes multicore and effects, but integration hurdles persist in C++-heavy worlds like finance and crypto trading systems.
The backend, from Samuel Grütter and contributors, lives on GitHub at samgrutte/ocamlc-cpp. You compile OCaml files with ocamlc -output-obj -o foo.cpp foo.ml, then link via C++:
$ clang++ -std=c++11 -O3 -I ocamlc-cpp/include foo.cpp ocamlc-cpp/runtime.o -lpthread -ldl -o fooIt handles OCaml staples: algebraic data types become structs with variants, closures as lambdas, pattern matching via switch statements. The runtime includes a Boehm-Demers-Weiser GC interface, tuned for C++.
Performance Reality Check
Benchmarks tell the story. On the OCaml polybench suite, the C++ backend hits 80-110% of ocamlopt‘s speed—close enough for most workloads. For example, the crypto bench (AES encryption) runs at 95% of native speed; md5 at 102%; sieve lags at 82%. No LLVM bloat means smaller binaries: a hello world drops from 1.2MB (ocamlopt) to 200KB. Multicore? It supports domains from OCaml 5, but effects land in 5.1—test thoroughly.
Skeptical lens: This isn’t production-ready everywhere. Linux and macOS work with GCC 11+ and Clang 14+. Windows? Not yet; MSVC integration pending. Debug info is basic—no source-level stepping in GDB without tweaks. GC pauses mirror OCaml’s, so high-frequency trading bots might need custom allocators. Compared to GraalVM Native Image or WebAssembly via Multicore OCaml, it’s narrower but toolchain-agnostic.
Why This Actually Matters
OCaml shines in high-stakes code: Jane Street runs billions in trades on it; LexiFi verifies derivatives; Tarides builds space software. But C++ dominates perf-critical stacks—think quant funds with proprietary engines or crypto exchanges crunching order books. FFI via ctypes works, but it’s glue code hell: manual marshalling, segfault roulette.
This backend flips that. Drop OCaml modules into C++ projects seamlessly. Need OCaml’s type safety for a matching engine? Compile to .cpp, link with your C++ FIX parser or RocksDB store. In crypto, prototype smart contract verifiers in OCaml, embed in C++ nodes. Security angle: OCaml’s memory safety reduces vulns; C++ output lets auditors use familiar tools. No hype—it’s 300 lines of runtime, hackable.
Broader context: OCaml’s compiler historically split ocamlc (bytecode) and ocamlopt (native assembly). Flambda 0.68 and 1.x optimize relentlessly, but backend lock-in limits ports. js_of_ocaml hits JS; MulticoreB2Wasm does WASM. C++ backend democratizes native targets—Android NDK? Raspberry Pi? Compile once, toolchain everywhere. Maintainers promise upstreaming to OCaml 5.2; watch the discuss.ocaml.org thread for traction.
Risks remain. Adoption hinges on ecosystem buy-in. Dune build system integration? OPAM packages? Early days. If you’re greenfield, stick to ocamlopt. Brownfield C++ monolith? Prototype now. In tech/finance/crypto, where every latency tick costs, this bridges two worlds without compromise. Test it: clone, build cryptokit, clock it against native. Numbers don’t lie.
