> Reading this has only further convinced me that Haskell is unsuitable for production due to the difficulties laziness posses to correctly reasoning about the

> Reading this has only further convinced me that Haskell is unsuitable for production due to the difficulties laziness posses to correctly reasoning about the performance characteristics of code. What are those difficulties? Here are a couple of sentences from the start of the article: > I knew just based on common sense that m only gets evaluated once (when it is first needed, no sooner, no later) but I realised I didn't know the exact mechanics behind that. > What I'm about to describe is completely useless to learn how to write Haskell, but if you're like me and like poking at things under the hood, by all means join in. That sounds just like any other language to me: - We know what the behaviour will be "based on common sense" (ie. the high-level spec and our experience) - We don't really care about the exact implementation - Some novices don't understand the language yet - Trying to follow a real implementation is complicated by the masses of optimisation it's had, and the heavy dose of hooks it's gained for debugging, instrumentation, portability, etc. > Idris is not only strict by default, but has an even more advanced type system, and because of that it will probably overtake Haskell eventually. Whilst Idris is pretty cool, I think it's a long way from production use. The language itself is still evolving (eg. type-based laziness annotations, affine types, etc.) and many of those changes lead to large upheavals in the standard library. I've written some Idris, but I wouldn't count on it still working after a version bump. Haskell seems to be a/the de facto functional language at the moment. Whilst Idris usage may increase, I doubt it will make up for Haskell's head start. More likely, something better will emerge and eclipse both, although that may take decades.