Most of the issues mentioned so far are trivial or just warts. The real issue is understanding the design patterns that work well enough to build high performan

Most of the issues mentioned so far are trivial or just warts. The real issue is understanding the design patterns that work well enough to build high performance applications. Also in order to really exploit the power and productivity of Haskell there is quite a learning curve. We built an algorithmic trading system, and almost everything else in Haskell. Our code base is over 100K of human written code. The major library gaps were a time library (you can find a version of what we have been thinking about releasing at https://github.com/time-cube/time-cube https://github.com/time-cube/time-cube). We use our own build system that drives cabal and ghc. Otherwise having many libraries is just painful. We found that composing applications as conduits to be a very effective design pattern that minimizes many laziness issues. Monad transformers are very powerful but the machinery for them (like forking) is not fully cooked. Maintaining the codebase is far easier with haskell than with anything else I have worked with (C/C++,C#,Java,etc...). Refactoring in Haskell is great. You can't fight the language. Fighting with Haskell will cause great pain. When you go with the flow, using lots of strong types, higher order functions and can apply things like a monoid instance to a problem the language is a joy to work with. Debugging is more painful than it has to be. There are still times when you need some real GDB wizardry. Lastly if you have more questions feel free to contact me through our website http://www.alphaheavy.com http://www.alphaheavy.com