OCaml Syntax Sucks (2016)

Original Article ↗ Hacker News Discussion ↗

Overall view of OCaml syntax

  • Many find the article’s example misleading; any language can look awful if everything is crammed into one line.
  • Several argue let … in is natural and makes scoping explicit and easy to reason about.
  • Others say OCaml syntax does have problems, but not the ones in the article: main complaints are confusing precedence between let, if, match, fun, and ;, and hard‑to‑trace errors when in is omitted.

Real pain points: matches, errors, and dev UX

  • Repeated criticism that match has no explicit terminator, making nested matches easy to get wrong and producing poor error messages (“the rest of the file is broken”).
  • Error reporting in general is seen as weak, especially for beginners; syntax errors often point at the end of the file.
  • Autoformatting, LSP integration, extra parentheses / begin…end are widely recommended as mitigations.
  • Overall dev experience is polarizing: some advise avoiding OCaml entirely, others describe it as one of their most pleasant professional languages.

Arguments in favor of OCaml’s design

  • Praise for:
    • Whitespace‑insensitive syntax combined with a formatter.
    • Low punctuation density and ergonomic typing.
    • Clear scoping rules (look “upward” for definitions, three core concepts: values, types, modules).
    • Fast compiler, separate compilation, and sane defaults with accessible “escape hatches”.
  • Some like .mli interface files as clean, documentation‑friendly API surfaces, despite their different syntax.

Async, computation expressions, and effects

  • OCaml’s async via libraries (no special language support) is framed as a design strength, similar to Rust/Haskell/Clojure ecosystems.
  • In F#, computation expressions (task {}, async {}, seq {}) spark debate:
    • Pro: powerful, generic abstraction (beyond async), useful for many computational patterns.
    • Con: ugly “sub‑syntax”, high cognitive load when much code is async; preference from some for integrated syntax like async/await.
  • OCaml 5 + effects and structured concurrency are mentioned as promising for direct‑style async.

Ecosystem splits and alternatives

  • Confusion and frustration around the split between OCaml’s stdlib and Jane Street’s Core/Base; many online answers assume Core and have sparse docs.
  • ReasonML, ReScript, and Melange are discussed as alternative syntaxes/targets; perceptions range from “useful bridge to OCaml” to “unappealing JS‑like skin”.
  • Alternatives suggested for similar niches: F#, Scala, Gleam, Standard ML.

Meta and ergonomics

  • Some see low punctuation as readable; others argue it harms “visual parsing” compared to C‑like languages.
  • International keyboard issues with certain ASCII symbols (e.g., backticks) are raised.
  • A side thread proposes HN should discourage non‑HTTPS links; others question the practical threat model.