What functional programmers get wrong about systems

Article accessibility & style

• Several readers found the site hard to scroll (especially on Firefox mobile) and the article excessively long and repetitive for the amount of new ideas.
• Some felt the prose and section headers have an “LLM-ish” / clickbait tone; others strongly disagreed and praised it as clear, approachable, and well-structured.
• There’s back-and-forth over whether it’s “good technical writing,” with some calling it a survey/discussion piece rather than how‑to documentation.

Is this really about “functional programmers”?

• Multiple commenters argue the issues described (schema evolution, distributed versioning, semantic drift) are generic systems problems, not specific to FP, and the title is misleading or clickbaity.
• Others think it applies mainly to the highly-typed ML/Haskell tradition, not to Lisp/Erlang/Elixir-style FP that more freely uses unstructured data and embraces messy systems.
• A recurring point: the real distinction is “program vs system,” not FP vs non‑FP. FP just makes the program‑level part unusually strong, which can distract from system‑level concerns.

Versioning, schemas, and data evolution

• Strong agreement that the hard problems are:
  • Coexistence of multiple code versions and schema versions.
  • Logs and queues acting as “time capsules” of old data.
  • Semantic drift where meanings change without type changes.
• Discussion of approaches:
  • Temporal/bitemporal databases, event sourcing, and Datomic/Datalog-style immutable histories.
  • IDLs and tools (GraphQL schema diffing, Buf, Cambria, Typical, CUE) that encode or check evolution rules.
  • Modeling schema updates as typed functions between schema versions.

Static typing, FP tools, and their limits

• Many defend types/ADTs as extremely useful locally but insufficient for reasoning about whole evolving systems.
• Debate over “rigid types”: some say typed FP makes schema incompatibility painful; others counter that languages like Haskell can parse leniently into generic types when needed.
• Several note that even perfect local typing cannot detect semantic drift or user‑driven meaning changes.

Architectural strategies & critiques

• One long subthread argues for monorepos, monodeploys, and database/query systems integrated into the same language and type system to extend static checking across the system; others call this unrealistic and insufficient for real-world multi-service, multi-vendor environments.
• Model checking (e.g., TLA+) is proposed as a better fit for reasoning about global system properties.
• Erlang/Elixir are cited as examples of FP that are “honest” about distributed systems via processes and message passing.