My own answer: The team I was in in 2013 invested a lot of time to learn Haskell. We tried to use it in production for 1-2 projects, mostly as an ETL framework

My own answer: The team I was in in 2013 invested a lot of time to learn Haskell. We tried to use it in production for 1-2 projects, mostly as an ETL framework. It didn't work out, we found the it's not a good fit for changing requirements, plus GHC was a bitch to use for debugging in production (cryptic). There were a lot of disappointments around this type, for example "if it compiles it's probably correct", or the often recurring "you can actually do that with an extension, there's a paper on that" answer to pretty basic questions. Although these projects were ultimately a failure, they produced some of the funniest war stories which we remember fondly, which we still recite over beers to scare our juniors :) Other teams had more success and put small Haskell projects into production, but these were later replaced with imperative versions, when Haskell produced hard to debug/fix memory (list) leaks and/or noone was around who wanted to maintain a Haskell service. I also tried to use Haskell for personal projects, which I thought would a good fit for strong typing: a library for physical units/dimensions. I also failed on that, it quickly became a mess. Oddly, I found C++ templates a lot more straightforward (even though I try to avoid C++ templates in general). Today, I would not use Haskell in production, and would be highly skeptical of a company doing so --- but while trying to keep an open mind.