It sucks when you have to use it for everything, but it's a useful enough technique that most Haskell datatypes come with functions that provide exactly this conversion to church encoding.

See eg 'maybe' (https://www.stackage.org/haddock/lts-18.18/base-4.14.3.0/Pre... on stackage) or foldr for lists.

'foldr' is interesting, because it encapsulates a recursive pattern matching on lists. For the non-recursive version, see 'uncons' composed with 'maybe'.

Which is exactly why I said:

> I cannot wait for the Result monad.

Generics make this possible, and will be a huge improvement to Go's error handling.

I'm not saying it will solve everything, but it's a huge step nonetheless.

Depends on how generic you want this.

In Haskell, you can have functions that work generically over option-types, error-able types, lists, functions, tuples, etc.

In Rust, you have to specifically implement functionality for all of these.

But eg your 'map' function in Rust still works for all lists, no matter what item type. In Go before this change, you had to write a different map function for each item type that could be in your list.

In Haskell, the same 'map' function works for lists, functions, error-able types etc.

That's actually a problem in Erlang.

In Haskell, 'Maybe (Maybe Int)' is a different type from 'Maybe Int'.

That means that when you use eg a hash table that returns some kind null value like 'Nothing' on lookup when a key is not found, you can still stick exactly that kind of null value as a normal value into the table and everything will turn out fine.

The comparison here is with go.

Unwrap would look like:

    file := os.Open("foo").Unwrap()

I'll take that over the current go state of the art:

    file, err := os.Open("foo")
    if err != nil {
        panic(err)
    }

Just like "panic(err)" is used infrequently, "unwrap" would be used infrequently. They're comparable, and for the cases where unwrap is okay (test code, once-off scripts, etc), I'd definitely prefer it to the panic boilerplate.

I use rust and my code does not have .unwrap() (and definitely not .unwrap().unwrap()) in it either. That's what the ? operator is for.

this is nice, especially for the function clauses

Elixir is my daily drive and working in Java made me miserable until I started working around the lack of pattern matching facilities

Error handling is the worst part, I think a simple

  switch (retval) {
    Ok(val):
       ...
       break;
    Error(err):
       ...

would make Java much more pleasant, even without full pattern matching everywhere.

Not so much a nitpick because with checked exceptions your method signature can declare multiple types of exception whereas Result generalizes your specific exceptions to Throwable, which you can't pattern match with the compiler being able to enforce exhaustiveness.

So to achieve the same exhaustiveness as a method like

User createUser() throws IOException, BusinessException

you would need both a Result-like construct and union types

Either<User, IOException | BusinessException> createuser()

which few mainstream languages offer. Otherwise you type is unable to express that only IOException and BusinessException are thrown and you don't need to handle a default Throwable case.

This is only the case for "checked" exceptions though; the important part about the Result type in Rust is that it won't implicitly propagate errors if you try to just use the success value but instead will give a compiler error. I don't code much Java, but my impression is that standard library methods throwing unchecked exceptions is far more common than panicking, the closest equivalent is in Rust.