I have and will continue to maintain that it's Haskell's operational challenges that are holding it back from wide adoption, at least on the web. In a lazy lang

I have and will continue to maintain that it's Haskell's operational challenges that are holding it back from wide adoption, at least on the web. In a lazy language, your cost model is all out of whack. When your program consumes resources, you can't unambiguously identify the line of code that caused your program to consume those resources. That's because a function application itself does nothing. Needing the result of the application is what causes work to be done. And that function application could be floating through your program as a thunk for who knows how long until its result (probably a partial result at that) is forced. So who's to blame for the work? The function application or the code that forced its result? Who knows. The typical solution to this problem in production Haskell systems, by the way, is to run the application with profiling turned on.