The general value of typed functional programming lies in leaving no edge cases

For example, say you have a pandas dataframe with a column "foo" and you accidentally try to read column "fooo". Instead of getting a useful exception like "PandasException: Attempted to read nonexistent column 'fooo'", you get a traceback 10 layers deep, terminating in something like "pandas.hashtable.PyObjectHashTable.get_item" which ought to be totally invisible to you, the library user.

Maybes explicitly express what the programmer has foreseen, exceptions form a safety net over it. You need both in a wholesome language. That's wht even Haskell has exceptions.

I'm not sure that's such a bad thing. Exception handling doesn't mean you should be handling all exceptions, just that you can recover if one does occur. If an exception is 100% relevant to what you're doing then yes absolutely handle it, or even clean up your own state before propagating the exception if you can't. But please don't catch any and all exception to suppress or obfuscate them by wrapping it in another domain specific exception.

But from my understanding, this is not directly related to the borrow checker, which tracks who owns a reference and is allowed to modify it or not.

(That being said if you had a "default" case earlier, the compiler won't complain)

I don’t know of any mainstream language that has bolted on that level of verification.

If you wish to reduce "leakiness", you can dispatch on the null-ness of the variable; Swift lets you write `if let x = x { /* x is non-optional in here * / }`, which binds a non-optional value inside the braces, and `guard let x = x else { return } /* x is non-optional now * /` which binds a non-optional value after the braces. So as soon as you consume an optional value, you are free to "un-leak" it and extract its value (if it has one) immediately.

For example consider a network response that in a JS app might be passed around as an opaque object. In a language like Swift this is infeasible, you have to transition from the network serialized version to concrete models at the network layer. If you encounter mismatches in the expectation of what is optional you have to handle it here at the edge of the program. This enables massively safer code and makes reasoning about your program much simpler if anything.

As a concerete example say an API response tells you if a user is verified(for some domain specific definition of "verified"), additionally you want to know when they were verified maybe to give them a hint when they need to do it again. You coudl model this as:

    {
      "verified": false,
      "verified_at": null
    }

    {
      "verified": true,
      "verified_at": "2020-02-24T15:31:12Z"
    }

In Swift this would then be modelled as

    struct Users {
        let verified: Bool
        let verifiedAt: Date?
    }

    {
      "verification_status": {
        "status": "unverified"
      }
    }

    {
      "verification_status": {
        "status": "verified",
        "at": "2020-02-24T15:31:12Z"
      }
    }

    enum VerificationStatus {
        case unverified
        case verified(Date)
    }

    struct User {
        let verificationStatus: VerificationStatus
    }

  # where R is some r such that Num r
  let huge = <the largest (finite) value in R>
  let inf = huge * huge  # can't be finite unless you
  # truncate or saturate or something
  let nan = inf - inf  # can't be either of
  # infinite (infinitely < +inf and > -inf), or
  # finite (catastrophic rounding errors)

https://wiki.haskell.org/Introduction#Quicksort_in_Haskell

I deliberately didn't go into the specifics about the various typeclasses at play and their laws, and how those are tested. Part of that is just for reasons of time, but the more salient reason is that I wanted to show how those of us who do purely functional programming do it in practice. So if you watched the presentation, you saw that most of my thinking was about "OK, how do I elaborate from the most trivial transformation (do nothing at all) to the one I really want?" And that proceeds compositionally: I transform this value to that value. OK, does that value have the right type? No? What do I need to do to ensure that it does? And the transformation steps have some important properties, like their scope being entirely local. I really tried to emphasize this at the end with `attemptRepeatedly`: my description of each line of the whopping three lines is exhaustive. When I say there's no point in writing a test for it, I mean that literally. There certainly are typeclasses at play, and I briefly talk about the `Catchable` typeclass, and show the ScalaDoc for it, which documents an important law: the relationship between catching ambient exceptions and the algebra provided by `Catchable`. I rely on the other typeclasses and other laws in a similar fashion.

The other thing I think is pretty important is the part where I say "Let's look at cases," because the point there is that I can reason about the code by reasoning about the shape of the data it's manipulating. So if a `step` is an `attempt` of `p` that, if successful, `kill`s the retry `schedule` or, if unsuccessful, logs the exception, I'm still dealing with a `Process` of one element (by assumption that `p` will emit one element). Then `retries` will be a `Process` of 0 to infinity elements, because we put no constraints on `schedule`. So `(step ++ retries)` will be one or more elements, and because `step` `kill`s `schedule` on success, because `retries` is derived from `schedule`, `retries` is also `kill`ed. So `(step ++ retries)` is a `Process` that will emit one or more elements, with the last element being the first successful one, or the last failed element if none of the `retries` succeeds, so we take `last`. Then we just `fold` the failure or value back into a single effect, and we're done.

As I discuss in the presentation, there certainly are questions. What happens if the `schedule` is empty? What happens if the `schedule` is infinite? An attendee in Q & A asked a really good question: was I sure `retries` would wait before the first retry, or was the semantics "try, then wait?" (It really is the former, but that wasn't clear from my recorded REPL session.)

Of course, this isn't very impressive for a three-line example, although I think it's pretty striking that it only takes three lines, each of which can be completely reasoned about independently, to achieve a pretty significant operational goal. The point, though, is we can build entire systems this way, and in fact `attemptRepeatedly` is part of a distributed monitoring system I worked on at Intel Media/Verizon Labs, which is written entirely in this way apart from the monitoring types themselves, which present an imperative API for familiarity's sake (and which we later came to regret).

I hope this helps!

It means you operate on a higher level of abstraction, and that inherently makes reading code faster. Not per line of code, but certainly per functional unit.

Idiomatic Rust tends to use a lot of functional code, and provides all the tools to make that safe. Its map function could mutate the input -- it would be unidiomatic, but certainly possible -- except that, if you don't pass a mutable reference, then you're safe to assume it won't.

while (my ($index, $value) = each @list) { ... }

https://docs.raku.org/routine/kv#class_List

for @list.kv -> $index, $value { ... }

   map someFunction listOfValue

   map someOtherFunction (zip [0..] listOfValues)

Just change your loop to auto& x.

This does not invalidate your experience. It's common, and with good reason. This sort of dissimilar experience with the same code is why coding standards need to be views as social norms for the team using them, and not just technical things.

I moved from first camp to the second one somewhere during my adult life. And IMO: Both are valid, sometimes first one is necessary (because that's how the machines actually work), but second one is clearly better most of the time for humans, especially in business-logic heavy cases.

Or you can use types where it's enforced by the compiler.

But it may be a very interesting question for a researcher.

Sometimes safety equipment lets you go faster.