Anil Madhavapeddy – Unikernels: Functional Infrastructure with Mirage OS

Anil captivates the crowd with his talk on Mirage OS.

Last week, we had the privilege of hosting a very special guest speaker, Anil Madhavapeddy. You already know him as one of the authors behind “Real World OCaml: Functional programming for the masses”.

Anil showed us some neat developments from the Mirage OS project. Topics of interest included: an informal demonstration of OCaml Unikernels, a tutorial about operating system aspects, and a walkthrough of the TLS stack. Magnus Skjegstad gave us a demo of Jitsu which can spin up servers within milliseconds just-in-time as a request arrives. Anil also showed us the Bitcoin Piñata and invites programmers to tackle this challenge for a chance at free Bitcoins!

Screen Shot 2015-05-12 at 2.59.14 PM
Anil talks about Unikernels.

Below is a video of the entire talk for your enjoyment.

Those who came out to our event also had the chance to meet other OCaml enthusiasts, munch on some food, partake in some drinks, and bask in our uniquely painted officeWe’d like give a big thanks to Anil once again for making the long trip and being awesome as usual.

Thanks to everybody who came out and hope to see you at the next OCaml Meetup.

Algebraic Data Types

Algebraic data types are the fundamental building blocks of programs in ML-style languages like Haskell and OCaml. Since they play such an important role in these languages, it is well worth understanding how they work and where they come from—at first, the design may feel a bit arbitrary, but in reality it flows naturally from a reasonable starting point.

Algebraic data types are made up of two components: products (also known as structs, records or tuples) and variants (also known as tagged unions, sums or coproducts). Let’s take a look at each of these in turn, how they can be combined and how they’re related.


Products are a construct that appears in most programming languages: it’s a type that contains multiple values. The simplest example in OCaml would be a pair (just like an ordered pair in mathematics):

# let pair = (1, 2);;
val pair : int * int = (1, 2)

This pair has the type int * int which means it has two members, both integers. In prose rather than code, this is often written as int × int because it corresponds to a cross-product of sets. Fundamentally, we can do two interesting things with a pair: get the first element or get the second element:

# let first (x, y) = x;;
val first : 'a * 'b -> 'a = <fun>
# let second (x, y) = y;;
val second : 'a * 'b -> 'b = <fun>

In OCaml, pattern matching makes the definitions pretty visual. The functions first and second are often abbreviated as fst and snd or π₁ and π₂ (π is used because these are projection functions).

Why We Use OCaml


According to the TIOBE Programming Community index for June 2014, the following nine programming languages make up over 60% of the total popularity ratings: C, Java, Objective-C, C++, C#, PHP, Python, JavaScript, and Ruby.

Here at Esper, we have chosen to use the OCaml language for the server-side backend that implements most of our application’s functionality. OCaml includes many features that are not available in the more mainstream programming languages listed above, and we believe this gives us a competitive advantage. But even among Silicon Valley startups, OCaml is an unusual choice. The purpose of this post is to explain the benefits of OCaml and compare it to other languages. We hope to convince readers, especially other developers, to consider adopting OCaml for their projects as well.



Here are some of the most important features of the OCaml language that we consider useful, or even essential, for building high-quality, reliable software:

First-class functions and immutable values

It is not always clear what people mean when they say “functional programming”, so we avoid this term and state directly what we want. Functions should be full-fledged values that can be created within other functions, stored inside data structures, passed as arguments, and returned as results. A function should automatically capture the relevant parts of its environment at the time of creation into a closure.

Most recent programming languages support these features, but they may be little used in idiomatic programs. One reason is that a function’s behavior is more difficult to predict when the values in its environment can be modified after its definition. Such modification could cause the function to produce different results when called with the same arguments, contrary to the expected behavior of a function. Mutability can be a useful tool in some situations, but it is often unnecessary and potentially harmful.