Sure, in Java you don't have to deal with GADTs. But you do have to deal with the fact that people think functions are dark magic and expect you to extend an ab

Sure, in Java you don't have to deal with GADTs. But you do have to deal with the fact that people think functions are dark magic and expect you to extend an abstract class instead. The amount of type wizardry that Haskell permits is far larger than Java and C++ teaches us that in practice you have to expect all possible combinations language features that are allowed. A random Java library will have a far more understandable API than a random Haskell package, since there are not so many permutations of language features possible. If everybody stuck to just Haskell 98, things would be far simpler. Besides, have you ever tried to use the equivalent of Parsec or QuickCheck in Java? As a matter of fact, I just committed QuickCheck-like unit tests five minutes ago [1] :): https://github.com/danieldk/dictomaton/commit/7aaa89aae68524f32528b6fb5e28d0d14da9b828 https://github.com/danieldk/dictomaton/commit/7aaa89aae68524... I write such tests in Java quite often. Of course, you don't have the nice combinators of QuickCheck :). I am not saying that Haskell isn't more powerful it is. But it comes at a cost: many packages come with an up-front learning cost, Haskell is hard to optimize compared to Java or C, etc. The Java APIs are predictable, run-time performance is predictable (in the sense that it easy to profile and optimize) and the ecosystem is boring and predictable. These are some of reasons that Java is popular (besides having a steward with deep pockets). ([1] Ps. yes, I know there is a very obvious optimization optimization possible that commit, it's a development branch.)