Functional programming and reliability: ADTs, safety, critical infrastructure • Hacker News Board

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#91

Post by cloudhead » Sun, Dec 28, 2025, 1:54 PM UTC

charcircuit wrote: post #3

>In banking, telecom, and payments, reliability is not a nice to have. It is table stakes. This reliability isn't done by being perfect 100% of the time. Things like being able to handle states where transactions don't line up allowing for payments to eventually be settled. Or for telecom allowing for single parts of the system to not take down the whole thing or adding redundancy. Essentially these types of business…

False dichotomy.. if reliability matters, you have to invest in both. Fault tolerance is not a replacement for correctness.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#92

Post by Ekaros » Sun, Dec 28, 2025, 2:08 PM UTC

squirrellous wrote: post #79

whateveracct wrote: post #19

> In banking, telecom, and payments, reliability is not a nice to have. It is table stakes. Haha as someone who has worked in one of these domains using FP even - I wish the people in charge agreed with you! Reliability is a cost center and Product-oriented Builders treat it as such.

Perhaps someone can enlighten me on this. I never quite understood the sentiment of treating money-related tech as somehow more critical than others. The effects of large SaaS services failing and the bank failing can be quite similar - businesses interrupted, money lost, etc. but it’s typically not life and death, so the importance of reliability should be similar. I can understand treating social network sites as l…

Losses with money are easiest to prove thus easiest to litigate. And then also potentially prosecute. Money is in the end most of time reconcilable at the end. So any mistakes can be proven.

In other areas like lost sales or failures of the system there is lot more arguments. On other hand if you are rich enough and can prove the other side is off by sufficiently large amount of money you can bring the hammer down with facts.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#93

Post by rastrian » Sun, Dec 28, 2025, 2:10 PM UTC

cubefox wrote: post #67

rastrian wrote: post #60

Earlier quoted context omitted.

I think your Option/String example is a real-world tradeoff, but it’s not a slam-dunk “untagged > tagged.” For API evolution, T | null can be a pragmatic “relax/strengthen contract” knob with less mechanical churn than Option (because many call sites don’t care and just pass values through). That said, it also makes it easier to accidentally reintroduce nullability and harder to enforce handling consistently, the fai…

I believe there is a misunderstanding. The compiler can check untagged unions just as much as it can check tagged unions. I don't think there is any problem with "ambiguous narrowing", or "reliability". There is also no risk of "nullable everywhere": If the type of x is Foo|Null, the compiler forces you to write a null check before you can access x.bar(). If the type of x is Foo, x is not nullable. So you don't have…

I think we mostly agree for the nullable case in a sound-enough type system: if Foo | null is tracked precisely and the compiler forces a check before x.bar, then yes, you’re not “remembering” checks manually, the compiler is.

Two places where I still see tagged/discriminated unions win in practice:

1. Scaling beyond nullability. Once the union has multiple variants with overlapping structure, “untagged” narrowing becomes either ambiguous or ends up reintroducing an implicit tag anyway (some sentinel field / predicate ladder). An explicit tag gives stable, intention-revealing narrowing + exhaustiveness.

2. Boundary reality. In languages like TypeScript (even with strictNullChecks), unions are routinely weakened by any, assertions, JSON boundaries, or library types. Tagged unions make the “which case is this?” explicit at the value level, so the invariant survives serialization/deserialization and cross-module boundaries more reliably.

So I’d summarize it as: T | null is a great ergonomic tool for one axis (presence/absence) when the type system is enforced end-to-end. For domain states, I still prefer explicit tags because they keep exhaustiveness and intent robust as the system grows.

If you’re thinking Scala 3 / a sound type system end-to-end, your point is stronger; my caution is mostly from TS-in-the-wild + messy boundaries.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#94

Post by chrisoverzero » Sun, Dec 28, 2025, 2:11 PM UTC

conartist6 wrote: post #25

agumonkey wrote: post #17

Earlier quoted context omitted.

Is this a methodology you use at work or only for personal projects ? I'm curious how common this culture is among companies/teams.

I'm not personally aware of any companies doing this in plain JS aside from my own (I am co-founder/CEO of a two-person startup). I really like working in plain JS. It feels malleable where TS code feels brittle, almost crystalline. Even though I don't have compile-time types there's still only a small handful of different shapes of objects in the core of my software (far fewer than the average TS codebase, I'd wager…

> […] it shouldn't take long at all for people to learn the highly consistent naming conventions that tip you off to what type of data is being handled.

I’ve used languages with an approach like this. The difference in what I’ve used is that you separate the conventional part from the rest of the name with a space (or maybe a colon), then only refer to the value by the non-conventional part for the rest of the scope. Then the language enforces this convention for all of my co-workers! It’s pretty neat.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#95

Post by xpe » Sun, Dec 28, 2025, 2:12 PM UTC

See also the type-state pattern. It is commonly used in Rust along with the builder pattern [1]. Quoting:

"""The typestate pattern is an API design pattern that encodes information about an object’s run-time state in its compile-time type. In particular, an API using the typestate pattern will have:

- Operations on an object (such as methods or functions) that are only available when the object is in certain states,

- A way of encoding these states at the type level, such that attempts to use the operations in the wrong state fail to compile,

- State transition operations (methods or functions) that change the type-level state of objects in addition to, or instead of, changing run-time dynamic state, such that the operations in the previous state are no longer possible.

This is useful because:

- It moves certain types of errors from run-time to compile-time, giving programmers faster feedback.

- It interacts nicely with IDEs, which can avoid suggesting operations that are illegal in a certain state.

- It can eliminate run-time checks, making code faster/smaller."""

Some other languages can do it as well: see [2] for a discussion.

[1]: https://cliffle.com/blog/rust-typestate/

[2]: https://www.reddit.com/r/rust/comments/17l8eez/is_there_any_...

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#96

Post by acdha » Sun, Dec 28, 2025, 2:17 PM UTC

rastrian wrote: post #55

acdha wrote: post #54

Earlier quoted context omitted.

Sure, my point was simply that it’s not as simple as the author assumes. This is a common failure mode in FP advocacy and it’s disappointing because it usually means that a more interesting conversation doesn’t happen because most readers disengage.

I get why it reads like FP evangelism, but I don’t think it’s “ignoring decades of prior art.” I’m not claiming these ideas are exclusive to FP. I’m claiming FP ecosystems systematized a bundle of practices (ADT/state machines, exhaustiveness, immutability, explicit effects) that consistently reduce a specific failure mode: invalid state transitions and refactor breakage. Rust is actually aligned with the point: it d…

I would keep in mind how much the title communicates your intentions on future posts. The conversation about preventing invalid states has to be somewhat inferred when it could have been explicitly stated, and that’d be really useful comparing other approaches - e.g. the classic OOP style many people learned in school also avoid these problems as would something like modern Python using Pydantic/msgspec so it’d be useful to discuss differences in practice, and especially with a larger scope so people who don’t already agree with you can see how you came to that position.

For example, using the input parsing scenario, a Java 1.0 tutorial in 1995 would have said that you should create a TimeDuration class which parses the input and throws an exception when given an invalid value like “30s”. If you say that reliability requires FP, how would you respond when they point out that their code also prevents running with an invalid value? That discussion can be far more educational, especially because it might avoid derails around specific issues which are really just restating the given that JavaScript had lots of footgun opportunities for the unwary developer, even compared to some languages their grandmother might have used.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#97

Post by wiseowise » Sun, Dec 28, 2025, 2:24 PM UTC

pizlonator wrote: post #29

It's acceptable to state, without evidence, that functional programming and static typing make things more reliable. But this isn't a falsifiable claim. We cannot possibly know if this is true or not. - Not all of banking and telecom use functional programming or even static typing. - Functional programming often leads to write-only incomprehensible code; the exact opposite of what you need to have a reliable system.…

> Functional programming often leads to write-only incomprehensible code; the exact opposite of what you need to have a reliable system.

In what language?

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#98

Post by wiseowise » Sun, Dec 28, 2025, 2:29 PM UTC

jatins wrote: post #69

These arguments unfortunately fail flat in front of industrial use. AWS could be considered "critical" by most metrics and what is is it written in? Java

Modern Java supports everything in the blogpost, so nothing stops AWS from adopting the style.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#99

Post by wiseowise » Sun, Dec 28, 2025, 2:31 PM UTC

hibikir wrote: post #72

d--b wrote: post #12

Strong types: yes, it’s definitely better Functional programming: no, functional programming as in: the final program consists in piping functions together and calling the pipe. In my opinion, that tends to get in the way of complex error handling. The problem being that raising Exceptions at a deep level and catching them at some higher level is not pure functional programming. So your code has to deal with all the…

That's only a problem when you decide that the way to do error handling is exceptions. When you go with a strongly typed functional programming language, you throw exceptions away, and the fact that something can error, and what kinds of errors it can produce, are encoded into the type system. So yes, generating errors at a deep level and catching them at a higher one is a normal pard of the system design, it's purel…

> When you go with a strongly typed functional programming language, you throw exceptions away, and the fact that something can error, and what kinds of errors it can produce, are encoded into the type system.

You’ve just reinvented checked exceptions, good job.

Re: Functional programming and reliability: ADTs, safety, critical infrastructure

#100

Post by xpe » Sun, Dec 28, 2025, 2:38 PM UTC

pizlonator wrote: post #29

It's acceptable to state, without evidence, that functional programming and static typing make things more reliable. But this isn't a falsifiable claim. We cannot possibly know if this is true or not. - Not all of banking and telecom use functional programming or even static typing. - Functional programming often leads to write-only incomprehensible code; the exact opposite of what you need to have a reliable system.…

> ... functional programming and static typing make things more reliable.

> But this isn't a falsifiable claim.

Saying "this isn't falsifiable" is a wild claim. Indeed the claim "functional programming and static typing make things more reliable" is falsifiable, as long as you admit a statistical understanding. The world is messy and experiments have noise, so what would you use if not statistics? Anecdotes?: no. Purely deductive methods?: no; we should not expect any single technique to be a silver bullet.

Good studies and analyses lay out a causal model and use strong methodologies for showing that some factor has a meaningful impact on some metric of interest. I recommend this as a starting point [1]

[1]: https://yanirseroussi.com/2016/05/15/diving-deeper-into-caus...