Yeah, I don't know why Prelude.head doesn't return a Maybe. Anyway, the point stands.

• In Java forgetting to check for null will crash your program.

• In C, forgetting to check for NULL will lead to undefined behavior.

• In Haskell, you either have to (a) check for Nothing, or (b) explicitly say "crash the program if this is Nothing" by using a function like fromJust or head, which internally does (a). This is always an improvement over C, and often an improvement over Java.

Side note: I like Rust's convention of consistently naming these might-crash-your-program methods "unwrap" and "expect".

Yeah I think rust has better defaults here.

I get the choice. It's unintuitive for basic types to be wrapped in a maybe mondad. People expect addition, subtraction and division to return numbers. To have division be the only operation to return an optional is a bit off.

I get the choice of why it wasn't done with haskell even though I disagree with it.

You cannot have a null exception in haskell.

Yes, I'm aware of that 1/0 returns an exception.

I'm saying that it makes sense to use nulls because 1/0 is an undefined operation. Therefore to represent the output of 1/0 with a null makes sense. So the existence of nulls makes sense. That is not haskell code I'm typing up there. "1/0 = undefined" is not code.

If you read my reply you will see that my statement isn't referring to an exception caused by 1/0. It's actually referring to a null exception which is completely different.

I am explicitly saying that the "null" in haskell is part of a sum type (the maybe monad) and in that case the "null" or nothing will be handled with no run time errors. You cannot have a null exception in haskell.

Never did I say Haskell has no runtime errors, and 1/0 is not an exception caused by a null. Please analyze and reread my statement.

Isn't that just due to `head` being a non-total function?

Nothing to do with null per se.

Well, Haskell calls the empty list the "null" list (see List.null), so I could say that List.head crashes when it encounters a null. :P

Anyway, the real lesson is that even if your language has sane defaults that force you to check that your list isn't empty, or that your pointers aren't null, a bad library function like List.head can hide that check away from you and crash anyway, bringing you back to square one in terms of the type system preventing unexpected crashes.