OCaml as my primary language

Original Article ↗ Hacker News Discussion ↗

OCaml vs F# and other MLs

  • Several commenters say if they wanted OCaml they’d pick F# instead (better ecosystem, .NET interop, GUI libraries, Avalonia.FuncUI).
  • Counterpoint: F# tooling (Ionide, Fantomas, MSBuild) is brittle; OCaml is actually the refuge from F# for some.
  • Language‑feature comparisons: OCaml has native GADTs; F# can “hack them up” with equality witnesses but can’t match full power (no refutable unreachable branches).
  • Modules/functors are cited as a major OCaml advantage for coarse‑grained generics; F# lacks HKTs and has weaker module‑level abstraction.

Tooling, Debugging, and Package Management

  • Common complaint: OCaml has good language but rough tooling, especially debugging and opam.
  • Others push back: OCaml LSP is “okay and improving,” with long‑standing completion; DAP + bytecode debugger (ocamlearlybird) works; native debugging is harder due to DWARF limitations.
  • OCaml ships with a reverse debugger, but UX and VS Code integration are seen as clunky.
  • opam is described by some as fragile and non‑reproducible (broken installs, removed versions); others report years of smooth use and point to opam lock/pin and dune’s lockdir.
  • Dune is evolving towards its own package management to address opam issues.

Sum Types vs Sealed Hierarchies

  • Long, heated debate on whether Java/Kotlin/C# sealed hierarchies are “real” sum types.
  • One side: sealed classes fully model sums and add useful subtyping (e.g., “function never returns Point” as a type), with compiler‑checked exhaustiveness.
  • Other side: cases-as-types weaken exhaustiveness guarantees and blur algebraic structure; ML‑style variants + pattern matching stay simpler and more disposable.
  • OCaml alternatives (GADTs, polymorphic variants, modules) can encode many of the “sum as subtyping” patterns, but at cost of complexity.

Functional Languages and LLMs

  • Speculation: denser FP code (OCaml/Haskell) might better fit LLM context windows.
  • Experiences vary: some find terseness hurts LLMs’ ability to “self‑correct”; verbose languages like Go often get better generations.
  • Strong static types and good LSP support are seen as more helpful than brevity; type errors and property‑based tests can drive iterative LLM refinement.
  • Immutability/purity may align well with LLMs’ limited global context by reducing side‑effect reasoning.

OCaml vs Rust, Scala, Kotlin, etc.

  • Multiple reports of migrating OCaml → Rust: Rust is less elegant but has far stronger tooling, ecosystem, and performance (2–5× speedups in some rewrites, especially parsing/ETL).
  • Several argue Rust’s real draw is ML‑style ADTs and pattern matching plus modern tooling; borrow checking is a bonus, and many would accept a Rust‑with‑GC.
  • View that OCaml “could have been Rust” if multicore and ergonomics had arrived ~2010; others say Rust’s “no‑GC but safe and fast” niche is unique and decisive.
  • Scala, Kotlin, F#, and even Java/C# with sealed types are discussed as carrying many “OCaml‑like” ideas into mainstream ecosystems.

Syntax, Ergonomics, and Ecosystem Gaps

  • Some love OCaml’s syntax once learned; others find let ... in, double semicolons, and record quirks off‑putting. ReasonML’s alternative syntax had fans but seems to have fizzled.
  • Ecosystem complaints: weak desktop GUI story, sparse high‑level web/database tooling (manual SQL strings, hand‑rolled auth), poor Windows experience, and thin documentation.
  • Fans praise how the type system and modules make refactoring safe and keep business logic small and composable, but concede you often end up building more plumbing yourself.

Effects, Modules, and Dependency Injection

  • New algebraic effects and handlers are highlighted as a modern strength (e.g., DI via effect handlers, test vs prod interpreters).
  • Some compare this to Haskell patterns (free monads, tagless final) but note OCaml’s effect system still isn’t tracked in types.
  • Overall sentiment: OCaml’s core language, modules, and effects are highly admired; hesitations center on tooling, ecosystem maturity, and fit for “mainstream” product work.