15 ms·

Functional programming and reliability: ADTs, safety, critical infrastructure

158 points by rastrian 9mo ago

mlavrent 9mo ago
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.
- conartist6 9mo ago
  You don't need a strong type system or even really ANY compile-time type system for this strategy to work! I use all these techniques in plain JS and I can still get the benefits of correct-by-construction code style just by freezing objects and failing fast.
  - bdangubic 9mo ago
    godspeed with that :)
  - agumonkey 9mo ago
    Is this a methodology you use at work or only for personal projects ? I'm curious how common this culture is among companies/teams.
    - conartist6 9mo ago
      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), and 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. The result is that I'd expect that it would only be a handful of days learning the mental model for the codebase before the average person would find it far easier to read the JS code as opposed to TS code, thanks to the lower amount of visual clutter. I also ship code super fast. When I find bugs I just fix them on the spot. When I find variables named wrong, I just rename them. The result that I often smash bugfixes and features and cleanup together and have a messy git history, but on the flip side you'll never find bugs or naming deceptions that I've left sitting for years. If something is wrong and I can reproduce it (usually easy in functional code), the debugger and I are going to get to the bottom of it, and quickly. Always and only forward!
      - conartist6 9mo ago
        I should add a few more things: much of how I got here was exposure to Facebook's culture. Move fast and break things. React with prop types. Redux. Immutable.js. I did UI there on internal tools for datacenter operators and it was a drinking-from-the-firehose experience with exposure to new programming philosophies, tools, and levels of abstraction and refactoring velocity beyond anything I had previously encountered. Problems which in other companies I had learn to assume would never be resolved would actually consistently get fixes! Well, at that time. This was before the algorithm was fully enshittified and before the disastrous technopolitical developments in the way facebook and facebook messenger interact with each other. Perhaps the most direct inspiration I took from there though was from the wonderful "opaque types" feature that Flow supports (https://flow.org/en/docs/types/opaque-types/ https://flow.org/en/docs/types/opaque-types/) which for reasons known only to Hejlsberg and God, Typescript has never adopted; thus most people are unfamiliar with that way of thinking.
        auggierose 9mo ago
        Yes, I am wondering if opaque types would be difficult to implement somehow in TypeScript? It should really be part of TypeScript if at all reasonably possible.
        conartist6 9mo ago
        I'm not that familiar with the TS internals. They'd have to add a keyword to the language which could break stuff. The smart move would be to reserve the `opaque` word a few versions in advance of introducing the feature that gives it a meaning
        auggierose 9mo ago
        I don't think the keyword is the problem, I am wondering more about the internals of their type inference algorithm.
      - chrisoverzero 9mo ago
  - keyle 9mo ago
    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.
    - zephen 9mo ago
      > The best argument for dynamic types systems, is enjoying debugging in production. This comment is either severe snark or severe ignorance.
      - keyle 9mo ago
        Please, do elaborate... If you remove passes of a compiler, you, looking at it whilst running, are the compiler.
        2colours 9mo ago
        It's a bit ironic that now we went down the static rabbit hole so much that we don't realize it's more the opposite: by adding more to your language and compiler to enforce static checks, you turn the compiler itself more and more into a runtime that you are just going to run ahead of time, according to a potentially vastly different set of rules compared to your real runtime. There is no reason why you couldn't do something like this by will but it's just not worth it after a certain point clearly.
        conartist6 9mo ago
        I agree. So I write tests. I use architecture to defend against the risk of super-rare code paths where I wouldn't rapidly notice if they broke. I dogfood so I find prod bugs before users do. None of this seems that new. Even people who write TS code still write tests and still ship bugs and still have to think about good architecture patterns, like the ones in the linked post.
- aag 9mo ago
  Thank you for saying that. I regularly attend the International Conference on Functional Programming, which grew out of the LISP and Functional Programming conference. Except for the Scheme Workshop, which is the reason I attend, it might as well be called the International Conference on Static Types. 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. The types are all that anyone talks about.
  - rastrian 9mo ago
    I get your point about ICFP drifting into “types, types, types.” I don’t think FP benefits are only static typing or immutability, pure-ish core/imperative shell, and explicit effects matter a lot even in dynamic languages. My angle was narrower: static types + ADTs improve the engineering loop (refactors, code review, test construction) by turning whole classes of mistakes into compiler errors. That’s not “what FP is”, it’s one very effective reliability layer that many FP ecosystems emphasize.
    - brabel 9mo ago
      Static types and ADTs are orthogonal to being FP, as Rust clearly shows. But to speak in terms of FP when those are the important things for you is just wrong since even non FP languages now have ADT, including also mainstream languages like Java, Kotlin, Dart, C# and more. Even purity is not something exclusive to FP, D and Nim also support separating pure from impure functions. And if you ask me, the reason not many other languages have support for that is that in practice, it has been demonstrated again and again that it’s just not nearly as useful as you may think. Effects, as in Unison and Flix, generalizes the concept to include many more concepts than just purity and may perhaps prove more useful in general purpose programming, but the jury is still out on this.
      - yunnpp 9mo ago
        Help me with a tl;dr here, but are effects just monads?
- acdha 9mo ago
  Yeah, I know Rust isn’t everyone’s favorite but I’d expect at least some awareness that we’ve seen a lot of reliability improvements due to many of these ideas in a language which isn’t focused on FP. I ended up closing the tab when they had the example in TypeScript pretending the fix was result types rather than validation: that idea could be expressed as preferring that style, an argument that it makes oversights less likely, etc. but simply ignoring decades and decades of prior art suggests the author either isn’t very experienced or is mostly motivated by evangelism (e.g. COBOL didn’t suffer from the example problem before the first FP language existed so a far more interesting discussion would be demonstrating awareness of alternatives and explaining why this one is better).
  - galangalalgol 9mo ago
    Rust certainly isn't a pure fp language, but the borrow checkerbl is a lot kinder when you use fp style.
    - acdha 9mo ago
      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.
      - rastrian 9mo ago
        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 delivers major reliability wins via making invalid states harder to represent (enums, ownership/borrowing, pattern matching). That’s not “FP-first,” but it’s very compatible with functional style and the same invariants story. If the TS example came off as “types instead of validation,” that’s on me to phrase better, the point wasn’t “types eliminate validation,” it’s “types make the shape explicit so validation becomes harder to forget and easier to review.”
- saghm 9mo ago
  I've seen it pointed out that the main point of functional programming is immutability, and that the benefits mostly flow from that. I haven't really learned much of any lisp dialect, but my (admittedly fuzzy) general perception is that this is also the preferred way to work in them, so my guess is that's where the benefit in reliability might come from.
  - zelphirkalt 9mo ago
    Correct. If things are mutable, then in most languages, there can be spooky action at a distance, that mutates some field of some other object or does so indirectly via some calls. This then can change how the thing behaves in other circumstances. This style of programming quickly becomes hard to fully grasp and leads to humans making many mistakes. Avoiding mutation therefore avoids these kinds of faults and mistakes.
- adamddev1 9mo ago
  I worked through https://htdp.org https://htdp.org (which uses untyped Racket), and funny enough, that's what really for me thinking about type driven development. The book gets you to think about and manually annotate the types coming in and out of functions. FP just makes it so natural to think about putting functions together and thinking about the "type" of data that comes in and out, even if you're using a dynamically typed language.
- rastrian 9mo ago
  Agreed, I conflated FP with “typed FP.” My claim is mainly about static types + ADTs/exhaustiveness improving refactors/review/tests. Racket can get FP benefits, but absent static typing you rely more on contracts/tests (or Typed Racket), which is a different reliability tradeoff.
- mightybyte 9mo ago
  The term "functional programming" is so ill-defined as to be effectively useless in any kind of serious conversation. I'm not aware of any broadly accepted consensus definition. Sometimes people want to use this category to talk about purity and control of side effects and use the term "functional programming" to refer to that. I would advocate the more targeted term "pure functional programming" for that definition. But in general I try to avoid the term altogether, and instead talk about specific language features / capabilities.
  - jghn 9mo ago
    > The term "functional programming" is so ill-defined as to be effectively useless in any kind of serious conversation. This is important. I threw my hands up and gave up during the height of the Haskell craze. You'd 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. Similar to you, now I talk about specific patterns and concepts instead of calling a language functional. Also, as so many of these patterns & concepts have found their way into mainstream languages now, that becomes even more useful.
    - agumonkey 9mo ago
      to add a grain of salt, some of the lisp world is not functional, a lot of code is straight up imperative / destructive. but then yeah a lot of the lisp culture tended to applicative idioms and function oriented, even without the static explicit generic type system of haskell.
      - jghn 9mo ago
        Sure, but that's part of my point in agreeing that definitions of "functional programming" are muddy at best. If one were to go back to say 1990 and poll people to name the first "functional programming" language that comes to mind, I'd wager nearly all of them would say something like LISP or Scheme. It really wasn't until the late aughts/early teens when that started to shift.
- mbac32768 9mo ago
  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.
henning 9mo ago
I like good type systems, too, but they won't save you from bugs that are better addressed by fuzz testing, fault injection testing and adversarial mindset shifts.
- saghm 9mo ago
  Luckily these aren't exclusive! You can do all of those things with a strong type system as well, and get the benefits of all of them.
  - z0ltan 9mo ago
    [dead]
  - rastrian 9mo ago
    100%. Types don’t replace fuzzing, property tests, chaos, or adversarial thinking. They just move one slice of bugs from runtime to compile time and make refactors safer. In hindsight I should have positioned types/ADTs as one layer in the reliability toolbox, not the toolbox.
charcircuit 9mo ago
>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 businesses require fault tolerance to be supported. The real world is messy, there is always going to be faults, so investing heavily into correctness may not be worth it compared to investing into fault tollerance.
- discarded1023 9mo ago
  You'd like to know your fault tolerance is reliable and possibly even correct.
  - charcircuit 9mo ago
    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.
    - rastrian 9mo ago
      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.
      - nickpsecurity 9mo ago
        You can also argue that debugging time can be expensive but static checks reduce debugging. This is much more true when it's concurrency errors.
      - 9mo ago
wewewedxfgdf 9mo ago
I'm wary of absolute statements about programming.
- ggm 9mo ago
  I want to be a contrarian and argue with this, but my daily praxis is generally to take a betteridges law approach to most argumentative absolutes and also false dichotomous headlines and question them. Reading the other comments to the effect that the conferences are now strong typing gabfests and insufficiently about FP per se reinforced this feeling. Reliability should be simpler with FP but so much depends on correctness of the runtime and IO. Erlang and the "run correctly or die" comes to mind as well. The system is either working or is off. When being off is fatal, Erlang seems to shrug and say "maybe next karmic cycle" maybe this too is a better approach?
d--b 9mo ago
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 cases. It is more reliable if you can do it, but large systems have way too many failure points to be able to handle them all in a way that is practical.
- zelphirkalt 9mo ago
  If you have strong types, it is still possible to make a mutable thing, that will be mutated from the other end of the program and that will introduce bugs, that can be hard to find. If you are doing FP on the other hand, at least change always results in new objects, with structural sharing at most. This excludes a whole category of bugs.
  - Jensson 9mo ago
    > If you are doing FP on the other hand, at least change always results in new objects, with structural sharing at most. This excludes a whole category of bugs. Not if you program it with a mutable god object to mimic creating a new big state, then you have exactly the same kind of issues. The issue is if you try to program a transaction flow using object oriented programming, that is not very good, and most work programmers do revolves around involves flows. But when it doesn't then functional programming isn't a very good or reliable solution.
    - zelphirkalt 9mo ago
      > Not if you program it with a mutable god object to mimic creating a new big state, then you have exactly the same kind of issues. Have you done any FP? That's not how you do FP.
- breadwinner 9mo ago
  > that tends to get in the way of complex error handling. Agree. In Java, Streams allow you to process collections in a functional style. This feature enables concise, expressive data manipulation with operations like map, filter, and reduce. Some people point out that Java's checked exceptions spoil the simplicity and elegance of Streams by forcing you to handle exceptions. But that's not a reason to not have checked exceptions, it is a reason to not do functional style composition when methods can throw exceptions. Streams was invented for collections, which tend not to throw exceptions. If proper error handling is important don't do Streams.
cubefox 9mo ago
I think there is a strong case that ADTs (algebraic data types) aren't so great after all. Specifically, the "tagged" unions of ADT languages like Haskell are arguably pretty clearly inferior to the "untagged" unions of TypeScript or Scala 3. Because the latter actually behave like a logical "or" rather than an artificial construct that needs to be wrapped and unwrapped.
- jesse__ 9mo ago
  > "tagged" unions of ADT languages like Haskell are arguably pretty clearly inferior to the "untagged" unions of TypeScript dude .. wut?? Explain to me exactly how this is true, with a real world example. From where I stand, untagged unions are useful in an extremely narrow set of circumstances. Tagged unions, on the other hand, are incredibly useful in a wide variety of applications.
  - cubefox 9mo ago
    Example: Option<> types. Maybe a function returns an optional string, but then you are able to improve the guarantee such that it always returns a string. With untagged unions you can just change the return type of the function from String|Null to String. No other changes necessary. For the tagged case you would have to change all(!) the call sites, which expect an Option<String>, to instead expect a String. Completely unnecessary for untagged unions. A similar case applies to function parameters: In case of relaxed parameter requirements, changing a parameter from String to String|Null is trivial, but a change from String to Option<String> would necessitate changing all the call sites. > From where I stand, untagged unions are useful in an extremely narrow set of circumstances. Tagged unions, on the other hand, are incredibly useful in a wide variety of applications. Any real world example?
    - rastrian 9mo ago
      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<T> (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 failure mode is “it compiles, but someone forgot the check.” In practice, once the union has more than “nullable vs present”, people converge to discriminated unions ({ kind: "ok", ... } | { kind: "err", ... }) because the explicit tag buys exhaustiveness and avoids ambiguous narrowing. So I’d frame untagged unions as great for very narrow cases (nullability / simple widening), and tagged/discriminated unions as the reliability default for domain states. For reliability, I’d rather pay the mechanical churn of Option<T> during API evolution than pay the ongoing risk tax of “nullable everywhere. My post argues for paying costs that are one-time and compiler-enforced (refactors) vs costs that are ongoing and human-enforced (remembering null checks).
whateveracct 9mo ago
> 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.
- stingraycharles 9mo ago
  Honestly, as someone else who does a lot of data plumbing, there is so much FTP servers with excel sheets being used as the means for official clearance processes. There are constant data bugs in the feeds provided by major exchanges, market makers, etc, and so many iffy business rules that are basically all encoded in 100+ tab excel sheets. Maybe this article focuses on a very specific niche of banking, but most of it is tied together with FTP and excel sheets. I think the author would be shocked just how flaky a fundamental banking protocol like SWIFT is.
  - rastrian 9mo ago
    I’ve worked in Brazilian banking stacks that were literally FTP + spreadsheets for years. So yes, the ecosystem is often messy and protocols can be flaky. That’s exactly why I argue for stronger internal modeling: when the boundary is dirty, explicit state machines/ADTs + exhaustiveness + idempotency/reconciliation help ensure bad feeds don’t silently create invalid internal states.
    - whateveracct 9mo ago
      I totally agree as a fellow fintech engineer. It was a battle getting approval for all that from Product for us. While we were battling for it, we rushed multiple projects without literally any of it. And then spent a year+ each time cleaning up the mess.
      - brabel 9mo ago
        And your pockets were being filled in that year while you were just doing cleanups. Mission accomplished.
thundergolfer 9mo ago
All the line items are decent things, worth doing, but the claim about how much following the line items would improve reliability is super exaggerated. > [Most production incidents] are due to the code entering a state that should never have been possible. I have never seen evidence that this is even remotely true, and I've been looking at software reliability research in the last few months. Instead, 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. 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. > Arguments that these degraded conditions should have been recognized before the overt accident are usually predicated on naïve notions of system performance. System operations are dynamic, with components (organizational, human, technical) failing and being replaced continuously. — https://how.complexsystems.fail/ https://how.complexsystems.fail/
- int08h 9mo ago
  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 enters an "unsafe state" (your words) or a "state that should never have been possible" (OP's words). "Unsafe state" and "state that should not have been possible" are, in practice in a real system, the same practical thing. I suspect you both would agree "system confuses a string for an integer and acts based on erroneous value" or "system acts on internal state that indicates the valve is both open and closed" would be states that a system should not be in. Outside pedantry, your descriptions are practically synonymous with each other.
  - thundergolfer 9mo ago
    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 safe condition Those are very different goals.
FpUser 9mo ago
Yet another silver bullet.
- rastrian 9mo ago
  Fair pushback. I agree the title and a couple of lines overshoot. My intent isn’t “FP is a silver bullet” or “types replace operational reliability”
pizlonator 9mo ago
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. - There's no hard evidence that static typing improves reliability. Only vibes and feels.
- dionian 9mo ago
  It improves reliability at compile time, certainly
- ux266478 9mo ago
  > There's no hard evidence that static typing improves reliability. I'm curious how you came to that conclusion? https://pleiad.cl/papers/2012/kleinschmagerAl-icpc2012.pdf https://pleiad.cl/papers/2012/kleinschmagerAl-icpc2012.pdf https://www.deepdyve.com/lp/springer-journals/an-empirical-study-on-the-impact-of-static-typing-on-software-0ZImQZ508o https://www.deepdyve.com/lp/springer-journals/an-empirical-s...
  - rastrian 9mo ago
    I was searching for the Stefik article to argue here, thank you.
  - pizlonator 9mo ago
    I don't consider a human subjects study to be "hard evidence". So, we can safely disregard these papers. They got exactly the result that they sought out to get, and the papers were published because they confirmed the preexisting groupthink.
    - rowanG077 9mo ago
      Interesting, so you consider the entire scientific field of medicine to work without hard evidence?
websiteapi 9mo ago
A few mention on tests, but I expected more. The main value of pure functions is that now their behavior is representative in tests. In fact, I'd argue that all you need for reliability is determinism and tests of all equivalent scenarios. functional programming (and immutability) are only helpful to the extent that it's easier to have representative tests, but not necessarily required.
- rastrian 9mo ago
  Agree, I didn’t give testing enough space. A proper treatment would’ve doubled the post, so I’m writing a separate follow-up on testing. Pure functions/immutability help a lot because tests become representative and cheap. I’d only push back on “tests of all equivalent scenarios” being sufficient, the space explodes and many real failures live at I/O/concurrency/distributed boundaries. My intended claim is that FP/ADTs/types reduce the state space and improve the ROI of tests, not replace them.
- xpe 9mo ago
  > In fact, I'd argue that all you need for reliability is determinism and tests of all equivalent scenarios. Any insights as to how to get effective determinism without pure functions? Pure functions win here because we only have to reason about the function arguments. Reasoning is easier when you have to less of it! Without pure functions, the state space explodes, because anything anywhere could have a side-effect — madness, I say! — so how would you figure out equivalent states? Special case inspection I suppose? There is a continuum between "anything goes" and "pure functions". From a certain light, all the varieties of encapsulation can be seen as explorations of this theme. (An idea: perhaps there are languages where side-effects can be circumscribed in ways that don't rely on the high bar of pure functions?) The arguments against pure functions appear to be somewhat contingent: current adoption levels, practice, convenience, and taste. Things that are contingent have a way of changing over time as new methods emerge and new values take hold. I don't hold shallow human preferences in high regard. As an example, many humans and organizations in practice trade security for convenience, at significant cost — especially when that cost is external to them. At the same time, onerous tasks encourage work-arounds. This is the crux of it I think: unless people perceive the value of pure functions (to do what they want to do), some will seek shortcuts. So we need some combination of (1) making them easier to work with; (2) motivating people to aspire to higher principles; namely, high quality software that does not open to door to exploitation, misuse, botnets, etc; and/or (3) internalize the external costs. As an example of (3), if people and companies faced predictable and commensurate costs when their flawed software inflicts harm on others, they would be more inclined to care about correctness.
jatins 9mo ago
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
- wiseowise 9mo ago
  Modern Java supports everything in the blogpost, so nothing stops AWS from adopting the style.
  - rastrian 9mo ago
    I really don’t like the argument calling “industrial usage” just because a main company or FAANG aren’t using the tech stack, but arbitrary under the hood are doing basically the same stuff with internal toolings that should be entirely under the language features, not under a system design library. But your take about modern Java is correctly, and they adopt this style under internal projects for some workflows.
jschrf 9mo ago
Tup: Use interface for structural types in TypeScript, not type.
tasuki 9mo ago
I'm impressed by the author having made so many sensible choices in their life, yet marrying their blog content to GitHub issues.
- rastrian 9mo ago
  lmao
mightybyte 9mo ago
Was just talking with someone the other day who used to write Haskell professionally but is now using Python. He said that in his experience when there are bugs the "blast radius" is much larger in a dynamic language like Python than in a static language like Haskell. That has been my experience as well. Something I haven't seen talked about, though, is how powerful the type system is for constraining LLMs when using them to generate code. I was recently trying to get LLMs to generate code for a pretty vague and complex task in Haskell. I wasn't having much luck until I defined a very clear set of types and organized them into a very clear and constrained interface that I asked the LLM to code to. Then the results were much better! Sure, you can use these same techniques in less strongly typed languages like Rust, and you can probably also use a similar approach in dynamically typed languages, but Haskell's pure functions allow you to create much stronger guard rails constraining what kinds of code the LLM can write.
- Jeff_Brown 9mo ago
  Amen. I've been coding a big hobby project in Rust since July, after having spent years using Haskell for such things. I chose Rust because the primary DB I wanted to use (TypeDB) only had drivers for Rust and Python at the time. Rust is popular relative to Haskell, so I thought others might be more likely to sign on, and the type system seemed almost as expressive. But since purity is not encoded in Rust's type system, any function might do any kind of IO -- in particular, read from or write to disk or one of the DBs. That makes the logic much harder to reason about. (Also, Rust's syntax is so noisy and verbose that it's harder to see what's going on, and less context fits in my head at one time. I'm getting better at paying that cost, but I wish it weren't there.) I can't say I made the wrong decision, but I often fantasize about moving most of the logic into Haskell and just calling Rust from Haskell when I need to call TypeDB from Rust.
  - yobbo 9mo ago
    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.
xpe 9mo ago
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/ https://cliffle.com/blog/rust-typestate/ [2]: https://www.reddit.com/r/rust/comments/17l8eez/is_there_any_other_language_that_do_type_state/ https://www.reddit.com/r/rust/comments/17l8eez/is_there_any_...
- zozbot234 9mo ago
  The type-state pattern is really just OOP implementation inheritance in a type-theoretic trench coat. The relevant difference is simply that most uses of type-state are not trying to span multiple modules like the OOP design approach does; the "state" variations are contained such that they don't impact modularity throughout the program, unlike the OOP inheritance approach.
northlondoner 9mo ago
Yes.
beders 9mo ago
Most of the musings on enforcing invalid states with ADTs are impractical when working with real data that needs runtime validation when it enters the system. Using a schema/spec/type library at runtime that is even more powerful than ADTs is a better investment - or to be less controversial - is an additional investment on top of types. Yes, it means the compiler can't help you as much, but who has time waiting for a compiler anyways ;) I find the "make illegal state unrepresentable via types" idea great for software that needs to fly a plane, but for enterprise software not so much. The cost/benefit is not justifiable.
fud101 9mo ago
Of course you can do this with Typescript but what about Python if you're stuck using it for $dayjob. Any tips?
- rastrian 9mo ago
  You can get most of the “ADT/state-machine reliability” benefits in Python by combining static checking + tagged unions + boundary validation: Model states as tagged unions (Union + Literal + dataclass(frozen=True)), use match (Py3.10+) and add assert_never so type checkers complain when you forget a case. Run Pyright (strict) or mypy –strict in CI so “illegal states” show up as build failures, not incidents. Validate/parsing at boundaries (HTTP/queues) with Pydantic discriminated unions (tagged unions at runtime), then keep internals typed. For expected failures, prefer an explicit Result (e.g., returns) over exceptions-as-control-flow. Use Ruff for lint/consistency (it’s not a type checker, but pairs well with one). References here: Pyright: https://microsoft.github.io/pyright/ https://microsoft.github.io/pyright/ mypy --strict: https://mypy.readthedocs.io/en/stable/getting_started.html https://mypy.readthedocs.io/en/stable/getting_started.html PEP 634 (match): https://peps.python.org/pep-0634/ https://peps.python.org/pep-0634/ assert_never & exhaustiveness guide: https://typing.python.org/en/latest/guides/unreachable.html https://typing.python.org/en/latest/guides/unreachable.html typing_extensions (backports): https://typing-extensions.readthedocs.io/ https://typing-extensions.readthedocs.io/ Pydantic discriminated unions: https://docs.pydantic.dev/latest/concepts/unions/ https://docs.pydantic.dev/latest/concepts/unions/ returns Result: https://returns.readthedocs.io/en/latest/pages/result.html https://returns.readthedocs.io/en/latest/pages/result.html Ruff FAQ: https://docs.astral.sh/ruff/faq/ https://docs.astral.sh/ruff/faq/
aliyome 9mo ago
In the Cents example, why are they using throw instead of Result?

158 points by rastrian 9mo ago

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.

conartist6 9mo ago
You don't need a strong type system or even really ANY compile-time type system for this strategy to work! I use all these techniques in plain JS and I can still get the benefits of correct-by-construction code style just by freezing objects and failing fast.
- bdangubic 9mo ago
  godspeed with that :)
- agumonkey 9mo ago
  Is this a methodology you use at work or only for personal projects ? I'm curious how common this culture is among companies/teams.
  - conartist6 9mo ago
    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), and 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. The result is that I'd expect that it would only be a handful of days learning the mental model for the codebase before the average person would find it far easier to read the JS code as opposed to TS code, thanks to the lower amount of visual clutter. I also ship code super fast. When I find bugs I just fix them on the spot. When I find variables named wrong, I just rename them. The result that I often smash bugfixes and features and cleanup together and have a messy git history, but on the flip side you'll never find bugs or naming deceptions that I've left sitting for years. If something is wrong and I can reproduce it (usually easy in functional code), the debugger and I are going to get to the bottom of it, and quickly. Always and only forward!
    - conartist6 9mo ago
      I should add a few more things: much of how I got here was exposure to Facebook's culture. Move fast and break things. React with prop types. Redux. Immutable.js. I did UI there on internal tools for datacenter operators and it was a drinking-from-the-firehose experience with exposure to new programming philosophies, tools, and levels of abstraction and refactoring velocity beyond anything I had previously encountered. Problems which in other companies I had learn to assume would never be resolved would actually consistently get fixes! Well, at that time. This was before the algorithm was fully enshittified and before the disastrous technopolitical developments in the way facebook and facebook messenger interact with each other. Perhaps the most direct inspiration I took from there though was from the wonderful "opaque types" feature that Flow supports (https://flow.org/en/docs/types/opaque-types/ https://flow.org/en/docs/types/opaque-types/) which for reasons known only to Hejlsberg and God, Typescript has never adopted; thus most people are unfamiliar with that way of thinking.
      - auggierose 9mo ago
        Yes, I am wondering if opaque types would be difficult to implement somehow in TypeScript? It should really be part of TypeScript if at all reasonably possible.
        conartist6 9mo ago
        I'm not that familiar with the TS internals. They'd have to add a keyword to the language which could break stuff. The smart move would be to reserve the `opaque` word a few versions in advance of introducing the feature that gives it a meaning
        auggierose 9mo ago
        I don't think the keyword is the problem, I am wondering more about the internals of their type inference algorithm.
    - chrisoverzero 9mo ago
- keyle 9mo ago
  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.
  - zephen 9mo ago
    > The best argument for dynamic types systems, is enjoying debugging in production. This comment is either severe snark or severe ignorance.
    - keyle 9mo ago
      Please, do elaborate... If you remove passes of a compiler, you, looking at it whilst running, are the compiler.
      - 2colours 9mo ago
        It's a bit ironic that now we went down the static rabbit hole so much that we don't realize it's more the opposite: by adding more to your language and compiler to enforce static checks, you turn the compiler itself more and more into a runtime that you are just going to run ahead of time, according to a potentially vastly different set of rules compared to your real runtime. There is no reason why you couldn't do something like this by will but it's just not worth it after a certain point clearly.
      - conartist6 9mo ago
        I agree. So I write tests. I use architecture to defend against the risk of super-rare code paths where I wouldn't rapidly notice if they broke. I dogfood so I find prod bugs before users do. None of this seems that new. Even people who write TS code still write tests and still ship bugs and still have to think about good architecture patterns, like the ones in the linked post.
aag 9mo ago
Thank you for saying that. I regularly attend the International Conference on Functional Programming, which grew out of the LISP and Functional Programming conference. Except for the Scheme Workshop, which is the reason I attend, it might as well be called the International Conference on Static Types. 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. The types are all that anyone talks about.
- rastrian 9mo ago
  I get your point about ICFP drifting into “types, types, types.” I don’t think FP benefits are only static typing or immutability, pure-ish core/imperative shell, and explicit effects matter a lot even in dynamic languages. My angle was narrower: static types + ADTs improve the engineering loop (refactors, code review, test construction) by turning whole classes of mistakes into compiler errors. That’s not “what FP is”, it’s one very effective reliability layer that many FP ecosystems emphasize.
  - brabel 9mo ago
    Static types and ADTs are orthogonal to being FP, as Rust clearly shows. But to speak in terms of FP when those are the important things for you is just wrong since even non FP languages now have ADT, including also mainstream languages like Java, Kotlin, Dart, C# and more. Even purity is not something exclusive to FP, D and Nim also support separating pure from impure functions. And if you ask me, the reason not many other languages have support for that is that in practice, it has been demonstrated again and again that it’s just not nearly as useful as you may think. Effects, as in Unison and Flix, generalizes the concept to include many more concepts than just purity and may perhaps prove more useful in general purpose programming, but the jury is still out on this.
    - yunnpp 9mo ago
      Help me with a tl;dr here, but are effects just monads?
acdha 9mo ago
Yeah, I know Rust isn’t everyone’s favorite but I’d expect at least some awareness that we’ve seen a lot of reliability improvements due to many of these ideas in a language which isn’t focused on FP. I ended up closing the tab when they had the example in TypeScript pretending the fix was result types rather than validation: that idea could be expressed as preferring that style, an argument that it makes oversights less likely, etc. but simply ignoring decades and decades of prior art suggests the author either isn’t very experienced or is mostly motivated by evangelism (e.g. COBOL didn’t suffer from the example problem before the first FP language existed so a far more interesting discussion would be demonstrating awareness of alternatives and explaining why this one is better).
- galangalalgol 9mo ago
  Rust certainly isn't a pure fp language, but the borrow checkerbl is a lot kinder when you use fp style.
  - acdha 9mo ago
    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.
    - rastrian 9mo ago
      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 delivers major reliability wins via making invalid states harder to represent (enums, ownership/borrowing, pattern matching). That’s not “FP-first,” but it’s very compatible with functional style and the same invariants story. If the TS example came off as “types instead of validation,” that’s on me to phrase better, the point wasn’t “types eliminate validation,” it’s “types make the shape explicit so validation becomes harder to forget and easier to review.”
saghm 9mo ago
I've seen it pointed out that the main point of functional programming is immutability, and that the benefits mostly flow from that. I haven't really learned much of any lisp dialect, but my (admittedly fuzzy) general perception is that this is also the preferred way to work in them, so my guess is that's where the benefit in reliability might come from.
- zelphirkalt 9mo ago
  Correct. If things are mutable, then in most languages, there can be spooky action at a distance, that mutates some field of some other object or does so indirectly via some calls. This then can change how the thing behaves in other circumstances. This style of programming quickly becomes hard to fully grasp and leads to humans making many mistakes. Avoiding mutation therefore avoids these kinds of faults and mistakes.
adamddev1 9mo ago
I worked through https://htdp.org https://htdp.org (which uses untyped Racket), and funny enough, that's what really for me thinking about type driven development. The book gets you to think about and manually annotate the types coming in and out of functions. FP just makes it so natural to think about putting functions together and thinking about the "type" of data that comes in and out, even if you're using a dynamically typed language.
rastrian 9mo ago
Agreed, I conflated FP with “typed FP.” My claim is mainly about static types + ADTs/exhaustiveness improving refactors/review/tests. Racket can get FP benefits, but absent static typing you rely more on contracts/tests (or Typed Racket), which is a different reliability tradeoff.
mightybyte 9mo ago
The term "functional programming" is so ill-defined as to be effectively useless in any kind of serious conversation. I'm not aware of any broadly accepted consensus definition. Sometimes people want to use this category to talk about purity and control of side effects and use the term "functional programming" to refer to that. I would advocate the more targeted term "pure functional programming" for that definition. But in general I try to avoid the term altogether, and instead talk about specific language features / capabilities.
- jghn 9mo ago
  > The term "functional programming" is so ill-defined as to be effectively useless in any kind of serious conversation. This is important. I threw my hands up and gave up during the height of the Haskell craze. You'd 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. Similar to you, now I talk about specific patterns and concepts instead of calling a language functional. Also, as so many of these patterns & concepts have found their way into mainstream languages now, that becomes even more useful.
  - agumonkey 9mo ago
    to add a grain of salt, some of the lisp world is not functional, a lot of code is straight up imperative / destructive. but then yeah a lot of the lisp culture tended to applicative idioms and function oriented, even without the static explicit generic type system of haskell.
    - jghn 9mo ago
      Sure, but that's part of my point in agreeing that definitions of "functional programming" are muddy at best. If one were to go back to say 1990 and poll people to name the first "functional programming" language that comes to mind, I'd wager nearly all of them would say something like LISP or Scheme. It really wasn't until the late aughts/early teens when that started to shift.
mbac32768 9mo ago
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.

henning 9mo ago

I like good type systems, too, but they won't save you from bugs that are better addressed by fuzz testing, fault injection testing and adversarial mindset shifts.

saghm 9mo ago
Luckily these aren't exclusive! You can do all of those things with a strong type system as well, and get the benefits of all of them.
- z0ltan 9mo ago
  [dead]
- rastrian 9mo ago
  100%. Types don’t replace fuzzing, property tests, chaos, or adversarial thinking. They just move one slice of bugs from runtime to compile time and make refactors safer. In hindsight I should have positioned types/ADTs as one layer in the reliability toolbox, not the toolbox.

charcircuit 9mo ago

>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 businesses require fault tolerance to be supported. The real world is messy, there is always going to be faults, so investing heavily into correctness may not be worth it compared to investing into fault tollerance.

discarded1023 9mo ago
You'd like to know your fault tolerance is reliable and possibly even correct.
- charcircuit 9mo ago
  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.
  - rastrian 9mo ago
    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.
    - nickpsecurity 9mo ago
      You can also argue that debugging time can be expensive but static checks reduce debugging. This is much more true when it's concurrency errors.
    - 9mo ago

wewewedxfgdf 9mo ago

I'm wary of absolute statements about programming.

ggm 9mo ago
I want to be a contrarian and argue with this, but my daily praxis is generally to take a betteridges law approach to most argumentative absolutes and also false dichotomous headlines and question them. Reading the other comments to the effect that the conferences are now strong typing gabfests and insufficiently about FP per se reinforced this feeling. Reliability should be simpler with FP but so much depends on correctness of the runtime and IO. Erlang and the "run correctly or die" comes to mind as well. The system is either working or is off. When being off is fatal, Erlang seems to shrug and say "maybe next karmic cycle" maybe this too is a better approach?

d--b 9mo ago

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 cases. It is more reliable if you can do it, but large systems have way too many failure points to be able to handle them all in a way that is practical.

zelphirkalt 9mo ago
If you have strong types, it is still possible to make a mutable thing, that will be mutated from the other end of the program and that will introduce bugs, that can be hard to find. If you are doing FP on the other hand, at least change always results in new objects, with structural sharing at most. This excludes a whole category of bugs.
- Jensson 9mo ago
  > If you are doing FP on the other hand, at least change always results in new objects, with structural sharing at most. This excludes a whole category of bugs. Not if you program it with a mutable god object to mimic creating a new big state, then you have exactly the same kind of issues. The issue is if you try to program a transaction flow using object oriented programming, that is not very good, and most work programmers do revolves around involves flows. But when it doesn't then functional programming isn't a very good or reliable solution.
  - zelphirkalt 9mo ago
    > Not if you program it with a mutable god object to mimic creating a new big state, then you have exactly the same kind of issues. Have you done any FP? That's not how you do FP.
breadwinner 9mo ago
> that tends to get in the way of complex error handling. Agree. In Java, Streams allow you to process collections in a functional style. This feature enables concise, expressive data manipulation with operations like map, filter, and reduce. Some people point out that Java's checked exceptions spoil the simplicity and elegance of Streams by forcing you to handle exceptions. But that's not a reason to not have checked exceptions, it is a reason to not do functional style composition when methods can throw exceptions. Streams was invented for collections, which tend not to throw exceptions. If proper error handling is important don't do Streams.

cubefox 9mo ago

I think there is a strong case that ADTs (algebraic data types) aren't so great after all. Specifically, the "tagged" unions of ADT languages like Haskell are arguably pretty clearly inferior to the "untagged" unions of TypeScript or Scala 3. Because the latter actually behave like a logical "or" rather than an artificial construct that needs to be wrapped and unwrapped.

jesse__ 9mo ago
> "tagged" unions of ADT languages like Haskell are arguably pretty clearly inferior to the "untagged" unions of TypeScript dude .. wut?? Explain to me exactly how this is true, with a real world example. From where I stand, untagged unions are useful in an extremely narrow set of circumstances. Tagged unions, on the other hand, are incredibly useful in a wide variety of applications.
- cubefox 9mo ago
  Example: Option<> types. Maybe a function returns an optional string, but then you are able to improve the guarantee such that it always returns a string. With untagged unions you can just change the return type of the function from String|Null to String. No other changes necessary. For the tagged case you would have to change all(!) the call sites, which expect an Option<String>, to instead expect a String. Completely unnecessary for untagged unions. A similar case applies to function parameters: In case of relaxed parameter requirements, changing a parameter from String to String|Null is trivial, but a change from String to Option<String> would necessitate changing all the call sites. > From where I stand, untagged unions are useful in an extremely narrow set of circumstances. Tagged unions, on the other hand, are incredibly useful in a wide variety of applications. Any real world example?
  - rastrian 9mo ago
    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<T> (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 failure mode is “it compiles, but someone forgot the check.” In practice, once the union has more than “nullable vs present”, people converge to discriminated unions ({ kind: "ok", ... } | { kind: "err", ... }) because the explicit tag buys exhaustiveness and avoids ambiguous narrowing. So I’d frame untagged unions as great for very narrow cases (nullability / simple widening), and tagged/discriminated unions as the reliability default for domain states. For reliability, I’d rather pay the mechanical churn of Option<T> during API evolution than pay the ongoing risk tax of “nullable everywhere. My post argues for paying costs that are one-time and compiler-enforced (refactors) vs costs that are ongoing and human-enforced (remembering null checks).

whateveracct 9mo ago

> 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.

stingraycharles 9mo ago
Honestly, as someone else who does a lot of data plumbing, there is so much FTP servers with excel sheets being used as the means for official clearance processes. There are constant data bugs in the feeds provided by major exchanges, market makers, etc, and so many iffy business rules that are basically all encoded in 100+ tab excel sheets. Maybe this article focuses on a very specific niche of banking, but most of it is tied together with FTP and excel sheets. I think the author would be shocked just how flaky a fundamental banking protocol like SWIFT is.
- rastrian 9mo ago
  I’ve worked in Brazilian banking stacks that were literally FTP + spreadsheets for years. So yes, the ecosystem is often messy and protocols can be flaky. That’s exactly why I argue for stronger internal modeling: when the boundary is dirty, explicit state machines/ADTs + exhaustiveness + idempotency/reconciliation help ensure bad feeds don’t silently create invalid internal states.
  - whateveracct 9mo ago
    I totally agree as a fellow fintech engineer. It was a battle getting approval for all that from Product for us. While we were battling for it, we rushed multiple projects without literally any of it. And then spent a year+ each time cleaning up the mess.
    - brabel 9mo ago
      And your pockets were being filled in that year while you were just doing cleanups. Mission accomplished.

thundergolfer 9mo ago

All the line items are decent things, worth doing, but the claim about how much following the line items would improve reliability is super exaggerated. > [Most production incidents] are due to the code entering a state that should never have been possible. I have never seen evidence that this is even remotely true, and I've been looking at software reliability research in the last few months. Instead, 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. 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. > Arguments that these degraded conditions should have been recognized before the overt accident are usually predicated on naïve notions of system performance. System operations are dynamic, with components (organizational, human, technical) failing and being replaced continuously. — https://how.complexsystems.fail/ https://how.complexsystems.fail/

int08h 9mo ago
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 enters an "unsafe state" (your words) or a "state that should never have been possible" (OP's words). "Unsafe state" and "state that should not have been possible" are, in practice in a real system, the same practical thing. I suspect you both would agree "system confuses a string for an integer and acts based on erroneous value" or "system acts on internal state that indicates the valve is both open and closed" would be states that a system should not be in. Outside pedantry, your descriptions are practically synonymous with each other.
- thundergolfer 9mo ago
  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 safe condition Those are very different goals.

FpUser 9mo ago

Yet another silver bullet.

rastrian 9mo ago
Fair pushback. I agree the title and a couple of lines overshoot. My intent isn’t “FP is a silver bullet” or “types replace operational reliability”

pizlonator 9mo ago

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. - There's no hard evidence that static typing improves reliability. Only vibes and feels.

dionian 9mo ago
It improves reliability at compile time, certainly
ux266478 9mo ago
> There's no hard evidence that static typing improves reliability. I'm curious how you came to that conclusion? https://pleiad.cl/papers/2012/kleinschmagerAl-icpc2012.pdf https://pleiad.cl/papers/2012/kleinschmagerAl-icpc2012.pdf https://www.deepdyve.com/lp/springer-journals/an-empirical-study-on-the-impact-of-static-typing-on-software-0ZImQZ508o https://www.deepdyve.com/lp/springer-journals/an-empirical-s...
- rastrian 9mo ago
  I was searching for the Stefik article to argue here, thank you.
- pizlonator 9mo ago
  I don't consider a human subjects study to be "hard evidence". So, we can safely disregard these papers. They got exactly the result that they sought out to get, and the papers were published because they confirmed the preexisting groupthink.
  - rowanG077 9mo ago
    Interesting, so you consider the entire scientific field of medicine to work without hard evidence?

websiteapi 9mo ago

A few mention on tests, but I expected more. The main value of pure functions is that now their behavior is representative in tests. In fact, I'd argue that all you need for reliability is determinism and tests of all equivalent scenarios. functional programming (and immutability) are only helpful to the extent that it's easier to have representative tests, but not necessarily required.

rastrian 9mo ago
Agree, I didn’t give testing enough space. A proper treatment would’ve doubled the post, so I’m writing a separate follow-up on testing. Pure functions/immutability help a lot because tests become representative and cheap. I’d only push back on “tests of all equivalent scenarios” being sufficient, the space explodes and many real failures live at I/O/concurrency/distributed boundaries. My intended claim is that FP/ADTs/types reduce the state space and improve the ROI of tests, not replace them.
xpe 9mo ago
> In fact, I'd argue that all you need for reliability is determinism and tests of all equivalent scenarios. Any insights as to how to get effective determinism without pure functions? Pure functions win here because we only have to reason about the function arguments. Reasoning is easier when you have to less of it! Without pure functions, the state space explodes, because anything anywhere could have a side-effect — madness, I say! — so how would you figure out equivalent states? Special case inspection I suppose? There is a continuum between "anything goes" and "pure functions". From a certain light, all the varieties of encapsulation can be seen as explorations of this theme. (An idea: perhaps there are languages where side-effects can be circumscribed in ways that don't rely on the high bar of pure functions?) The arguments against pure functions appear to be somewhat contingent: current adoption levels, practice, convenience, and taste. Things that are contingent have a way of changing over time as new methods emerge and new values take hold. I don't hold shallow human preferences in high regard. As an example, many humans and organizations in practice trade security for convenience, at significant cost — especially when that cost is external to them. At the same time, onerous tasks encourage work-arounds. This is the crux of it I think: unless people perceive the value of pure functions (to do what they want to do), some will seek shortcuts. So we need some combination of (1) making them easier to work with; (2) motivating people to aspire to higher principles; namely, high quality software that does not open to door to exploitation, misuse, botnets, etc; and/or (3) internalize the external costs. As an example of (3), if people and companies faced predictable and commensurate costs when their flawed software inflicts harm on others, they would be more inclined to care about correctness.

jatins 9mo ago

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

wiseowise 9mo ago
Modern Java supports everything in the blogpost, so nothing stops AWS from adopting the style.
- rastrian 9mo ago
  I really don’t like the argument calling “industrial usage” just because a main company or FAANG aren’t using the tech stack, but arbitrary under the hood are doing basically the same stuff with internal toolings that should be entirely under the language features, not under a system design library. But your take about modern Java is correctly, and they adopt this style under internal projects for some workflows.

jschrf 9mo ago

Tup: Use interface for structural types in TypeScript, not type.

tasuki 9mo ago

I'm impressed by the author having made so many sensible choices in their life, yet marrying their blog content to GitHub issues.

rastrian 9mo ago
lmao

mightybyte 9mo ago

Was just talking with someone the other day who used to write Haskell professionally but is now using Python. He said that in his experience when there are bugs the "blast radius" is much larger in a dynamic language like Python than in a static language like Haskell. That has been my experience as well. Something I haven't seen talked about, though, is how powerful the type system is for constraining LLMs when using them to generate code. I was recently trying to get LLMs to generate code for a pretty vague and complex task in Haskell. I wasn't having much luck until I defined a very clear set of types and organized them into a very clear and constrained interface that I asked the LLM to code to. Then the results were much better! Sure, you can use these same techniques in less strongly typed languages like Rust, and you can probably also use a similar approach in dynamically typed languages, but Haskell's pure functions allow you to create much stronger guard rails constraining what kinds of code the LLM can write.

Jeff_Brown 9mo ago
Amen. I've been coding a big hobby project in Rust since July, after having spent years using Haskell for such things. I chose Rust because the primary DB I wanted to use (TypeDB) only had drivers for Rust and Python at the time. Rust is popular relative to Haskell, so I thought others might be more likely to sign on, and the type system seemed almost as expressive. But since purity is not encoded in Rust's type system, any function might do any kind of IO -- in particular, read from or write to disk or one of the DBs. That makes the logic much harder to reason about. (Also, Rust's syntax is so noisy and verbose that it's harder to see what's going on, and less context fits in my head at one time. I'm getting better at paying that cost, but I wish it weren't there.) I can't say I made the wrong decision, but I often fantasize about moving most of the logic into Haskell and just calling Rust from Haskell when I need to call TypeDB from Rust.
- yobbo 9mo ago
  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.

xpe 9mo ago

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/ https://cliffle.com/blog/rust-typestate/ [2]: https://www.reddit.com/r/rust/comments/17l8eez/is_there_any_other_language_that_do_type_state/ https://www.reddit.com/r/rust/comments/17l8eez/is_there_any_...

zozbot234 9mo ago
The type-state pattern is really just OOP implementation inheritance in a type-theoretic trench coat. The relevant difference is simply that most uses of type-state are not trying to span multiple modules like the OOP design approach does; the "state" variations are contained such that they don't impact modularity throughout the program, unlike the OOP inheritance approach.

northlondoner 9mo ago

Yes.

beders 9mo ago

Most of the musings on enforcing invalid states with ADTs are impractical when working with real data that needs runtime validation when it enters the system. Using a schema/spec/type library at runtime that is even more powerful than ADTs is a better investment - or to be less controversial - is an additional investment on top of types. Yes, it means the compiler can't help you as much, but who has time waiting for a compiler anyways ;) I find the "make illegal state unrepresentable via types" idea great for software that needs to fly a plane, but for enterprise software not so much. The cost/benefit is not justifiable.

fud101 9mo ago

Of course you can do this with Typescript but what about Python if you're stuck using it for $dayjob. Any tips?

rastrian 9mo ago
You can get most of the “ADT/state-machine reliability” benefits in Python by combining static checking + tagged unions + boundary validation: Model states as tagged unions (Union + Literal + dataclass(frozen=True)), use match (Py3.10+) and add assert_never so type checkers complain when you forget a case. Run Pyright (strict) or mypy –strict in CI so “illegal states” show up as build failures, not incidents. Validate/parsing at boundaries (HTTP/queues) with Pydantic discriminated unions (tagged unions at runtime), then keep internals typed. For expected failures, prefer an explicit Result (e.g., returns) over exceptions-as-control-flow. Use Ruff for lint/consistency (it’s not a type checker, but pairs well with one). References here: Pyright: https://microsoft.github.io/pyright/ https://microsoft.github.io/pyright/ mypy --strict: https://mypy.readthedocs.io/en/stable/getting_started.html https://mypy.readthedocs.io/en/stable/getting_started.html PEP 634 (match): https://peps.python.org/pep-0634/ https://peps.python.org/pep-0634/ assert_never & exhaustiveness guide: https://typing.python.org/en/latest/guides/unreachable.html https://typing.python.org/en/latest/guides/unreachable.html typing_extensions (backports): https://typing-extensions.readthedocs.io/ https://typing-extensions.readthedocs.io/ Pydantic discriminated unions: https://docs.pydantic.dev/latest/concepts/unions/ https://docs.pydantic.dev/latest/concepts/unions/ returns Result: https://returns.readthedocs.io/en/latest/pages/result.html https://returns.readthedocs.io/en/latest/pages/result.html Ruff FAQ: https://docs.astral.sh/ruff/faq/ https://docs.astral.sh/ruff/faq/

aliyome 9mo ago

In the Cents example, why are they using throw instead of Result?