Add article about Maybe and Result

[lukewestby]

At the suggestion of @mgold and with assistance and suggestions from members of the community I'm pleased to submit for your review "Where did null and undefined go?" as a primer for how Maybe, Result, and other union types help us communicate concepts like emptiness and success/failure in a type-safe and reliable way.

Let me know what you think!

[mgold]

This looks really good! I'm going to merge regardless but here are a few things I'd like to see called out explicitly.

• You do a good job talking about how we must explicitly deal with optional values. I'd like the other side mentioned: everywhere there isn't a Maybe, you will definitely have the value you asked for, so the rest of the language becomes reliable without being littered with null checks.
• Maybe is a data structure. It just so happens to hold at most one element. This is key to understanding why map, andThen and other list-like functions are also available for Maybe. I think these functions, and withDefault, should get a bit more attention.
• When talking about the naive translation of a node callback to Elm, you can mention that nothing says you must receive exactly one Just and one Nothing. There are two bogus cases, further reason not to use that pattern.
• "dat is an instance of a MyData type" - First, typo on dat. Second, this is OO language. Use "is a value of type MyData" instead.

As an overall comment... it seems very "salespitchy". A lot about reliability, how great Elm is, in between "here's what this thing is and how to use it".

I'm really grateful for the contribution and I'm not going to turn it down. (It helps that, unlike libraries which get released and commit to semvar, these essays can be updated whenever.) So I'll let you folks mull over this feedback and merge when you're satisfied.

[lukewestby]

You do a good job talking about how we must explicitly deal with optional values. I'd like the other side mentioned: everywhere there isn't a Maybe, you will definitely have the value you asked for, so the rest of the language becomes reliable without being littered with null checks.

I'll make sure to give equal mention of that aspect

Maybe is a data structure. It just so happens to hold at most one element. This is key to understanding why map, andThen and other list-like functions are also available for Maybe. I think these functions, and withDefault, should get a bit more attention.

I think I'll move the discussion of Maybe in terms of Elm-specific constructs into a separate section and include this content there as well.

When talking about the naive translation of a node callback to Elm, you can mention that nothing says you must receive exactly one Just and one Nothing. There are two bogus cases, further reason not to use that pattern.

Great point, I'll add it!

"dat is an instance of a MyData type" - First, typo on dat. Second, this is OO language. Use "is a value of type MyData" instead.

Oops! The conditioning from my C# experience hasn't totally left my mind it seems.

As an overall comment... it seems very "salespitchy". A lot about reliability, how great Elm is, in between "here's what this thing is and how to use it".

I started getting that impression as well toward the end of writing it. I'll see if I can tone it down and make it more about the comparison to JavaScript and other languages with null.

Thanks for your feedback @mgold!

[mgold]

You're welcome! Looking forward to seeing the revisions.

[lukewestby]

@mgold I addressed all of your specific points directly, and in the case of being sales-pitch-like I just searched for the term "reliable" and adjusted the language in those places.

[mgold]

:heart_eyes: