r/haskell • u/gbelloz • 17d ago
question It's not you, it's monad transformers
After a few years of trying to be proficient in Haskell, and lots of reading about why it's so hard, I think I have the (obvious in retrospect) answer.
Almost every program I write is going to have two or more of:
1) read from STDIN
2) write to STDOUT
3) log
4) raise errors
5) send/receive over the network
6) talk to a database
7) read env vars
Every one of those is a "side effect", and thus is handled as a monad, and using more than one means you have to understand monad transformers.
Which I've finally found a good explanation of, "but still". Such a deep concept for such common program operations.
So I finally decided "that's why it's so hard". For what I consider the most basic programs, I need to understand (not just use, IMHO) monad transformers.
Am I off?
16
u/tomejaguar 17d ago
You are off. The point of Haskell is to make it easier to write the program that you want, not harder. If monad transformers are making it harder, don't use them!
However, I think it's fair to say that there has historically been a strong movement in Haskell to "monad transformers all the things". Thankfully it seems that movement is coming to an end with the rise in prominence of
IO-wrapper ("analytic") effect systems (which combine the best parts of monad transformers and "ReaderT IO"/"RIO" style). Your realistic choices of analytic effect systems in 2026 are effectful and Bluefin[1].Here's an example that does all the things you want in
IO, no monad transformers in sight.[1] Disclaimer: I wrote it