Top 5 Favorite OCaml Libraries?

Hi! I’m Christine, a technical writer at Tarides.
I’d love to hear from the community on this topic. One of the misconceptions about OCaml is that there aren’t enough libraries. I’d like to write a blog article dispelling this myth for newcomers to OCaml or programmers who might want to try OCaml.

What are your top 5 favorite OCaml libraries and why?


Most used: stdlib, lwt, cmdliner, ounit, cohttp
Other libraries I’ve enjoyed using: ocamlgraph, angstrom, zarith, cryptokit, yojson

Sorry, but the “why” is really difficult to describe - it’s a mix of many reasons - the type of stuff I happened to work on, the utility of these packages, the available alternatives, the nice abstractions and design-choices, the reliability/quality, how well they’re documented etc.

I think each library could probably have its own blog post about the pros/cons, written by someone more articulate, but I wanted to offer my list, even without anything useful in terms of “reasons why”.

1 Like

In your article you write about Lwt:

It also has functionality for running asynchronous code in parallel.

I don’t think that’s entirely correct. Lwt helps with creating concurrently running code, we’ll have to wait for OCaml 5 to get parallel programming facilities.

Thank you for writing this article! I like your choices and I’d add:

  • batteries: for the simplicity of the interfaces it provides, the good documentation
    and the drop-in replacement capability for the stdlib
  • pyml_bindgen: for looting the Python ecosystem like a pirate and not feeling any guilt
  • pyml: because it is needed by pyml_bindgen and so is great stuff

And for all the following, I am terribly biased since I am their authors (but I use them with joy almost everyday):

  • parany: for parallelization; in the past I would have said parmap, but then I wrote my own kind of parmap, which is more generic
  • minicli for super terse command-line parsing
  • dolog: logging for command-line programs (owl includes their own copy inside)
  1. ppx_deriving_yojson to derive json serializers on ocaml types.
  2. lacaml for BLAS/LAPACK bindings
  3. gsl for Gnu Scientific Library (GSL) bindings

The last two are my personal choice for an improved standard library and async support, but as others mentioned, there’s several options in this space:

  1. core for stdlib replacement.
  2. async for async programming.

Despite core being my default choice, I sometimes find myself reaching for containers whenever core doesn’t have the data structure I’m looking for.


Thank you so much for pointing that out. I had missed removing that sentence in the review, so I’m glad you caught it! It’s been removed.

Thanks also for making a list of those helpful libraries! I’ll make a note for the article I’m working on. :slight_smile:

1 Like

Thank you for sharing those! I’ll make a note of them for my future article. :slight_smile:

Thank you for this list and for taking the time to write out the why you like them as well! I’ll add them to the list of my forthcoming article. :slight_smile:

This is all good stuff! Thank you for sharing these and why you like them. All of these from all of you will help with my future article, and they will help newcomers understand there are lots of libraries for OCaml!

A quick grep would seem to indicate:

  1. unix because I find low-level solutions to big problems can be more reliable than fancy ones.
  2. lablgl because I love using OpenGL for visualization and this tried-and-tested library is rock solid.
  3. uri is indispensable in the web age.
  4. yojson because JSON is everywhere and this library is super simple and super fast.
  5. ppx_deriving but I really wish OCaml had generic printing!

Honorable mentions go to lwt and cohttp, both of which are awsome but I don’t use them often enough to make the top 5.


Here are five I quite like:

  • Bos is one of the nicer libraries I’ve used to abstract OS/file-system interactions.
  • Notty is just great fun for playing with and prototyping terminal-foo.
  • Js_of_ocaml because it’s pretty amazing to just write the same code for front-end and back-end and have (almost everything) just work.
  • Containers has been my preferred stdlib overlay for some while. Just find the APIs and documentation very nice.
  • Cmdliner makes really line cmd lines and is well documented.

I look forward to reading your article!


atdgen because of how easy it makes it to consume json.


For me they are, in alphabetical order,

  • bos (and fpath) to interact with os/filesystem (recently)
  • cmdliner for cli interfaces (well documented even though I often need very small reminders and look at the cheatsheet instead)
  • containers my goto stdlib extension, I like that is comprehensive, well documented and just extend the stdlib, so I introduce it only if I need and things don’t break
  • cohttp it is straightforward and always worked well for my needs
  • owl and gls for numerical simulations
  • re for regular expressions has always been a pleasure to use

For me these are indispensable

  • containers - lean and great stdlib extension
  • gsl - to be able to do anything numerical. I wish the coverage were complete.
  • lacaml - ditto
  • ctypes - so I can bind external C libraries without much C-fu.
  • iter - for handling fast iterators

My GOTOs that show up in every project for which I can choose libraries:

  • base: for the comfort of having well designed and homogeneous APIs for List/Option/Seq/Hashtbl/Map/etc
  • (dune’s) pp: very pleasant replacement for Format that is still compatible with it (Pp.to_fmt) → for people who have better things to do than hunting for opening and closing boxes :slight_smile:
  • Bünzli’s ptime/(ez)jsonm/xmlm/cmdliner → reliable, well documented
  • increasingly fond of the JaneSt’s PPXs: sexp, variants, fields, equal, compare, and especially ppx_expect

Most of them are about reducing the mental load for dealing with the basics and saving brain power for real & interesting problems.


Wow! Thank you all so much! I’m just thrilled by how many of you have responded to this. :slight_smile:

I’ll incorporate those libraries in the list for my future post. These will really help dispel the myth there aren’t enough libraries in OCaml!

@Jon_Harrop, @shonfeder, @rbjorklin, @mseri, @n4323, and @smondet — thank you for your valuable input. :tada:

(Also: so sorry for the noise earlier! I now know not to reply to each person individually but rather tag them.)



  • First, gsl (ocaml-gsl oandrieu and M. Mottl) because I am a numerical physicist, on the analysis side (integration, differential equations, etc).
    The GSL (Gnu Scientific Library) is a C library for numerical calculations.
    This may be not said very often but OCaml is great for numerical physics ! I switch to OCaml 20 years ago thanks to the existence of ocaml-gsl. I was using the GSL in C/Fortran and the OCaml wrapper is great to insure the correctness of the algorithm, for the readibility, etc. For example, in analysis basically everything is a float and OCaml allow to distinguish between them.

  • stdlib (I think it is a great standard library),

  • cmdliner

  • ppx_deriving

  • fmt (as Fprintf replacement)


Wow, I am really positively surprised, how many people are using OCaml for scientific/engineering applications (when looking at libs like owl, gsl, lacaml & python interop).

BTW, here are my favourites:

  1. cmdliner
  2. alcotest
  3. ppx_deriving
  4. owl
  5. lablgtk3

base, core, async

They’re well designed, and rarely leave me feeling like they lack something useful. On the contrary, I feel like I keep finding new useful stuff in them all the time.

More recently, I’ve been playing around with incremental, which has been really nice. It’s super powerful (like excel on steroids), and I love how seamless it is to get it working on the browser.

ppx_expect and quickcheck are pretty great, and recently I’ve also started using tezt more, which is pretty nice for its CI integration (auto balancing tests, and creating JUnit reports).

Edit: wanted to add esy to the mix. It’s a bit rough around the edges but when it works, it’s rock solid and super simple.


Thank you so much for chiming in with your favorite libraries and why, @arno, @kkirstein, and @rdavison!

@kkirstein, I’ll also be writing a few posts on dispelling some common OCaml misconceptions, and one of them is that it’s mainly for academic use. Great that people are using it for scientific/engineering. Perhaps I’ll make a new Discuss post asking what cool projects engineers are using OCaml to make. :slight_smile: