> So, for a programming language that has so much to offer, why isn't it adopted more? In my experience it's usually some combination of FUD echoed throughout

> So, for a programming language that has so much to offer, why isn't it adopted more? In my experience it's usually some combination of FUD echoed throughout these comments such as: Haskell is an academic language and cannot be understood be mere mortals Well everyone is mortal and some people have learned Haskell so this is obviously hyperbole and meaningless. Is it difficult to understand? Yes... but I have a theory that this is largely because we aren't taught to think in the way Haskell asks us to. Most of us in industry invariably learn Haskell as a second or third language and by then certain patterns and expectations are present in our brains that we hold as truths. The tragedy of this argument is that people think you have to understand everything in Haskell in order to get started. They point to more advanced features like lenses and profunctor optics and all of this jargon as proof. However I don't ever recall having to learn the entirety of template metaprogramming to get started in C++. There's really a pyramid of features and the amount of Haskell you need to know to get started is small. It is too hard to hire Haskell programmers It's as hard as you make it out to be. There are plenty of people out there who would love to program in Haskell for their day job. When I started posting jobs for Haskell programmers my queue was full, constantly. The problem is that unless your organization is fully invested in Haskell people in your organization will find ways to hijack this process in order to make it come true by moving the goal posts. It might be hard to find Haskell programmers in your area so they'll say you can't hire remote developers. Say you'll train people up into Haskell and they'll say we don't have anyone experienced enough, or not enough time, etc, etc. It's not hard to hire programmers. It's hard dealing with people who don't want Haskell to be adopted in your org. The documentation is poor, there aren't enough libraries, etc This may have been true more than ten years ago but it no longer holds. The documentation is phenomenal. It seems rough if you're not used to reading type signatures. However once you are familiar with rudimentary levels of Haskell this disappears fast. Haskell is documented. Whenever you add a top-level signature you're adding documentation that not only enriches the program but documentation that cannot be wrong, go out of date, etc. I think this one gets bandied around a lot by developers from big ecosystems that have deep corporate pockets to fund the development of frameworks, libraries, and tooling. Haskell has been getting more of that but it's still nothing compared to Java/.NET/Swift, etc. Regardless there are libraries for every common task and ones that can do things with Haskell's type system that you simply cannot in other languages (or can only emulate, poorly, with possibly buggy run-time code introspections, templates, macros, etc). The real world is messy and Haskell's type system just gets in the way The real world is messy so why would you want to use a tool that makes incorrect programs permissible? This comes up from folks who like how easy it is to get started with dynamic languages which are permissive about their inputs. I like this property of dynamic languages too. What I don't like is all of the run time inspection I have to do in order to know what data is safe to use. At first this doesn't seem like a problem with unit tests and a tight feedback loop. However at larger scales in a code base it makes refactoring and reasoning about high-level patterns much harder. And despite the claim that "type errors are rarely ever the source of production issues anyway," I still find TypeError: undefined is not a function in logs more often than they'd like to think. The point of all this is that we ship this code confident that we probably nailed ~85% of the problem and we tolerate the risk that there will be some number of errors that will be reported after the fact. Ship early and ship often. However in practice this sucks up a lot of time as a project matures. I rather like the experience of not having to chase down where an errant null check as missed or where some code mistakenly mutated a shallow copy. I don't even have to think about that in Haskell. I can focus on the business domain logic.