OxCaml - a set of extensions to the OCaml programming language.

Original Article ↗ Hacker News Discussion ↗

Language features & labeled tuples

  • OxCaml has already upstreamed features to OCaml 5.4, notably labeled tuples and immutable arrays (with adjusted syntax).
  • A major discussion centers on anonymous labeled structs/records vs plain tuples:
    • Pro side: better readability than bare tuples (no more “what does this usize mean?”), convenient ad-hoc return types with named fields.
    • Skeptic side: if the meaning isn’t “random”, a named newtype is clearer; documentation and strong nominal types already solve many issues.
  • Examples from other languages:
    • Rust lacks anonymous labeled structs as return values.
    • Dart unifies tuples and records with mixed positional/named fields, with some syntactic quirks.
    • F# anonymous records and OCaml records are compared; anonymous records don’t need prior type declarations.
  • There is debate over order-independence and structural typing:
    • Some prefer fully order-independent anonymous records.
    • Others note labeled tuples are “effectively” order-independent at call-sites, but internal representation and FFI constraints limit arbitrary reordering.

“Oxidizing” OCaml vs Rust

  • “Oxidized” here means bringing Rust-like guarantees (e.g. safer memory, fearless concurrency, reduced GC reliance) into OCaml, not embedding Rust.
  • One view: Rust will likely gain flexible GC tooling sooner than OxCaml reaches parity, so the value is unclear.
  • Counterview: extensions greatly benefit existing OCaml codebases; OxCaml encodes locality/modality differently from Rust, aiming for a cleaner, pay-as-you-go integration rather than overloading the core type system.

GC, low latency, and trading

  • Thread discusses using a GC language for ultra-low-latency systems like high-frequency trading:
    • Strategies include disabling GC during market hours, designing systems to avoid allocations after startup, overprovisioning RAM, or running GC when markets are closed.
    • Others highlight drawbacks of unchecked allocation (poor locality, pointer chasing) and suggest struct-of-arrays / vector-style designs and zero-allocation “kernels”.
    • Parallel/real-time GCs and overprovisioned server pools are mentioned as general approaches (not OCaml-specific).

Performance extensions: SIMD and platform support

  • OxCaml adds SIMD, unboxed types, and explicit stack allocation, which some see as making it viable for gamedev/consumer software.
  • Current status:
    • Working 128-bit SSE and NEON; AVX is “coming soon”.
    • ARM SIMD works at the compiler level, but lacks a dedicated NEON intrinsics library.
    • No fundamental blockers for Windows support; a partial Windows port exists but needs further work.

Tooling & editor experience

  • Users share opam/OCAMLPARAM tips to avoid new alerts breaking package installs.
  • A patched Merlin plus ocaml-lsp-server generally works with VS Code’s OCaml extension if the OxCaml switch is selected.
  • Some report LSP features (errors, formatting) failing after editor restart, even with correct configuration; causes remain unclear in the thread.

Language choice, sunk cost, and alternatives

  • Strong disagreement over whether heavy continued investment in OCaml/OxCaml is a “sunk cost fallacy” or a proven advantage:
    • Critics argue OCaml’s niche status shrinks the hiring pool and that its syntax/semantics are unappealing.
    • Defenders claim OCaml has been a major success factor, both technically and as a filter attracting certain kinds of developers, and that migrating away would be risky and low-value.
  • Broader comparisons:
    • Some see Rust as a “poor man’s OCaml”; others strongly prefer F# or find OCaml “esoteric”.
    • Several comments list GC languages with stronger low-level “knobs” (stack allocation, value types, unsafe features), arguing GC per se isn’t the core problem.
    • F# is discussed both as a softer, more modern-feeling ML and as constrained by .NET and C# design decisions; Fable and possible WASM targets are mentioned but seen as going in a different direction than OxCaml.

LLMs and release motives

  • One person speculates that OxCaml’s openness might be to feed LLM training so public models can handle it.
  • Responses push back, noting models are already weak at minority languages like OCaml/Gleam, and that the signal is too small; an explicit docs API would be more relevant for such a goal.