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. :)
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:)
> 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".
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. :)