Live data from Hacker News

Fighting spam with Haskell

code.facebook.com

21–30 of 98 posts

Re: Fighting spam with Haskell

#21
post #10
post #4

I am under the impression that a large part of engineering effort at established companies go into porting existing components to a deemed to be more appropriate language for that task. Is it plain impossible to pick the best fit language without implementing a solution in the first place and fleshing out the requirements and challenges that specific to the problem space? Or do the problems evolve fast enough that no…

Could be simply that time uncovers better solutions to the same problems, which triggers the need of porting.

The problem with this is just how often the story seems to involve porting of solutions. Not necessarily refinement or advancement, but pure porting. With lots of debate/fighting on the syntactic properties of the solutions.

Re: Fighting spam with Haskell

#22
For those not involved in the Haskell community, Simon Marlow worked full time on the GHC compiler and specifically run-time system for many years. Along with Simon Peyton-Jones, he's huge in the Haskell world. Marlow also wrote the very excellent "Parallel and Concurrent Programming in Haskell" book.

Facebook also employs Bryan O'Sullivan, an epic Haskell library writer (Aeson, Attoparsec, Text, Vector, and on and on http://hackage.haskell.org/user/BryanOSullivan). Bryan also co-authored the "Real World Haskell" book.

So Facebook has hired two prolific Haskellers and probably others I don't know about.

Re: Fighting spam with Haskell

#24
I learned a few things from this post outside the usual "technical" explanations:

1. They have CORE Haskell contributors on their payroll to deliver this type of project (what this mean is that no... Haskell isn't any better than other language, it's just that they have people who know Haskell very very deep to the compiler level...)

2. In-house custom language eventually does not scale (the EOL is much much much shorter than other programming languages), plan for that :)

Re: Fighting spam with Haskell

#25
post #16

Damn you FaceBook. I dislike the underlying premise, the adverts, and (especially) the "real names" policy. But... between great bits of Open Source like React, cool infrastructure projects like this, and a technical culture which seems a whole lot more open than many other big companies, it's getting kind-of hard to go on hating. Walk back a bit from the obsession with open plan offices, and I might just cave...

Their commitment to open source is truly amazing - I am currently in the process of interviewing with them, and am increasingly in awe of the company.

Surprisingly, their massive open office is the quietest office I have been in. It is a really nice workplace.

Re: Fighting spam with Haskell

#26

For those not involved in the Haskell community, Simon Marlow worked full time on the GHC compiler and specifically run-time system for many years. Along with Simon Peyton-Jones, he's huge in the Haskell world. Marlow also wrote the very excellent "Parallel and Concurrent Programming in Haskell" book. Facebook also employs Bryan O'Sullivan, an epic Haskell library writer (Aeson, Attoparsec, Text, Vector, and on and o…

A side note: The Haskell runtime is written in C so Simon Marlow is also one of the best low level C hackers I've ever met.

Re: Fighting spam with Haskell

#27
post #4

I am under the impression that a large part of engineering effort at established companies go into porting existing components to a deemed to be more appropriate language for that task. Is it plain impossible to pick the best fit language without implementing a solution in the first place and fleshing out the requirements and challenges that specific to the problem space? Or do the problems evolve fast enough that no…

It's rarely "just" a port. It's usually because the new language has better characteristics. These days porting can be a very gradual, as-needed process - partly because of thrift, another Facebook tool!

One of the big parts of becoming a professional for me was accepting that code has a lifecycle; code is written to make the business money at the time, but it's entirely normal for it to change and die as time goes on.

(That said, you should just write everything in Haskell and then you won't have these problems. When was the last time you saw a company port code away from Haskell?)

Re: Fighting spam with Haskell

#28

For those not involved in the Haskell community, Simon Marlow worked full time on the GHC compiler and specifically run-time system for many years. Along with Simon Peyton-Jones, he's huge in the Haskell world. Marlow also wrote the very excellent "Parallel and Concurrent Programming in Haskell" book. Facebook also employs Bryan O'Sullivan, an epic Haskell library writer (Aeson, Attoparsec, Text, Vector, and on and o…

Bos manages the internal tooling team at Facebook. It is little surprise that Facebook's internal tooling is acquiring a functional programming flavor.

Re: Fighting spam with Haskell

#29

For those not involved in the Haskell community, Simon Marlow worked full time on the GHC compiler and specifically run-time system for many years. Along with Simon Peyton-Jones, he's huge in the Haskell world. Marlow also wrote the very excellent "Parallel and Concurrent Programming in Haskell" book. Facebook also employs Bryan O'Sullivan, an epic Haskell library writer (Aeson, Attoparsec, Text, Vector, and on and o…

It really shows what an investment they are willing to make in the language. They aren't just training up internal engineers, they're bringing in some of the best in the community.

I'm hugely excited that Facebook is making this investment and giving some of the developments back to the community. There are many smaller companies that would be interested in Haskell but don't have the resources or expertise to tackle some of these complicated problems.

Facebook is blazing the trail for production Haskell and the rest of us can follow.

Re: Fighting spam with Haskell

#30
post #23

In the throughput graph, why does Haxl perform worse in the 3 most common request types?

I don't think the graph says which request types are more or less common. The ordering could be arbitrary.

It would be interesting to know why some are slower. Perhaps they require very little processing and so the time becomes dominated by FFI transformations? It would be nice to know!

Post reply on HN