8 months of OCaml after 8 years of Haskell in production

I’ve been using Haskell in production for 8 years. I’ve been using OCaml in production for 8 months.

It’s time to compare those two languages.

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

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

OCaml, being a language from the ML family is great too, but still, Haskell is more tacit.

Compare a few examples:

Sum of all numbers in a string

Using just the standard library

Haskell

-- strSum "100  -42 15" = 73
strSum :: String -> Int
strSum = sum . map read . words

(* str_sum "100  -42 15" = 73 *)
let str_sum (str: string): int =
  str
  |> String.split_on_char ' '
  |> List.filter_map int_of_string_opt
  |> List.fold_left (+) 0

data Tree a
  = Leaf
  | Node a (Tree a) (Tree a)

type 'a tree =
  | Leaf
  | Node of 'a * 'a tree * 'a tree

parseLine :: String -> Maybe Int
parseLine line = do
    ["Status:", "0", _, "Result:", result] <- Just $ words line
    n <- readMaybe result
    guard $ even n
    pure n

let parse_line (line: string): int option =
  let ( let* ) = Option.bind in
  let* result =
    match String.split_on_char ' ' line with
    | ["Status:"; "0"; _; "Result:"; result] -> Some result
    | _ -> None
  in
  let* n = int_of_string_opt result in
  if n mod 2 = 0 then Some n else None

Number of Stripe API client libraries:

• Haskell: 13
• OCaml: 1 (last change was 8 years ago, so it’s more like zero)

You may find a solution in Haskell. But often you’ll discover too many solutions, you won’t know which one to choose.

Choosing a library in Haskell becomes a separate skill you need to master. Haskellers even blog their recommendations on how to choose a library! And you’ll face this dilemma over and over again.

Often, a new Haskell library is created not because it solves a different problem.

But because the author wanted to write it differently (using different abstractions, playing with new features, etc. Who doesn’t want a new streaming library based on LinearTypes???).

It’s not exciting to write a GitHub API client and parse tons of JSON.

But it is exciting to design a logger with comonads.

The Haskell tooling evokes the most controversial feelings. It’s like an emotional roller coaster:

• 🤩 Hoogle is the best! I can search through the entire ecosystem by using just a type signature!!!
• 😨 Wait, why build tooling error messages are so bad, what do you mean it couldn’t find a build plan for a working project???
• 🤩 Global content-addressable storage for all dependencies is such an amazing idea!!!
• 😨 What do you mean I need to recompile my IDE because I changed my package???
• 🤩 I can automatically test all the code snippets in my package docs!!!
• 😨 Wait, why the standard library doesn’t have docs at all for this version I use???

And so on.

Using Haskell tooling is like always being in the quantum superposition of “How do you even use other PLs without such wholesome Haskell tools???” and “How Haskellers can live like that without these usability essentials???”.

OCaml, on the other hand, hits differently. Because its ecosystem is smaller, you actually get surprised every time you find something working!

For example, the VSCode plugin for OCaml based on Language Server Protocol (LSP) works out-of-the-box. I never had any issues with it. It just works ™️

The ergonomics of starting with OCaml tooling might not be the best but they’re straightforward and robust. And they work most of the time.

To get a full picture, refer to the following table for the full comparison of available tooling in both languages.

Tooling comparison table

I want to highlight the compiler aspect of tooling separately since this is the tool you interact the most with.

Especially, compiler suggestions.

When using FP languages, the compiler is your best friend! You rely on it heavily to understand why your assumptions haven’t been codified precisely.

Therefore, the compiler must present the information in the most accessible way.

In my view, Haskell compiler messages tend to be verbose with lots of contextual, often redundant, and distracting information.

OCaml compiler messages, on the other hand, are quite succinct. Sometimes too succinct.

Consider the following example.

Haskell: Compiler messages example

Program with an error

Compiler output

OCaml: Compiler messages example

Program with an error

Compiler output

This is just one example (and most likely not the best one), but you can already see the differences in how information is presented and how types work in different languages.

I believe the standard library deserves a separate mention too.

It shapes your first program in a language and guides you through all future journeys.

A great standard library is a cornerstone of your PL success.

A poor standard library is a cornerstone of never-ending bikesheds about a better standard library (including an endless variety of alternative competing standard libraries).

I’m a big proponent of the idea that a standard library should be batteries-included.

Give me an Option-like type, a UTF-8 string, Map and HashMap, JSON and XML parsers, async primitives, and so on, so I can avoid learning your poor implementation of dependency tracking and build tooling. (Build Systems a la Carte is a thorough analysis of the space of dependency trackers and build tools.).

Both Haskell and OCaml have kinda barebones standard libraries. They have minor differences (e.g. Haskell doesn’t include Map and HashMap; OCaml doesn’t have non-empty lists and Bitraversable). But overall they’re similar in the spirit.

The Haskell standard library is called base and OCaml standard library is called.. well, it’s just “the standard library”.

However, one difference is striking. The quality of Haskell documentation sometimes can amaze even a seasoned developer.

Haskell has a few more nice features, like the ability to jump to sources from docs but I’ve been told such features are being cooked for OCaml too 👀

Compare a few doc snippets for the List data type (one of the fundamental structures in FP):

Haskell

Haskell: Data.List.head

Haskell: !?

OCaml

OCaml: List.hd

OCaml: List.nth_opt

You may argue that the result of such functions is obvious, therefore there’s no need to write essays under each function.

I’m a fan of example-driven documentation, and I love seeing usage examples in docs! This immediately gives me an idea of how I can leverage the API in the best way.

I want to end this blog post by saying:

Both languages came a long way to support real industrial needs.

They’re still small compared to mainstream languages.

If you’re not critically dependent on the presence of some specific SDK, you can choose any and have lots of joy while coding your next app 🧡

However, I prefer OCaml nowadays because I feel that I can focus on actually building stuff with this language.

Besides the comment section below, you can also find the discussions of this blog post in various places:

If you liked this blog post, consider supporting my work on GitHub Sponsors, or following me on the Internet: