Thread by @mapastr

Today I'm going to #rant about #haskell libraries. I'm a Haskell supporter, I think it's a great language, but that doesn't mean it doesn't have problems. Some of them are surprising and I want to talk about them.

At the end of the rant I will have tips for developers using Haskell and for libraries developers (in any language, some rules are universal) so bear with me. It's a long rant but there is a good ending ;).

A preamble first: one of the reasons why I decided to study haskell is because haskell had a good way to deal with errors and invalid inputs/states.

I remember the "Eureka" moments when I realized that the result of a function could contain the errors and the implications this had. I mean, just the readability and the ability to refactor was enough, but there was much more. There was composability. I had a blast.

I became a Haskell advocate, promoting the language everywhere. Since then I used it multiple times in production with good results.

Over time I discovered that even if the language had high support for errors, certain libraries were developed in the old fashion way: if there is an error, then throw an exception and break everything.

This is the topic of my daily rant.

Take for instance terminal-size's fdSize; given a fd, it returns the size of the terminal attached. The description says that "if there is no Terminal attached then Nothing is returned". But wait, what happens if fd is not a valid file descriptor?
hackage.haskell.org/package/termin…

Well, it turned out that the library swallows any error it encounters, even the ones unrelated, and returns Nothing regardless. This has two implications: 1) errors are not visible to the users and 2) the documentation is wrong.

Now you may think that this is one case among Haskell libraries. I wish you were right. Let's talk about Prelude. Prelude contains several partial functions on list, e.g. head. Those functions should NOT be used but since they are in Prelude somebody will, sadly, use them.

When you use those functions in the "wrong way", an error is thrown. This error has deliberately no context, e.g. the stack trace, which means it doesn't convey any info except the name of the function.

Even worse, the type of the functions mentioned has no effect. The user won't program defensively against them because in Haskell you usually have the effects modeled in the type.

Combine meaningless errors with lack of effect declaration and you'll get a ticking bomb ready to ruin your day. Keep in mind that those are not the only examples: the amount of functions swallowing errors in Haskell keeps surprising me.

Which is mind blowing if you consider how great Haskell is in dealing with errors. It's almost like a part of the haskell developers don't understand that modelling errors properly with as much context as possible is good. Like, really really really good.

Thanks for reading my mini-blog post on twitter. Now the two tips:

As #developer, know the libraries that you are using. Time spent learning libraries is time not spent debugging later. Just because it is in haskell it doesn't mean it can't have side-effects.

As library developer: *always* add maximum context to errors, in particular the ones that you don't model as effects. You will make working with that language and library much better. Trust me, somebody will thank you for that ;).

</rant>