
Facebook's New Spam-Killer Hints at the Future of Coding - nols
http://www.wired.com/2015/09/facebooks-new-anti-spam-system-hints-future-coding/
======
jerf
Even as someone who knows Haskell, it isn't actually possible to read this
article and figure out what specifically about Haskell is helping.

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.

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:
[http://www.randomhacks.net/2007/02/22/bayes-rule-and-drug-
te...](http://www.randomhacks.net/2007/02/22/bayes-rule-and-drug-tests/) [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]).

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.

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.

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.

[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.

[2]: Or see [http://blog.plover.com/prog/haskell/probmonad-
refs.html](http://blog.plover.com/prog/haskell/probmonad-refs.html)

[3]: [http://journal.stuffwithstuff.com/2015/02/01/what-color-
is-y...](http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-
function/)

------
jgrahamc
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:

 _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.”_

~~~
niix
Yeah it seems like they are just writing an article for the sake of writing an
article.

~~~
raintrees
And based on the number of grammatical errors, quickly, at that.

------
hacker_9
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.

What.

~~~
akhilcacharya
tldr: functional languages may be the future. Or maybe not.

~~~
codygman
Hm, I took away this:

tldr: functional languages were the future for Facebook's new spam fighting
tool, they weren't for a startup owner who has previous professional Haskell
experience. Consider for your next project and possibly live the future now.

------
andrewhull
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.

------
zeveb
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.

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.

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.

------
oconnore
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.

I mention this because there are ways to benefit from Haskell while still
maintaining the sorts of "practical benefits" that are cited here.

------
swalsh
I love the idea of old languages coming back in fashion. I secretly love
MUMPS.

~~~
eatonphil
I am with you. I am so hooked on the built-in persistent storage support. I
have never seen a language as cool in that regard.

------
GreaterFool
From Haxl paper:

"We present an Applicative abstraction that allows implicit concurrency to be
extracted from computations written with a combination of Monad and
Applicative."

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.

~~~
steveklabnik
Rust does not yet have Higher Kindded Types, and so cannot yet. We do want to
add them eventually.

------
PlzSnow
My jaw actually dropped when they said "they used a programming language
called Haskell."

Were all my prejudices against the business practicality of functional
languages wrong?

Nope.

"Biilmann no longer uses Haskell. It’s not entirely practical."

EDIT: ... and to say, if Facebook can't attract superstar Haskell programmers,
then what chance any other startup?

~~~
tikhonj
Biilmann isn't at Facebook; he's just some random developer at a startup with
experience in different languages who once used Haskell for a work project. He
may as well be yet another HN commenter, and it isn't surprising that not
everyone who has tried Haskell is using it! The reporter probably just found
him easier to interview than the people actively using Haskell, for whatever
reason.

Haskell at Facebook is still going strong with, I believe, two teams using it
and actively recruiting. (I've been contacted by a recruiter myself, even.)
And they've hired Simon Marlowe and Bryan O'Sullivan who are pretty much as
superstar as they come. Recruiting woes are greatly exaggerated if not
inverted for startups seeking a handful of engineers—Haskell actively attracts
interesting candidates.

~~~
bobfunk
Biilmann here, I'm definitively not at Facebook no :)

I've run Haskell services in production for more than 4 years and still
operate 4 of them to this date. I also contributed the wai-eventsource module
to the Yesod project and build a Haskell powered eventsource addon for Heroku.

It's not my impression that there are tons of other people in the bay area
with as much experience in actually using Haskell for real world production
stuff. Most of them are probably at Facebook now and the journalist behind the
article did interview them...

That said, it's absolutely true that for Netlify I now use Go for the tasks I
would have used Haskell for earlier.

Haskell is an awesome, mindblowing language, and when I started using it for
production tasks it was by far the best tool for the job at the time. By now,
however, Go is a far more pragmatic choice for most of the tasks I used
Haskell for before.

Unless your whole stack is Haskell based, the context switching involved in
going back and forth between more traditional languages and Haskell are really
brutal. Apart from that, it's very easy to bring someone new onto a team and
teach them enough Go to be productive in a day or two. You just can't do that
with Haskell.

That said, it looks like a really, really good fit for what they're doing at
Facebook with regards to spam filtering. I can totally see how you can make a
safe DSL for rules that will be statically type checked and handle concurrency
without any need for developers to think about it, and the Haskell runtime is
incredible for these kind of things.

------
vincvinc
I've read over and over that 'haskell is difficult', but why exactly is that?

Its mathy syntax? Its unique concepts? The practical side (installing,
configuring and libraries can still be troublesome)?

~~~
mikkom
I think it's mostly the immutability. That can be quite frustrating sometimes.

------
bozoUser
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).

------
0xdeadbeefbabe
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.

------
johanneskanybal
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.

