Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional programming and reliability: ADTs, safety, critical infrastructure

blog.rastrian.dev

Post reply on HN
Print view View original

151–160 of 191 posts

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

#151

Post by thefaux »

threethirtytwo wrote: post #51
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.…

Wait. This doesn’t make sense to me. Statically typed programming languages cannot be deployed nor can they run with a type error that happens at runtime. Untyped languages CAN run and error out with a type error AT runtime. The inevitable consequence of that truth is this: In the spectrum of runtime errors statically typed languages mathematically and logically HAVE less errors. That by itself is the definition of m…

This logic is both too broad and rigid to be of much practical use[1]. It needs to be tightened to compare languages that are identical except for static type checks, otherwise the statically typed language could admit other kinds of errors (memory errors immediately come to mind) that many dynamic languages do not have and you would need some way of weighing the relative cost to reliability of the different categories of errors.

Even if the two languages are identical except for the static types, then it is clearly possible to write programs that do not have any runtime type errors in the dynamic language (I'll leave it as an exercise to the reader to prove this but it is very clearly true) so there exist programs in any dynamic language that are equally reliable to their static counterpart.

[1] I also disagree with your definition of reliability but I'm granting it for the sake of discussion.

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

#152

Post by chrisoverzero »

conartist6 wrote: post #146
chrisoverzero wrote: post #141

Earlier quoted context omitted.

Sure! Let’s say I want to enforce that a variable only ever holds an integer. Rather than put the conventional prefix and the name together, like this: var intValue = 3; …I separate the conventional prefix with a space: int value = 3; …so now my co-workers don’t need to remember the convention – it’s enforced by the language. (I hope this makes the joke more obvious.)

I wasn't talking about Hungarian notation. I meant more like if you see a variable named `user` or `activeUser` you know that it's going to contain a predictably-shaped data object that describes a user. E.g. it will always have a `user.id` property. I would never call an string-ish ID a user, then. I would call it `activeUserId` or `userId` or just `id` if the distinction between those was already obvious from conte…

Mhm! Exactly! In the system those other languages use, once you see the variable’s declaration:

    User activeUser
…you’ll always know that `activeUser` contains a User value – something that might have an `Id` property. And the convention is enforced by the language, so it’s easy to communicate. These semantic distinctions are very useful, I agree.

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

#153

Post by keyle »

zephen wrote: post #121
keyle wrote: post #53

Earlier quoted context omitted.

You're about a decade too late with that argument. The best argument for dynamic types systems, is enjoying debugging in production. In dynamic languages, you are the type system.

> The best argument for dynamic types systems, is enjoying debugging in production. This comment is either severe snark or severe ignorance.

Please, do elaborate...

If you remove passes of a compiler, you, looking at it whilst running, are the compiler.

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

#154

Post by conartist6 »

chrisoverzero wrote: post #152
conartist6 wrote: post #146

Earlier quoted context omitted.

I wasn't talking about Hungarian notation. I meant more like if you see a variable named `user` or `activeUser` you know that it's going to contain a predictably-shaped data object that describes a user. E.g. it will always have a `user.id` property. I would never call an string-ish ID a user, then. I would call it `activeUserId` or `userId` or just `id` if the distinction between those was already obvious from conte…

Mhm! Exactly! In the system those other languages use, once you see the variable’s declaration: User activeUser …you’ll always know that `activeUser` contains a User value – something that might have an `Id` property. And the convention is enforced by the language, so it’s easy to communicate. These semantic distinctions are very useful, I agree.

Haha I knew you'd say that. I'm not pretending there aren't advantages to strict systems of declared types. There are many! But my point is simple to the point of stupidity: there's just more stuff on screen when you have to write `User` twice. In this simple example it looks trivially simple to write the word "user" twice, but in a reasonably-complex real example the difference will be far more noticeable.

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

#156

Post by AdieuToLogic »

rastrian wrote: post #48
charcircuit wrote: post #42

Earlier quoted context omitted.

Not if proving so is more expensive to do than not. 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.

Agree on the economics. I’m not arguing for full formal proofs; I’m arguing for low-cost enforcement of invariants (ADTs/state machines/exhaustiveness) that makes refactors safer and prevents silent invalid states. Human processes will always drift, so you enforce what you can at the system boundary and rely on reconciliation/observability for the rest.

In the banking subdomain of credit/debit/fleet/stored-value card processing, over time when considering regulation and format evolution, services provided by banks/ISOs/VARs will effectively exhibit FP traits regardless the language(s) used to implement them.

Savvy processors recognize the immutability of each API version published to Merchants, along with how long each must be supported, and employ FP techniques both in design and implementation of their Merchant gateways.

Of course, the each bank's mainframes "on the rails" do not change unless absolutely necessary (and many times not even then).

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

#157

Post by int08h »

thundergolfer wrote: post #150
int08h wrote: post #61

Earlier quoted context omitted.

Hmm, it seems you actually agree with the OP: OP says (your quote): > [Most production incidents] are due to the code entering a state that should never have been possible. You say: > [...] it is more true that most production incidents are due to the system entering into one of thousands of unsafe states which were possible and latent in production potentially for years I see you both agree that a broken system ente…

The crux is in the "never have been possible" bit. In complex systems, it is impossible to eliminate these potential states with functional programming or any other technique, unsafe states are always potentialities that must be actively controlled. Another way of casting it is like this. The goal may be: 1. Eliminate possibility code can enter invalid state 2. Control parameters of the system so that it remains in a…

Right, I understand your meaning better.

I agree with you: no matter how good of a job the code (by construction or types or otherwise) does of “making unsafe states unrepresentable”, that in no way makes a real world complex system “safe” by itself.

Code can be structured so that valves may only be open OR closed, but nothing stops the real world from returning a sensor reading that says “the valve is ”. To remain a “safe” system, the system must deal with inconsistent states like “heisen-valves”.

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

#158

Post by mbac32768 »

mlavrent wrote: post #2

This article seems to conflate strong type systems with functional programming, except in point 8. It makes sense why- OCaml and Haskell are functional and were early proponents of these type systems. But, languages like Racket don’t have these type systems and the article doesn’t do anything to explain why they are _also_ better for reliability.

Once you accept Curry-Howard, untyped FP languages are hard to take seriously as a foundation for reliability. Curry-Howard changes the entire game. FP and strong types were clearly meant for each other.

Untyped FP languages can be productive, flexible, even elegant (I guess) but they are structurally incapable of expressing large classes of correctness claims that typed FP makes routine.

That doesn’t make them useless, just, you know. Inferior.

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

#159

Post by tariqshams »

kephasp wrote: post #148
agumonkey wrote: post #110

Earlier quoted context omitted.

this makes me want to move to a haskell (or any hard fp language) shop in 2026..

I've been using Haskell professionally for the last 5 years, I definitely hope I can continue!

Genuinely curious on the types of projects you use Haskell for! I’ve been thinking of learning it beyond the lightweight treatment I got during my CS degree.

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

#160

Post by yobbo »

kephasp wrote: post #147
yobbo wrote: post #139

Earlier quoted context omitted.

Db access in rust typically needs some sort of handle and a mutex. Limiting access to the handle makes the rest of the code pure with respect to the db. The handle plays a similar role to the IO type. Actor-like patterns makes this nice. Message-objects can be passed to/from a module with db-access or other io.

How can you prevent code from creating a handle in a new place?

You can limit access to your db credentials. But other code can still launch missiles etc.
Post reply on HN