I have to respect Jane Street for proving that HM-typed functional programming can be production-ready and extremely fast when given enough love.
I still occasionally hear things about how the more academic-styled functional languages can't work in production, but Ocaml shows that it absolutely can work, even with high performance requirements.
I was fortunate enough to work at Jet.com before Walmart completely destroyed it, which was an F# shop. I really liked it, and I never really felt "limited" by it.
The stuff I was working on didn't have nearly the same requirements as high-frequency trading like Jane Street does though. I never did any super low-latency stuff with F#, so it's tough for me to say how well it fair with that kind of environment.
Thank you for mentioning this, because—not having followed the link—I thought someone was using Mercury for a backend. And... I wasn't sure I was prepared to follow that link.
Yeah, I actually interviewed for a Haskell position there in 2023. They didn't hire me, but it was kind of fun to do technical questions in Haskell for an interview instead of the boring JavaScript or Python that I usually use.
Certainly. There's also a good amount of F# in production. It's a fantastic option for building high quality programs with broad interop with existing systems.
NoRedInk[0] also uses some Haskell in their backend, as well as Elm for most of their frontend. They've also worked some with Roc according to a blog post from a few years back; not sure if using it.
Sadly I don't think it's used any more - it was migrated away from. I worked in integrity there and quite enjoyed whenever I had to make some changes to the Haskell rules :)
If anything the type system improves the run time speed, because the static analysis enables better code generation.
But I think what OP meant was more about the "functional programming" side of things than the "HM-typed" side of things. Naively, anyway, you might think that "the FP-style" of avoiding mutation and preferring recursion would require lots of garbage and high-latency garbage collection, copying, function call overhead...of course, that's not the whole story, but having Jane Street to point to as a crushing counter-example is nice.
Eh, this reads like damning with faint praise to me. Lots of robust and fast real world systems are in FP languages. Ocaml is estabilished and mature, far from "is it production ready?" category.
Not really meant to be "damning", I'm a pretty big functional programming advocate (I've spoken at the Lambda Days conference four times and the Clojure Conj once).
It feels like the trend right now is to bolt on one or two "functional libraries" into your "normal" language and pretend that that's the same as writing Haskell or Ocaml. People have actually expressed such sentiments to me because Java has the optional type and a "map" function for the Streams API. When I suggest writing something in a functional language, the response is always "it's too hard" or "we won't be able to hire for that", as if engineers are somehow unable to learn new things.
I dunno if anyone really doubted HM, functional programming could work. I've written a bit of OCaml and apart from the bad syntax (code very easily becomes a word soup) it's not especially different to other programming languages, just more convenient sometimes.
I think it's purity that actually is a big difference, but OCaml isn't pure.
My humble opinion is that the every-function-must-be-pure aspect of Haskell is the reason why Haskell won't receive mainstream success, not that that's what they're after.
It complicates things that are simple to express in an imperative language
I still occasionally hear things about how the more academic-styled functional languages can't work in production, but Ocaml shows that it absolutely can work, even with high performance requirements.