I wanted to make a simple REST service for queuing file uploads, deployable as a virtual machine. The traditional way to do this is to download a Linux cloud image, install the software inside it, and deploy that. Instead I decided to try a unikernel.

Unikernels promise some interesting benefits. The Ubuntu 14.04 amd64-disk1.img cloud image is 243 MB unconfigured, while the unikernel ended up at just 5.2 MB (running the queue service). Ubuntu runs a large amount of C code in security-critical places, while the unikernel is almost entirely type-safe OCaml. And besides, trying new things is fun.

In 2013, I spent 6 months converting 0install’s 29,215 lines of Python to OCaml (learning OCaml along the way). In this post, I’ll describe the approach I took and how it went. There will be graphs. If you don’t want to read the whole thing, the take-away is this: The new code is a similar length (slightly shorter), runs around 10x faster, and is statically type checked.

Way back in June, in Replacing Python: second round, I wrote:

The big surprise for me in these tests was how little you lose going from Python to OCaml.

Of course, I was mainly focused on making sure the things I needed were still available. With the port now complete (0install 2.6 has been released, and contains no Python code), here’s a summary of the main things you gain.

OCaml’s static typing allows it to detect many problems at compile-time. Still, some bugs slip though. In this post, I go over each discovered bug that made it into a Git commit and try to work out why it happened and whether it could have been prevented.

OCaml makes heavy use of parametric polymorphism (which you may also know as “generics” in other languages). The OCaml tutorials mention it from time to time, but the information is spread about over many articles and they don’t go into much detail. I’m not a type theorist, just a Python/Java/C programmer who finds this stuff interesting. I wanted to write this guide while I still remember the things that confused me. I know several OCaml experts keep an eye on this blog, so hopefully any inaccuracies will be corrected in the comments.

I’ve now migrated the asynchronous download logic in 0install from Python to OCaml + Lwt. This post records my experiences using Lwt, plus some comparisons with Python’s coroutines. As usual, the examples will be based on the real-world case of 0install, rather than on idealised text-book examples.

In today’s “thing’s I’ve learnt about OCaml” I look back at my first OCaml code, and think about how I’d write it differently now.

I’m now written 15,000 lines of OCaml while migrating 0install to the language. So here’s another “things I’ve learned” post…

The official objects tutorial offers a good introduction to using objects in OCaml, but it doesn’t explain a number of important issues. Chapter 3 of the OCaml manual does explain everything, but I had to read it a few times to get it.

The manual notes that:

the relation between object, class and type in OCaml is very different from that in mainstream object-oriented languages like Java or C++, so that you should not assume that similar keywords mean the same thing.

Good advice. Coming from a Python/Java background, here are some surprising things about objects in OCaml:

• An object’s type is not the same as its class.
• A class A can inherit from B without being a subclass.
• A class A can be a subclass of B without inheriting from it.
• You don’t need to use classes to create objects.

After we selected OCaml as the new language for 0install, I’ve been steadily converting the old Python code across. We now have more than 10,000 lines of OCaml, so I thought it’s time to share what I’ve learnt.

OCaml is actually a pretty small language. Once you’ve read the short tutorials you know most of the language. However, I did skip one interesting feature during my first attempts:

There are also “polymorphic variants” which allow the same field name to be used in different structures, but I haven’t tried using them.

I’ve since found a good use for these for handling command-line options…

In the initial language analysis, OCaml did well in most areas except for diagnostics (which turned out to have an easy solution) and shared libraries / binary compatibility. Now it’s time to look for a solution to that.