I worked on this project for a week during the FB team matching process.
I had previous Haskell experience, but what struck me was how irrelevant that was.
To their immense credit, they had managed to use Haskell to write an entirely entreprise focused, "boring" business rule backend serving millions of QPS, and people who were not Haskell fans could easily use its sensible DSL to accomplish their goals.
Way too many Haskell projects are about Haskell itself, so this was really fascinating to see.
Every time I try to work on someone's Haskell code, I'm confronted with a slew of custom infix operators, and I find my previous experience is completely irrelevant as I learn the new DSL the authors chose to write (which more often than not also involves flexing their brain as hard as they can).
But that's like half of computing.. every new tool the world inflicts on you, configured in Jojo's Awesome Configuration Language, with some arbitrary made up grammar punctuated by Tourette outbursts of special character line-noise.
That, or YAML, then a tool to template and generate the YAML, and then a stack of tools wrapped around that, ad infinitum.
A little learning is the cost of not having to write the thing yourself. On the other hand, hell is the non-composable tower of babel that is computing. Total employment by exponentially compounding incidental complexity.
I'm sure it is super cool and immediately comprehensible for an independent project. I'm actually really fascinated by programming languages like APL that take it even further, I'd like to try some of those out but I don't have a great fit for a project to use with them.
But all I can think of when I see custom operators professionally is how much of a nightmare it would be the second one has to onboard a junior developer onto the project.
It's super cool, but I'm not sure immediately comprehensible. I can't even read my own Haskell code after a few months away from it. You end up using other people's infix operators from the libraries and it's easy to forget what they are.
Yes, (and so is OCaml) but less than in the past, mostly for specialized and older projets. Most engineers at Meta will not encounter these languages. It's costly to integrate them with the internal tools and arguably not worth the effort. On the other hand, Rust is increasingly popular and well-supported and approved by the company.
I think one of the most promising pitches for rust adoption is that it borrowed as much as possible from Haskell/ML without treading into the territory where it becomes "scary" for broadly-C-family language monoglots. A C++ or even Java programmer can look at Rust and think to themselves "this text has a comfortably familiar shape".
The differences between Haskell/OCaml and C-family languages are much more significant than syntax. Rust brings a lot (but not all) of the richness of these languages while staying within a broadly imperative paradigm.
That's neither my point nor OP's point. The soothing feeling of "this text has a comfortably familiar shape" is entirely about syntax, and indeed is only a soothing feeling because such programmer has not seen anything beyond it and is unwilling to get outside that comfort zone.
I do not hire anything who does not get outside of their comfort zone or who is intimated by syntax they haven't seen. If a programmer rejects Haskell or OCaml by giving me a good critique of say, Hindley Milner style type systems†, that's a good programmer I'm willing to hire even though I don't necessarily agree.
†: I've been asked exactly this question during an interview: to critique HM style type systems. As a candidate I felt this style of questions gave me a far better way to display my knowledge and experience than Leetcode style questions.
This article was written about the same time when I interviewed with this group. I was very enthusiastic about Haskell but a senior Haskell lead told me I needed much more Haskell experience but I was otherwise an interesting candidate and he offered to put me in touch with the other FB team doing a similar function, but in Java. I was only interested in learning Haskell, so nothing happened. Still it was very cool to be able to talk with a couple of famous Haskell folks.
If this article was about "fighting spam with C++ at Meta", would it make the front page? I doubt it. I learnt Haskell thinking that it would give me super-powers no other language has, but in the end my impression of the language was "meh". I like the syntax a lot, and I have adopted the monadic approach to error handling when I do Python, but Haskell itself doesn't give me an edge over other programmers.
Haskellers are proud of a few projects that use Haskell (pandoc, xmonad, etc.) and they boast about how they can achieve the same thing as i3 but in much fewer LoC. But frankly I don't think #LoC is a good metric for gauging a language's value.
I had previous Haskell experience, but what struck me was how irrelevant that was.
To their immense credit, they had managed to use Haskell to write an entirely entreprise focused, "boring" business rule backend serving millions of QPS, and people who were not Haskell fans could easily use its sensible DSL to accomplish their goals.
Way too many Haskell projects are about Haskell itself, so this was really fascinating to see.
reply