A better build system for OCaml

Original Article ↗ Hacker News Discussion ↗

Naming, theme, and culture around Dune

  • Many commenters like “Dune” as a build-system name and enjoy the Dune‑novel references (including the humorous crash message).
  • Some joke about alternative names like “spice” and about the “shifting sands” nature of software builds.

Functional languages in production

  • OCaml at Jane Street is cited as strong evidence that HM‑typed functional languages can be fast and production‑ready, including for latency‑sensitive finance.
  • Other production uses mentioned: Haskell (e.g., internal tools, rules engines, analysis systems), F#, Elm, and various niche languages like Mercury.
  • Debate over purity: several argue that Haskell’s enforced purity is a barrier to mainstream adoption, while OCaml’s impure but functional style feels more practical.

Why build Dune instead of using Bazel/Buck2

  • Timeline is clarified: an internal system (Jenga, 2012) came first, then Jbuilder (2016) as a simpler, cross‑platform shim, later renamed Dune.
  • At the time Jenga was created, Bazel/Buck didn’t exist; later, Dune’s key goal was compatibility with existing OCaml build descriptions, not replacing them with Bazel/Buck.
  • Some note that OCaml’s dependency model (e.g., ocamldep) needs special handling; Buck2 reportedly supports this better than Bazel, but integration is still tricky.

Experience with Dune and OCaml tooling

  • Many OCaml users treat Dune as the default and praise its LSP integration and speed, especially versus dual systems (e.g., Dune + Buck2).
  • Others, especially distro packagers, criticize Dune’s own configuration syntax as yet another bespoke system that’s hard to patch and awkward for multi‑language builds.
  • Newcomers from Rust complain that OCaml tooling feels weaker: LSP often requires explicit dune build, new files aren’t picked up automatically, and error messages are less polished.
  • Some still prefer ocamlbuild or Make for simplicity, despite their own quirks.

Build systems and packaging, generally

  • Strong dislike expressed for CMake’s custom language, though some defend it as the only broadly workable cross‑platform option; Meson and xmake get mixed reviews.
  • Broader argument: language‑specific build systems are winning in most ecosystems, while traditional distro build systems (e.g., RPM spec, autotools) are seen by some as outdated and ill‑suited to modern dependency graphs.
  • Counter‑view from a Fedora packager: distro‑level systems are necessary to integrate multiple languages and maintain coherent, cross‑language packaging.

Jane Street libraries and ecosystem

  • Mixed impressions of Jane Street’s open‑sourced OCaml libraries and tools:
    • Positives: rich stdlib replacement, powerful PPX tooling, advanced data structures, generally high code quality.
    • Negatives: some tools “just don’t work” outside Jane Street, with undocumented dependencies or hidden configuration; fixes may take a long time.
  • Overall readiness for external users is seen as uneven and somewhat unclear.

Jane Street, work, and ethics

  • Several commenters speculate that working on OCaml and build systems at a high‑frequency firm is more fun and technically rewarding than most “tech” jobs.
  • Others emphasize the downsides: long hours, intense standards, elitist culture, and morally ambiguous value to society (“moving money faster” vs. solving broader problems).
  • There’s tension between admiration for the technical output (like Dune) and discomfort with the broader finance context.