Functional programming and reliability: ADTs, safety, critical infrastructure

Based on the Hacker News discussion, here are the four most prevalent themes:

1. The definition and scope of "functional programming" are ambiguous and contested. Multiple users argued that the term "functional programming" is too broad and ill-defined to be useful, especially when functional techniques are now mainstream in non-FP languages. > "The term 'functional programming' is so ill-defined as to be effectively useless in any kind of serious conversation." — mightybyte > "You'll see people here saying things like LISP wasn't real FP because it didn't match their Haskell-colored expectations. Meanwhile for decades LISP was the canonical example of FP." — jghn

2. Static type systems, ADTs, and immutability are the primary reliability drivers—not FP in itself. The discussion repeatedly separated the benefits of static typing, Algebraic Data Types (ADTs), and immutability from the broader label of functional programming. These features are credited with catching errors at compile time and preventing invalid states, a practice that is also evident in modern, non-FP languages like Rust. > "Almost all of the benefits of functional programming come from functional programming itself, not from static types, but one would never get that impression from the papers presented there." — aag > "Static types and ADTs are orthogonal to being FP, as Rust clearly shows." — brabel

3. Strongly-typed FP improves reliability, but dynamic languages are viable with discipline and tests. A central debate emerged between proponents of static typing, who argue it eliminates whole classes of runtime errors, and advocates for dynamic languages (like plain JS), who value malleability and speed. The dynamic camp concedes they must compensate with rigorous testing, architecture, and conventions. > "In dynamic languages, you are the type system." — keyle > "My point is simple to the point of stupidity: there's just more stuff on screen when you have to write User twice... I write tests. I use architecture to defend against the risk of super-rare code paths..." — conartist6

4. Practical reliability requires fault tolerance and design, not just correct-by-construction code. Several users pushed back on the idea that "correctness" alone ensures reliability, especially in complex systems like banking and telecom. They argued that real-world systems depend on fault tolerance, reconciliation, and defensive design, as unpredictable failures are inevitable in complex, distributed environments. > "Reliability is only a means. Not the end. Also the human parts of the business would need to be simplified in order to model them. If deviate from the model that could invalidate it." — charcircuit > "In a sufficiently complex system—all interesting and important software projects—functional programming is not strong enough a tool to prevent even a sliver of potential accidents." — thundergolfer