Even as someone who knows Haskell, it isn't actually possible to read this article and figure out what specifically about Haskell is helping.<p>My suspicion is that it is Haskell's great support for domain-specific languages. This is both in the sense of languages that are really "just" Haskell APIs but work in such an different manner that they are quite different, and in the sense of writing a full compiler [1] (or any subset of a compiler) for a new language.<p>For an example of the former, one of my favorite demonstrations is the "probability monad", in which one ends up with a sort of sublanguage inside of Haskell that is probability aware: <a href="http://www.randomhacks.net/2007/02/22/bayes-rule-and-drug-tests/" rel="nofollow">http://www.randomhacks.net/2007/02/22/bayes-rule-and-drug-te...</a> [2] If you want to start to really grasp the power of Haskell, you could do worse than meditate on how you'd implement that in your $FAVORITE_LANGUAGE... and then, most likely, burst into tears when someone shows you just how much of Haskell still works, unchanged, even in that environment (e.g., everything in Control.Monad), rather than having to be implemented in a parallel type hierarchy (or, put another way, producing a new "color" of functions [3]).<p>While I doubt they use something exactly like that, it's not hard to see how that sort of thing could make it fairly easy to write spam classification code with a lot of the basic plumbing abstracted away entirely.<p>There's a lot of examples of the latter, but I'm not sure of a really solid open source example to point at. I know it's a common move in industry, though.<p>For bonus points, these things compose together just fine; you could easily take the probability monad and build a new language on top of it.<p>[1]: And I do mean real compiler, by anybody's definition, all the way down to assembler if you like. Haskell's a pretty good base language for that sort thing.<p>[2]: Or see <a href="http://blog.plover.com/prog/haskell/probmonad-refs.html" rel="nofollow">http://blog.plover.com/prog/haskell/probmonad-refs.html</a><p>[3]: <a href="http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/" rel="nofollow">http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...</a>
This is such a strange article. It starts out describing how Haskell was well-suited to their problem (or at least tries to) and then suddenly says:<p><i>The thing is: Biilmann no longer uses Haskell. It’s not entirely practical. Not enough people know how to use it, and this is unlikely to change. “Haskell is like a programming language from an alternate future that is never going to happen,” he says. “It solves all these problems it promises to solve. But it’s so different that there is no chance it will become common.”</i>
tldr: use Haskell because it solves all problems, but actually don't use Haskell use Go/Rust instead because they are more suited to the mainstream programmer, but Haskell is more powerful.<p>What.
Saying Haskell is ideal to the problem but not what they use is not a non sequitur. Just because a language's intrinsic characteristics make it ideal does not make it the best tool for a large project with an evolving programmer base. The point stands that Haskell represents an almost platonic ideal that other languages and libraries are striving for.
I think the real key is to accept that with well-defined interfaces, polyglot environments really do have an advantage, because different languages really do have sweet spots.<p>And fortunately, POSIX gives us those well-defined interfaces. POSIX process boundaries, pipes and Unix & TCP sockets are excellent interfaces to separate tools written in different languages. A well-written RESTful service listening on a Unix socket can work wonders.<p>If one's using POSIX, then one's team can work on each tool in the language which best suits it and in which the primary lead is most product. If someone moves on, then the rest of the team can support it because a) good programmers can pick up good languages quickly (I don't want to hire or work with mediocre programmers) and b) each service is small enough that anyone can understand what it does by looking at a small amount of code.
At work we use a Haskell DLL loaded into Matlab. Haskell's type system allows us to have a fast, formal core to depend on, and Matlab allows us to do ad-hoc things at run-time with a fairly powerful REPL.<p>I mention this because there are ways to benefit from Haskell while still maintaining the sorts of "practical benefits" that are cited here.
From Haxl paper:<p>"We present an Applicative abstraction that allows implicit concurrency to be extracted from computations written with a combination of Monad and Applicative."<p>The more your code is Applicative the more concurrency you can extract. It's a matter of good abstractions rather than the language. I'm sure Rust can handle Applicative and Monad just fine.
My jaw actually dropped when they said "they used a programming language called Haskell."<p>Were all my prejudices against the business practicality of functional languages wrong?<p>Nope.<p>"Biilmann no longer uses Haskell. It’s not entirely practical."<p>EDIT: ... and to say, if Facebook can't attract superstar Haskell programmers, then what chance any other startup?
I've read over and over that 'haskell is difficult', but why exactly is that?<p>Its mathy syntax? Its unique concepts? The practical side (installing, configuring and libraries can still be troublesome)?
Amazed that the article compares Haskell with Go and Rust but failed to draw comparisons with Scala (with some learning curve but not as great as the ones in question).
tl;dr they rewrote facebook software in haskell, so haskell might be good. It definitely changed the pace enough to make a boring rewrite more engaging. Never admit that publicly.
pretty dumb article. An editor could save it by shifting the take away towards the concepts polygot and the concurency requirement and it might make a bit of sense.