Why Jane Street Uses OCaml

Jane Street uses OCaml for a remarkable range of its software. That choice can look strange from the outside, so I want to explain what the language gives us, why we think it is practical for a trading firm, and what it costs us.

A useful, if imperfect, map divides programming languages along two axes: imperative versus functional, and dynamic versus static typing. These categories are not precise boundaries; languages borrow ideas from one another, and people can use the same language in different styles.

On the imperative side, dynamic languages like Python and Ruby are often easy to write and quick to experiment with. Statically typed languages such as Java and C tend to require more explicit structure but can run much faster. Those are broad tendencies, not laws.

A dynamic language has to make decisions at runtime that a static language can often settle earlier. Even addition may mean different things depending on the values involved, and the machinery for deciding what operation to perform has a cost. This helps explain why similar-looking code can differ greatly in speed.

An audience member notes that statically typed code can also inspect types dynamically. I agree: the categories are fuzzy. Java, for example, has reflection, and that runtime flexibility can bring performance costs of its own.

Types also serve correctness. Historically, Fortran's static types helped make numerical computation fast, while Lisp occupied a very different part of the map. Today types can also express properties of a program and help us catch mistakes before it runs.

Functional languages commonly make functions lightweight values: you can pass them to other functions, return them, and store them in data structures. They also support a style that avoids mutation, meaning that values are not repeatedly changed as a computation proceeds.

That may sound odd if you are accustomed to computing by updating variables in a loop. But a computation can be expressed without changing the data it starts with. A small example is summing a list.

The Python version initializes a total to zero, loops over the list, and increments the total. In the OCaml version, a recursive function examines the list: an empty list sums to zero, and a nonempty list sums to its head plus the sum of its tail. Both express the same calculation using different habits.

An audience member asks about recursion and stack usage. Some recursive forms can be optimized into loops, but this simple version is not the only possible implementation. The example is intended to show how to express the calculation without a mutable accumulator, not to claim that every recursive formulation has identical performance.

Why avoid mutation? When multiple pieces of code share a value that can change, one part can affect another in ways that are hard to see locally. Immutable data reduces these hidden channels of communication, making components easier to understand and combine.

The benefit becomes especially clear with concurrency: shared mutable state requires coordination so that different threads do not interfere. Pure functions are easier to reason about because their result depends on their inputs rather than on an unseen history of changes.

That does not mean a useful program can never have effects. Programs must interact with the world, read data, and produce results. The point is to manage mutation and effects deliberately rather than letting them spread everywhere.

An audience member asks whether object-oriented encapsulation can also control mutable state. It can help, but an abstraction still has to account for the ways its state changes. Functional techniques give us another way to limit the number of interactions we must understand.

The static functional corner includes OCaml, Standard ML, Haskell, Scala, and F#. These languages combine functional programming with type systems that can catch mistakes before execution. OCaml's type inference often works out the types without requiring the programmer to annotate every expression.

For the list-summing function, the compiler can infer that the input is a list of integers and the result is an integer. The code can be concise while still obtaining the performance and checking associated with static types. Inference is not free of trade-offs: error messages can sometimes be difficult to interpret.

Jane Street began moving to OCaml roughly a decade before this talk. Trading software needs to be correct: mistakes can be extraordinarily expensive, and the environment includes unusual events and other market participants acting on their own interests.

Testing matters, but tests cannot cover every possible situation. Financial outcomes can have fat tails, and a rare failure may be much more consequential than ordinary failures. A type system offers another way to rule out classes of mistakes before production, complementing tests rather than replacing them.

Consider Python code that compares two dictionaries. If it loops through keys in the first dictionary and assumes each is also present in the second, a missing key can cause a runtime exception. The program's logic has silently depended on an assumption that was never checked.

In OCaml, a map lookup can return an option: either a value is present or it is absent. Pattern matching makes the programmer confront both possibilities. The language does not magically decide the correct business behavior, but it makes the missing case explicit at the point where a design decision is needed.

This is why I think of a type system as a design tool, not just a way to catch typos. It encourages us to describe the possibilities in our domain and makes it harder to forget one when implementing the behavior.

Another example is a small language of Boolean expressions. We can represent true and false, conjunction, disjunction, negation, and a base case whose meaning is supplied separately. The structure of the expression is distinct from the particular facts it tests.

An evaluator walks that structure recursively. It combines the results of subexpressions and calls a supplied function to interpret the base cases. For an email filter, those base cases might ask whether a sender or subject matches a condition; another application can use the same Boolean machinery with different predicates.

The example illustrates the combination of first-class functions, algebraic data types, and pattern matching. A type can describe exactly the shapes an expression may take, and a match can make the cases visible. I contrast this with Java, while acknowledging that the particular comparison is not entirely fair to Java.

OCaml has a wide dynamic range. It is concise enough for tasks one might otherwise approach with a scripting language, yet compiles to efficient code and offers expressive static types. At Jane Street we use it for scripts, configuration-related work, and trading systems alike.

Using one language across many kinds of work has organizational benefits. Libraries and ideas can be shared, and people can move between projects more easily. At the time of this talk, the firm had roughly 400 employees, including about 70 full-time developers.

A reasonable concern is whether a relatively unfamiliar language is too difficult for people to learn. I do not think OCaml requires unusually brilliant programmers, although I recognize that my own experience may reflect selection bias.

Our trader training includes about a month of programming instruction. Roughly half of participants become productive programmers. We also saw interns with different prior preparation—including Harvard students who had studied OCaml and MIT students who had not—make progress on a simple project after a few weeks.

Another concern is recruiting. Early on, we posted to an OCaml mailing list, received about 15 responses, pursued a dozen, brought five people in, and hired three. That was useful when we were small, but the more lasting effect has been that our choice attracts people interested in the language who might not otherwise consider a financial firm.

Stephen Weeks is one example of someone whose interest in the technical work helped bring him to Jane Street. The language choice can therefore be a recruiting advantage as well as a constraint, though it will not appeal to everyone.

The biggest drawback is the smaller ecosystem. There are fewer readily available libraries and tools than in the most popular languages, and we have had to invest in improving the surrounding infrastructure. Projects such as OPAM, Merlin, OCP-indent, and documentation tooling have helped, but the cost is real.

For us, the benefits have justified that investment. I am not claiming that OCaml is universally the right choice; I am explaining why the combination of expressive types, functional programming, speed, and a shared language has worked well in our setting.

Asked why these ideas have not spread faster, I point to network effects and inertia. People are trained in existing tools, organizations have existing code, and programming languages also inspire strong personal commitments. It is difficult to establish a single cause for adoption or the lack of it.

Measuring a language's productivity advantage is also difficult. The most important differences may emerge over years of maintenance and across a large codebase, rather than in a short comparison of how fast someone writes a small program. That makes confident numerical claims hard to substantiate.

The audience asks about adoption elsewhere. Functional languages and related ideas have found use at other companies, including Facebook's work on Hack and Flow and Twitter's use of Scala. These examples describe the landscape at the time of the talk; they do not imply that every organization should make the same choice as Jane Street.

Language choices are shaped by technical requirements, existing communities, available tools, and the people an organization can attract and train. Our experience is that an unconventional choice can be practical when its strengths match the work and the organization is willing to invest in the ecosystem.