Functional programming and reliability: ADTs, safety, critical infrastructure

Original Article ↗ Hacker News Discussion ↗

Scope of “Functional Programming”

  • Several comments argue the article conflates “functional programming” with “statically typed FP,” overlooking dynamically typed FP (e.g., Lisp, Scheme, Racket).
  • Others note that most of ICFP and FP discourse has become “types, types, types,” even though immutability, purity, and explicit effects are orthogonal to static typing.
  • Multiple participants say “functional programming” is so loosely defined that it’s more productive to discuss concrete features: immutability, purity, ADTs, effects, etc.

Static Types, ADTs, and Reliability

  • Strong static types + ADTs are seen by many as improving reliability via: making invalid states unrepresentable, safer refactors, and compiler-enforced exhaustiveness.
  • Rust, modern Java/Kotlin/C#/TypeScript are cited as non-“FP” languages that still reap these benefits. Typestate and state-machine modeling are brought up as practical patterns.
  • Others dispute the magnitude of benefit, arguing many production failures arise from complex, latent unsafe states that no type system can fully rule out.

Dynamic Languages and Reliability Practices

  • One thread describes using FP-style discipline in plain JavaScript: immutability (freezing), clear conventions, fast debugging, and refactoring without types.
  • Critics counter that dynamic typing shifts type checking to runtime and humans (“you are the type system”), potentially increasing production debugging.
  • Racket/HTDP are mentioned as examples where FP encourages type-like thinking even without a static type system.

ADTs, Unions, and Error Modeling

  • Debate over tagged vs untagged unions: untagged unions (e.g., T | null) ease API evolution; tagged/discriminated unions better support exhaustiveness and robust domain modeling.
  • Error handling: some argue FP makes complex error handling awkward without exceptions; others respond that encoding errors in ADTs/Result types is more precise and compositional than exception-based designs.

Critical Systems, Fault Tolerance, and Practice

  • Several comments push back on the article’s framing for banking/telecom: real systems lean heavily on fault tolerance, redundancy, reconciliation, and messy glue (FTP, spreadsheets, flaky protocols).
  • A common view: correctness-by-design (types, ADTs, explicit state machines) is one useful layer, but cannot replace fault tolerance, testing, chaos/fuzzing, and operational discipline.

Evidence and Silver-Bullet Skepticism

  • There is extended argument over empirical evidence that static typing improves reliability; some cite studies, others question their methodology or generality.
  • Many criticize absolutist claims: FP and strong types are valuable tools, but not a silver bullet, and cost–benefit depends on domain (safety-critical vs typical enterprise software).