[Blog] Getting OCaml Through the Eye of a Needle

Community
2

TIL about lobste.rs. (Since can’t reply without being a member, and some of that discussion seems better on discuss, I’ll post here)

What Jean posted seems both normal and sad. Spoiler alert: If you can’t read the post, the recommendation is:

Summary

not to use OCaml for webdev except in narrow cases

Since I did something similar at DkCoder 0.2 - Scripting in OCaml - #2 by jbeckford with the DkSubscribeWebhook example, I have some takeaways:

  1. Versioning and reproducibility is important. Compiling against an old but stable version of glibc on Linux is a thing. I use dockcross for that (essentially the same thing that binary Python wheels use), and you can use dkml-workflows in CI if you’d like a guided setup for existing OCaml projects.
  2. Knowing which dependencies to use is incredibly hard. And it is harder in OCaml because OCaml’s official standard library is thin for good reasons. I feel like this gets talked about a lot, but some measure of “actively supported” for packages is needed even if the problem space is hard. The alternative is to promote a thick standard library like Jane Street’s core, but I don’t think we have a good candidate yet that can cover the (mythical?) 80% of use cases.
  3. Yes, we really need package namespacing so that others can continue to develop when practical issues inevitably occur (maintainer does not have time; global conflicts; etc.). I’d really love if namespacing were a core feature of opam (after it gets through its current priorities).
  4. We need a good story for deploying to Linux servers. Generating static and portable executables with OCaml describes a technique that IMHO should be hidden behind a single dune configuration value.

In the meantime, I can practically apply the above takeaways as I’m developing DkCoder:

  1. Todo. DkCoder versions artifacts (.so, .cma, etc.) for the end-user with OS-specific portable build mechanisms (dockcross for Linux, MACOSX_DEPLOYMENT_TARGET for macOS). But today I can’t reliably reproduce the .cma artifacts.
  2. Todo. I’ve cobbled together a thick standard library for DkCoder based on actively supported, liberally licensed, cross-platform dependencies and minimally conservative PPX-es. I think I could export the packages to the opam repository at some point, if people are interested.
  3. Todo. I haven’t released external package management yet, but now I know that it needs to have first-class support for ownership transfers and forking. And a straightforward way to release packages to the main opam repository.
  4. Unclear. I’m used to Docker containers and/or custom Linux images, but scp-ing static binaries is much nicer when you don’t have CI/CD pipelines.
5 Likes