My experience hiring and working with Haskell developers - and those trying to get up to speed - is that one cannot just "learn Haskell in 2 months" as you migh

My experience hiring and working with Haskell developers - and those trying to get up to speed - is that one cannot just "learn Haskell in 2 months" as you might say, pick up Ruby after you already have significant Python, Java and C++ experience. It is however relatively unique to Haskell and similar languages whose paradigm is very different to what most of the market is used to. Everything is an optimization over a number of variables. The upside of Haskell is that (if you make an effort) you get very good people and they don't cost as much because there is comparatively less demand for the language, so even on a greenfield project it makes sense to give it a shot. This is aside from numerous language-specific benefits which have been discussed to death in the never ending language wars. The downside is that only a portion of the self-defined Haskell community can truly be more productive in Haskell than say, Python; and these people have many options and are themselves making trade-offs and optimizing across a variety of variables when picking a job (e.g. interesting machine learning work in Python vs boring CRUD work in Haskell, given the same salary, might rank about the same). If you find these people, if they want to work for you, you get good results. But you're bidding against Google and hedge funds, so you need to find an edge that they cannot take advantage of. For example, I saw almost no CVs with prestigious universities on them, because that's a common filter in prestigious organisations, who tend to miss out on the self-taught talent and the less well ranked alumni; those with "prestigious" CVs wait for organisations to get in touch rather than having to sell themselves. So it's probably a good idea to avoid using university as a filter. One reason there are many Haskell job openings in comparably fragile settings (low budget, bad politics, low stakes etc.) is because in cases where resources are ample (thus allowing for time for senior people to learn a new language or junior people to learn professional software development skills), the risk-taking appetite is less and managers will hedge by going for the popular instead of taking a "Python paradox"/blub bet. A cynical reason for this might also be that you do not want to be dependent on a small number of talented people - having a large team of replaceable junior talent hedges against the developers acquiring strong negotiating power by virtue of adding too much value, or even just the risk that a car crash wipes out half your codebase. In some ways the survivability of the organisation in the low-resource setting is then dependent on the Haskeller - if you help your employer increase its conversion rate or customer lifetime value 10-fold, or reduce dev ops and infrastucture cost by a factor of 10, you might well change the very dynamics of the business and justify your team and salary; so it might make sense to take a less attractive posting if you know this is a possibility. At the same time, there are numerous companies arguing this to try and get you to accept a pay cut.