1. Speed and space can be difficult to predict without considerable experience. 2. The libraries are not as extensive and tested compared to conventional choices such as Java or C++.

Using strict data structures is usually the simplest way to regain predictability:

    data QueryExpr
      = RelVar !Text
      | Restrict !ScalarExpr !QueryExpr
      | Select !(HashMap Text ScalarExpr) !QueryExpr
      | SummarizeBy !(Vector Text) !(HashMap Text ScalarExpr) !QueryExpr

Excessive strictness can cost you performance if you end up evaluating things you didn’t have to, but ASTs should probably be strict. Using Criterion for benchmarking helps find the sweet spot.

I have found Haskell’s library ecosystem quite good—any time I’ve needed a library, there has been a suitable one. In the rare case that changes are necessary, maintainers tend to be responsive and helpful. We probably just work on different kinds of software.

Many people see it as a big risk (such as investors and customers) which makes it self-fulfilling.

otoh, theres a few mostly haskell shops, and that number is growing! Its really exciting to see the growing haskell adoption at a number of companies doing interesting things

Can you describe better why they see it as such? The key risk I see in Haskell is the lack of enterprise-y libraries.

I guess a lot of it boils down to them never having heard of Haskell before.