4 ms·

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 manag

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.

jwatte 10y ago
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 10y ago
  Isn't Haskell 20 years old though?
  - tome 10y ago
    26 according to https://en.wikipedia.org/wiki/Haskell_%28programming_language%29 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 10y ago
    Parts of it. Basically all of it is pretty new to enterprise, though.
  - tejon 10y ago
    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.
daxfohl 10y ago
> 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 10y ago
  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 10y ago
    > 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.
  - deleted 10y ago
    [deleted]
codygman 10y ago
> 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 10y ago
  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 10y ago
    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 10y ago
  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-ways-are-the-best/ http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-... [1] https://github.com/bos/aeson/ https://github.com/bos/aeson/
seagreen 10y ago
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 10y ago
  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/ 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. :)

jwatte 10y ago

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 10y ago
Isn't Haskell 20 years old though?
- tome 10y ago
  26 according to https://en.wikipedia.org/wiki/Haskell_%28programming_language%29 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 10y ago
  Parts of it. Basically all of it is pretty new to enterprise, though.
- tejon 10y ago
  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.

daxfohl 10y ago

> 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 10y ago
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 10y ago
  > 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.
- deleted 10y ago
  [deleted]

codygman 10y ago

> 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 10y ago
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 10y ago
  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 10y ago
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-ways-are-the-best/ http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-... [1] https://github.com/bos/aeson/ https://github.com/bos/aeson/

seagreen 10y ago

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 10y ago
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/ 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. :)