Firstly, this doesn't mention the thing that bothered me the most in my few encounters; how baroque and fluid the tooling is.

I have regularly run into code that can only be compiled by a rather narrow range of ghc versions; too old or too new and it just won't.

> Haskell probably has the most elegant syntax across all languages I’ve seen (maybe Idris is better because dependently typed code can become ugly in Haskell really quickly).

I have a general dislike for ML-type syntaxes, and Haskell is my least favorite of the ML-type syntaxes I have encountered. Presumably there is some underlying set of principles that the author would like maximized that I assuredly do not.

> There’s utter joy in expressing your ideas by typing as few characters as possible.

Disagree; if I did agree, then I would probably use something from the APL family or maybe Factor.

Like a moth to flame, I'm drawn to Haskell every 6 months or so. What drives me to it is its ability to express concepts (once you're used to it) parsimoniously - like the point-free style in the example. Monads, I can understand/manage. But by the time I hit Monad Transformers (and the n different packages available), the excitement turns into a headache.

It's also a bummer that you need the containers package for basic DS. So, batteries not included, unlike Python. This also means that you need to use a package manager (stack or cabal) even for non-trivial programs, where a one-line ghci command line would have been more ergonomic.

That said, learning Haskell has had a very positive effect on how I think about and structure the programs I write in other languages ("functional core, imperative shell"). I don't think I'll ever program in Haskell in any semi-serious capacity. But these days, I get my daily functional fix from using jq on the command line.

I made a similar transition (1 year Haskell, 2 year OCaml) and this pretty matches up my experience. Some more points:

1. Compiler speed: a clear win for OCaml

2. OCaml 's module system is more explicit (always qualified Map.find). Haskell's type class system is more ergonomic (the instance is found through its type, so no explicit annotation needed, e.g. fmap fmap fmap, where the second must be the Reader's fmap).

3. > If I come to an existing OCaml project, the worst thing previous developers could do to it is have poor variable names, minimal documentation, and 200+ LOC functions. That’s fine, nothing extraordinary, I can handle that.

Though it's not common, but functor-heavy codebase does give you a headache. On the other hand, unifying type class instances across packages is no fun either.

4. OCaml's mixture of side effects and pure code tends to encourage using that in libraries and codebase. So expect more speed and more crashes.

Being conservative in the language extensions you use/allow in an organization is pretty important to maintaining usability of Haskell as a language.

Do we ever use TypeFamilies and DataKinds? Sure, but it's very rare.

https://www.simplehaskell.org/ is a pretty reasonable set of guidelines (though we opt for a more conservative approach ourselves)

    (…on Stripe API…)
    OCaml: 1 (last change was 8 years ago, so it’s more like zero)

I’ve been using OCaml for some time, primarily for my pet project, but also and some minor at-work utilities. One such thing was interacting with Datadog which, unsurprisingly, doesn’t provide OCaml SDK.

In short: Experience was great. Not only implementing specs with provided specs while using OCaml tooling was fast but also when I got to the rate limiting, I’ve been able to refactor code in around 20 minutes and then it felt like magic transformation.

My take away from that experience is that I wouldn’t use library availability as a hard argument. Every external library is liability and if language provides comfortable tooling and helpers then probably having own code on use-adequate level of abstraction (instead of high level kitchen sink) might preferred.

For high number of external integration I would use something like Go instead, which has exactly that, but as an API implementer I’d prefer to use OCaml instead.