8 months of OCaml after 8 years of Haskell in production (2023)

Language philosophy and productivity

• Many see OCaml as more pragmatic: fewer advanced type features, easier to “just build stuff,” less temptation to over‑abstract.
• Haskell is described as powerful but “nerd‑sniping,” encouraging perfectionism and type‑level wizardry that can slow delivery.
• Some argue this is more about team discipline and extension policies than the language itself (e.g., “Simple Haskell” guidelines).

Syntax, readability, and style

• Strong split: some find Haskell’s terse, compositional style beautiful; others find it cryptic and puzzle‑like, especially point‑free code and custom operators.
• OCaml syntax is often perceived as more approachable, though some find it too “barebones” or visually dense.
• Several argue that “everything is hard to read until you learn to read it,” but others counter that high density genuinely raises cognitive load in large codebases.

Purity, side effects, and reasoning

• Advocates highlight referential transparency: if a function passes in tests, it behaves identically in production, greatly simplifying reasoning.
• Critics note Haskell isn’t “pure” in every practical sense (non‑termination, unsafe primitives, trace), but agree that explicit IO types make side effects visible.
• OCaml’s implicit side effects and mutation are seen as both a practical advantage and a source of more potential runtime bugs.

Type systems, modules, and extensions

• Haskell’s type system is praised as more expressive (type families, DataKinds, etc.), but this power can lead to deep, opaque errors and wildly varying code styles.
• OCaml’s module system and first‑class modules are viewed as strong for “programming in the large,” though functor‑heavy code can also get complex.
• Several emphasize strict control of Haskell language extensions and use of editions (e.g., GHC2024) in production.

Tooling, libraries, and ergonomics

• OCaml tooling (dune, editor integration) is often reported as “just works,” including on non‑Windows platforms.
• Haskell tooling is described as baroque and version‑fragile; HLS and dependency hell are recurring pain points.
• Both languages are criticized for thin standard libraries (string conversions, collections), though Haskell’s containers is effectively bundled.
• Library ecosystem gaps (e.g., Stripe/GitHub SDKs) are noted; some argue generating bespoke clients in OCaml is feasible and preferable to heavyweight third‑party SDKs.

Performance and niches

• OCaml is remembered as often “close to C” when written carefully; Haskell can match C in some cases but may require more work on strictness and data structures.
• Both appear well‑suited to compilers, interpreters, and finance/trading systems; some see OCaml as better aligned with that niche and Haskell as more of an advanced research/teaching language that can be used in production with discipline.