Haskell in Production: Standard Chartered
I&#x27;ve talked to a lot of people using Haskell in production over the years, and one of the things I&#x27;ve consistently noticed is a disconnect between the Haskell features that are often touted, and the Haskell features that people use in production.<p>This isn&#x27;t always a quiet omission, like &quot;we didn&#x27;t end up using this&quot; either. The best example is that a lot of people end up doing some significant work to disable lazy evaluation. Simon Peyton Jones is reported to have said that lazy evaluation has been kept &quot;to keep us honest about side effects&quot;, i.e., that size effects become immediately painful with pervasive lazy evaluation. But in a production system, functional purity (no side-effects) is a means to an end, and lazy evaluation comes at a pretty extreme performance cost. Not everyone disables lazy evaluation in production Haskell, because not everyone thinks they need to for performance, but I&#x27;ve definitely heard about it enough times that it seems like a relevant pattern.<p>Production users of Haskell do seem to be happy about types, years into projects, so I&#x27;d take away that types are a benefit, but I do wonder if one might get those same benefits in another language without the problems which seem to crop up with Haskell, such as laziness causing performance issues, monadic complexity, and difficulty hiring.