We chose OCaml to write Stategraph

Original Article ↗ Hacker News Discussion ↗

Stategraph’s Problem & Terraform Workflows

  • Several commenters question the need: many orgs simply serialize Terraform applies with locks or CI, and don’t see race conditions as their main pain.
  • Others report very long plan/apply times (tens of minutes to a day) and serious lock contention, especially across time zones.
  • Current workaround is splitting large infrastructures into many root modules; this is seen as a costly refactor and a workflow shift.
  • Stategraph’s pitch: keep a single large state, but compute resource-level dependencies so non-overlapping changes can plan/apply in parallel, removing contention without restructuring modules.

Target Users and Alternatives

  • Some infra teams prefer splitting stacks by design, or are moving toward Kubernetes operators and away from Terraform for frequently changing infra.
  • For these users, Terraform variable management and multi-cell configuration are bigger issues than state locks.
  • Others say Stategraph offers a “third option” for large, slow Terraform estates: no refactor, less waiting.

Why OCaml? Comparisons to TypeScript, Rust, Haskell, Scala

  • Discussion centers on whether OCaml offers anything unique versus “any strongly typed language,” especially TypeScript.
  • Arguments for OCaml:
    • Sound, expressive type system (sum types, strong inference) versus TypeScript’s intentional unsoundness and weaker guarantees.
    • Native compilation with fast, predictable performance and GC; no need for JS+JIT workarounds.
    • Immutability-by-default style and modern concurrency (OCaml 5) that fit Stategraph’s correctness needs.
    • Powerful module system and PPX tooling for codegen (e.g., JSON, SQL).
  • Rust is seen as overkill here: borrow checker and bare-metal perf aren’t needed; GC + immutability is “good enough” with less friction.
  • Haskell is praised for STM but criticized as less pragmatic (laziness, pervasive monads, slower compiles).
  • Scala is said to offer similar advantages but has community/fragmentation issues and some see Scala 2 as “dying,” Scala 3 as immature.

Functional Programming, Concurrency, and Safety

  • Debate over what “functional” means: OCaml is not purely functional but encourages immutability with escape hatches.
  • Immutability helps prevent mixed/partially-written state, though it doesn’t solve “stale view” problems; those exist with or without mutability.
  • Some worry about OCaml 5 data races; others point to the memory model and higher-level libraries (e.g., Eio) as mitigating factors.

Subjectivity, Hiring, and Maintainability

  • Multiple commenters note that “we like it” is a major, if often post-hoc, reason for language choice, and that morale and aesthetics matter.
  • Others warn that one person’s “joyful” stack can become a maintenance burden if it’s niche or overengineered.
  • Concern is raised about hiring OCaml devs; counterpoint is that enthusiasts actively seek such roles and strong devs are excited to learn.

Type Systems and Boilerplate

  • Some readers report realizing how much validation and unit testing can be replaced by strong types (“parse, don’t validate”).
  • Examples: ID wrappers, domain-specific types (Nonnegative, Percent, etc.) with constructors enforcing invariants at the boundary.

OCaml Ecosystem and Licensing

  • Disagreement over whether OCaml is “ready for production” and how user-friendly it is; others cite many long-running industrial users and strong backwards compatibility.
  • Mention of Jane Street’s OxCaml fork and Flambda2 being upstreamed.
  • Stategraph’s license is undecided; they aim to balance openness with sustainability, with some commenters hoping for AGPL.