<story><title>Four months with Haskell</title><url>https://lexi-lambda.github.io/blog/2016/06/12/four-months-with-haskell/</url></story><parent_chain></parent_chain><comment><author>slezakattack</author><text>I programmed Haskell professionally for about a year and a half. My last company has been trying to hire Haskell engineers for over 2 years and we&amp;#x27;ve only managed to hire at least 2. &amp;quot;Hiring Haskell developers is not hard&amp;quot;, is extremely subjective and naive to say the least. Obviously, YMMV, but the front-end devs that the last company was hiring was running laps around the Haskell team. Honestly, finding a Haskell engineer is not always a winner either. I&amp;#x27;ve found that the ones we hired are very smart but not very decent engineers (i.e. defining requirements, shipping a product on time, understand tradeoffs, etc.).&lt;p&gt;There were quite a few things about Haskell that I truly love and miss, such as the type system, but the tradeoffs just weren&amp;#x27;t worth it to me and I honestly don&amp;#x27;t think it&amp;#x27;s mature enough to be considered &amp;quot;enterprise ready&amp;quot;. Aside from the learning curve, there were several bugs in one of the Haskell libraries that caused frequent outages (until we were able to pinpoint what was wrong), lazy evaluation caused excessive memory bloat when used incorrectly, and my all-time favorite: needing to switch on profiling in order to get stack traces (this is suppose to change in future GHC versions) which defeated the whole purpose of &amp;quot;haskell is fast&amp;quot;. I don&amp;#x27;t know, perhaps we were using Haskell wrong. From a business perspective, it just wasn&amp;#x27;t making that much sense given how difficult it was to hire, getting engineers excited to learn it, and having the features needed to monitor a production system.</text></comment>
<story><title>Four months with Haskell</title><url>https://lexi-lambda.github.io/blog/2016/06/12/four-months-with-haskell/</url></story><parent_chain></parent_chain><comment><author>p4wnc6</author><text>I fall in a weird bucket: very advanced understanding of some other languages and good work experience, education, etc., but even though I love Haskell and practice it all the time, I think I am just somewhere on the boundary between beginner and intermediate, and even with focused daily effort I would remain on that boundary for a long time before there is a phase transition to solid intermediate.&lt;p&gt;Because of this, the only kinds of FP shops that would hire me want to hire me at a junior or low-paying level, but my market value in lots of other skill areas (machine learning, Python, database stuff, etc.) is much higher, so I&amp;#x27;m not willing to take a salary anywhere close to what they think fits the position.&lt;p&gt;As a result, even though I would love to get industry experience with functional programming, there is a market wage energy barrier preventing me from considering it. I was burned once early in my career with malarkey about how you should accept a lower salary for some alleged other benefit (like cool functional programming, or working with a team of awesome people, or getting in on the ground floor on something, etc.) -- I won&amp;#x27;t make that mistake again.&lt;p&gt;So I basically had to learn to divorce myself from real world Haskell practically just as soon as I learned how much I really love it.&lt;p&gt;Plus, and this should not be discounted, the professional tooling with Haskell is still extremely immature with lots of esoteric corners duct taped together in unsatisfying ways. It&amp;#x27;s getting better, but if you work with Haskell for real there are likely to be as many, if not many more, extremely frustrating painpoints of the language tooling as with any other language, enough to amortize away all the warm fuzzy happiness you&amp;#x27;d get from the status effects of being able to say you do pure functional programming for a job.</text></comment>