[slezakattack]

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've only managed to hire at least 2. "Hiring Haskell developers is not hard", 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'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.).

There were quite a few things about Haskell that I truly love and miss, such as the type system, but the tradeoffs just weren't worth it to me and I honestly don't think it's mature enough to be considered "enterprise ready". 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 "haskell is fast". I don't know, perhaps we were using Haskell wrong. From a business perspective, it just wasn'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.

[seagreen]

As a huge haskell fan, I'd love to hear more of this story. There aren't enough good writeups of companies trying haskell and it not working.

[chadaustin]

I happened to work at said company (IMVU) too, and wrote a lot of Haskell (after the codebase was established), and I think it's not fair to say "it didn't work". It also wasn't a smashing success. There were definitely advantages and disadvantages. Ultimately, as technical director, I supported Haskell, because I felt the advantages outweighed the disadvantages. I now work at Dropbox, which uses Go for the same purpose instead of Haskell, and I regularly miss being able to, you know, just map across an array.

Advantages of Haskell: unit tests were 100% reliable. Performance was amazing compared to PHP. The number of accidental regressions was very low compared to PHP. Yesod's typed HTTP router was super awesome. The ability to easily parallelize IO was a big deal for reducing latency.

Disadvantages: there was a great deal of internal resistance to learning Haskell. I never managed to separate the resistance to the language itself vs. resistance to a parallel stack, but PHP was really not pulling its weight, so I'm not sure if, say, Go or Java would have had the same level of internal drama or not. Haskell Strings are stupid. We had to write our own high-performance JSON encoder to achieve <50ms service response times ( https://chadaustin.me/2015/02/buffer-builder/ ) on large JSON responses, like news feeds.

So, I love Haskell, and were I writing a new backend for a new company with people that I know would be productive in it, I'd definitely choose it again. But it's not something to be taken on lightly. Even though I was not the original Haskell advocate at IMVU, I did end up supporting it and did what I could to teach it to others.

It was surprisingly easy to teach to people. I remember showing a new engineer who'd never seen any Haskell before monads on a whiteboard and he after I explained monoids and functors and then monads, he just nodded and said "oh, okay, makes sense". He wasn't bluffing - he actually internalized the concept that quickly. The trick with teaching Haskell is to start with specifics and THEN generalize the ideas. "So, you know how you can concatenate lists? And if you concatenate a list with an empty list it stays the same? Well, those properties are true for lots of things, and those things are called monoids."

Sorry, I rambled a bit, but tl;dr: Haskell was a mixed success, brought along some drama, but overall enabled us to reduce the latency of some critical services by about 10x. At least while I was at IMVU, teaching people Haskell was actually not hard. Getting them to care about Haskell or even want to try it was sometimes VERY hard, depending on the person.

Oh yeah, and I 100% agree with slezakattack that Haskell programmers are not necessarily magical systems designers or system programmers. They're just like you and me. Some are better at some things than others. Many of my favorite Haskell libraries were written by people who came from high-performance programming in imperative languages but fell in love with Haskell's safety. Their libraries tend to have nice, safe APIs while not sacrificing performance. :)

[seagreen]

  I remember showing a new engineer who'd never seen
  any Haskell before monads on a whiteboard and he
  after I explained monoids and functors and then monads,
  he just nodded and said "oh, okay, makes sense".
  He wasn't bluffing - he actually internalized the concept
  that quickly.

This is amazing.

  The trick with teaching Haskell is to start with specifics
  and THEN generalize the ideas.

Definitely!

  Sorry, I rambled a bit, but tl;dr: Haskell was a mixed
  success, brought along some drama, but overall enabled
  us to reduce the latency of some critical services by
  about 10x. At least while I was at IMVU, teaching people
  Haskell was actually not hard. Getting them to care
  about Haskell or even want to try it was sometimes VERY
  hard, depending on the person.

Please, please, PLEASE turn this into a blog post. Haskell has a lot of great testimonials, but they can't be convincing unless they also show the downsides. For technical topics I think Haskellers do a great job being honest, eg: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md ("Numerical -- immature ... Front End ... immature ... Distributed programming ... immature"). But there aren't a lot of writeups of Haskell being tried in business with mixed results. A writeup saying "a big concern is getting developers onboard" would be hugely reassuring to companies considering Haskell that _do_ have their developers onboard.

  Oh yeah, and I 100% agree with slezakattack that Haskell
  programmers are not necessarily magical systems designers
  or system programmers. They're just like you and me.

Totally. There are some geniuses, but then there are also people like me who use it because my brain isn't big enough to hold a whole program in my head, so I need the types:)

[chadaustin]

Your comment inspired me to write it up, so thanks for that. :)

[tome]

> It was surprisingly easy to teach to people. I remember showing a new engineer who'd never seen any Haskell before monads on a whiteboard and he after I explained monoids and functors and then monads, he just nodded and said "oh, okay, makes sense".

Could you share your monad teaching technique?

[chadaustin]

Oh man, that's a great idea. If I get some time I'll try to write that up too.

[jwatte]

You will be happy to know that we now removed profiling from production builds, age our Haskell is now 12x faster than the PHP instead of "only" 6x faster :-)

I agree that any new technology introduced into an enterprise requires significant investment in training, which can be hard to justify for a startup chasing product market fit.

[CyberDildonics]

Isn't Haskell 20 years old though?

[tome]

26 according to https://en.wikipedia.org/wiki/Haskell_%28programming_languag...

And this seems like a non-sequitur. A technology can be new to a company without being new in itself.

[dllthomas]

Parts of it. Basically all of it is pretty new to enterprise, though.

[tejon]

So is Magic: the Gathering.

The latest core language spec is 2010, and GHC (the de-facto standard compiler) adds several new language extensions annually.

[codygman]

> 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),

What was the bug and what was the library?

[slezakattack]

This was a couple years ago when I was starting off with Haskell and was not intimately involved with what was happening. IIRC it was something to do with opening too many file descriptors on /dev/urandom. I think it was linked with one of the random libs. That's all I can remember.

[implicit]

I remember that. One of the crypto libraries was implemented by using unsafePerformIO to access a global handle to /dev/urandom rather than accepting another parameter.

For what it's worth, this bug was an outlier. The pitfalls of unsafePerformIO are relatively well-known.

For contrast, there a bug in PHP's opcode cache that causes memory corruption in our setup. The best we've managed to do to deal with that by patching PHP to bump the refcount of some object to a billion. The failure condition is sufficiently obscure that it took us multiple man-months to figure that much out.

[0xmohit]

For an example of a bug in aeson [1] and how it was isolated & fixed, refer to http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-...

[1] https://github.com/bos/aeson/

[daxfohl]

> defining requirements, shipping a product on time, understand tradeoffs

You could say that Haskell itself is only good at the first of these.

And: that it's common for a Haskell dev to not be good at the first, leads to deeper questions about Haskell's reason for existence at all in industry.

[slezakattack]

No, I think you could say that Haskell allows you to be good at the first. Working with stakeholders to help define requirements is not a skill you pick up with functional programming. In fact, my comment you're quoting really isn't dependent on what language you are using. It's more or less just a correlation about the haskell devs that were hired. Was trying to point out that finding people who learned haskell on their own time aren't always a good fit.

[the_af]

> Working with stakeholders to help define requirements is not a skill you pick up with functional programming

I'd go as far as to say it's not a skill you pick with any programming language, paradigm or technology. It's an important skill which happens to be orthogonal to the technology you're using.