Evolving the OCaml Programming Language (2025) [pdf]
kcsrk.info
kcsrk.info
This talk is a _subjective_ take on how the OCaml programming language evolves, based on my observations over the last 10 years I've been involved with it. My aim/hope is to demystify the compiler development process and the tradeoffs involved and encourage more developers to take a shot at contributing to the OCaml compiler.
Happy to answer questions, but also, more importantly, hear your comments and criticisms around the compiler development process, ideas to make it more approachable, etc.
[BTW we currently have open positions for two developers]
Great to hear about virt-v2v. I will reach out to you by email.
Could you share some more details about where this project is used? Links to those open positions for OCaml developers would be interesting too, not for myself :-)
No mention of OCaml though.
I've been exploring converting them into OCaml as the C versions are very segfault-prone.
What should a beginner in compiler development, someone who has written a few compilers of their own, do to get involved in a project such as OCaml? I understand this issue is not specific to compilers, but is faced by any sufficiently large project. Still, I think it's an important issue. I believe there are many resources for people to get up and running in a field but not enough for them to make the next jump into industrial projects.
Make sure you have installed and are using the software. Ideally you'd have an ongoing interest in it because it's something you use regularly (whether personally or for work).
Read first, especially the documentation, guidelines to contributing, mailing lists / Github issues / however else the upstream maintainers engage with each other.
Start small. Actually a great place is just to go and fix spelling mistakes and typos in documentation, code, comments, etc. Follow the guidelines for contributing to the letter, even if they appear over-complicated at first.
After you've engaged with small patches, build up. Look through their issues and (since you're using the software every day) find something that is an "itch" that you want to "scratch", and attempt to fix that.
I don't really need to go further because either at some point in this process you'll have become discouraged (for good or bad reasons), or you'll have found your community and will want to contribute more and more.
The dynamic arrays case is a good illustration. What began as a small PR grew into years of design iterations, debates about representation, performance, and multicore safety, and eventually a couple of thousand lines of code and more than 500 comments before it landed. From one perspective, that looks discouraging. From another, it shows the weight we place on getting things right, because once a feature ships, it is very hard to undo.
That tension, between wanting to be open and encouraging contributions but also needing to protect stability, is something I think we should be talking about openly. My hope is that by making the process more visible we can demystify it and help contributors understand not just what happened, but why.
However, none of the authors of those libraries were really happy with their own implementation because those implementations had to choose between performance, API usability or thread safety.
When I closed the student pull request (which was a naive implementation with no unsafe features), it was with the idea that it was unfair to expect a beginner use to solve those issues.
The subsequent iterations explored different part of the design space before the final iteration which converged to safely using unsafe language features to reach a new local API optimum.
And if you want more features with a "fix as you go approach" you will often have huge technical debt and get saddled with poor interfaces, often forever.
But, I think OCaml errs too much on the side of getting it right the first time. The result is that state of the art keeps moving far ahead. By the time OCaml "catches up" the field of programming languages has moved far ahead. So OCaml always remains the Jack of all trades and the master of none (IMHO).
I like the direction OxCaml is taking. But the problem is that no one has another 10 years to see its learnings get folded back into OCaml. There is a real chance that OxCaml may diverge so much that it becomes impractical to merge it into OCaml. Flambda2 is another great piece of software that may also take a long time to come into OCaml proper.
So I feel that things need to be "speeded up" if OCaml has to become a bigger ecosystem. You can see that some big projects are moving away from OCaml -- facebook for instance used to have their python typechecker in OCaml. Their new one, pyrefly is in Rust. This could be an isolated story, no doubt.
So here we have gotten the worst of both worlds -- a language that is evolving slowly and a language that has large features that are almost soft discouraged. My primary language is Rust and not OCaml (mostly dabble in OCaml) so I may not fully know what I'm talking about when it comes to OCaml.
It's literally just objects, one large (and early!) feature. Arguably too large compared to the rest of the language: first-class modules or polymorphic variants can handle most of their use cases while being much simpler, and faster than the existing class system. (Objects and object types without the actual classes are maybe ok.)
The only other controversial feature I can think of is Seq and that's just because it can be allocation-heavy. Then again ordinary OCaml lists are not much cheaper (thankfully immutable arrays are already in for 5.4).
They're conceptually nice, specially the in-place object syntax, but the class syntax feels tacked on and the overall implementation is very naive compared to a proper OOP runtime like CLR/JVM/JS.
I suggest reaching for them only when first-class modules aren't enough (i.e. you need open recursion). Even then you could sometimes get away with polymorphic variant constraints, but that's admittedly harder to read and understand.
Hard to reconcile with the fact that Ocaml had 90% of the features people like in Rust today twenty years ago, a module system which is still better than Haskell, and is currently implementing a full effect system.
It still pretty much ahead of every mainstream languages.
The module system though powerful is quite awkward and verbose. I personally prefer adhoc polymorphism (class/instance in Haskell, trait/implementation in Rust). That is really missed in OCaml and is likely to be missing for the next few years even though there have been (stalled) efforts like Modular implicits in the past.
Haskell and Scala seem to have many features lacking in OCaml. Some of those features are excessive I'll admit and OCaml can argue that it is more minimalistic (which is also useful).
Yes, effects are definitely a cutting edge feature in OCaml. But they are untyped which is a big limitation I would say.
TL;DR -- OCaml does many things well. It's a good language. My main point is that the language needs to speed up its pace of evolution. OCaml's lunch is being eaten up by lower level and performance oriented languages like Rust. At the higher level it is being squeezed by Lean, Haskell, Fstar etc.
Deeply disagree. It’s a lot easier to use and reason about that type classes. You can use Haskell if that’s what you want anyway. I’m glade Ocaml isn’t Haskell.
> Yes, effects are definitely a cutting edge feature in OCaml. But they are untyped which is a big limitation I would say.
APersonally I think it’s an insignificant limitation for a feature existing approximately nowhere else. Anyway I think we have safely killed your initial argument that Ocaml was somehow lagging behind.
I think the acceptance threshold can be much lower in other kinds of tooling. "It is what it is", so to speak.
Get the API right first. Make sure it’s correct, safe, and useful. Iterate on the performance afterwards.
IMO, a lot of contributions should take this shape.
But yes, the standard library has added many helper functions that were sorely needed during the last few years, and the upcoming 5.4 keeps adding more. Still not as many goodies as Jane Street's libraries, but nowadays I don't miss them as long as I can use just a few small libraries, mostly by dbunzli and c-cube.
There's nothing inherently wrong with them, aside from their API being unstable, but they're an opinionated wedge in an ecosystem already lacking the cohesion of newer languages.
Don't know if this would be of value to you. You can check out my blog built with OCaml, its made from my custome static site generator. https://www.fearful-odds.rocks
Because exceptions aren’t checked, this effectively means that a language designed for type safety has as much type safety as python, because it’s very easy to forget handling something, and get runtime errors.
How do you deal with this day to day? I assume it’s impossible to just believe that all the code you pull in doesn’t use exceptions?
There's no type unsafety from unchecked exceptions, because uncaught exceptions are not unsound. Even Haskell has them (error and undefined), because from a theoretical standpoint they're equivalent to reaching an infinite loop. (Now, recovering from an exception isn't unsound either, but it might mess with your usual mutable invariants.)
In more practical terms, concerning overall correctness, OCaml has been adding option-returning variants of those functions, so most exceptions raised from the stdlib nowadays are much more likely to be intended by the author.
I'm not a fan of Rust as a language for many reasons, but I will give it credit for making proper usage of the Result monad. They could have abused Option the same way Haskell abuses Maybe, but they didn't.
> [Haskell] doesn't provide a meaningful distinction between "This function might not return anything, and this is defined behavior" and "This function has a singularity"
I think Haskellers should fear divergence less, or push for SPARK-like static checking. In OCaml, the current trend would be to represent "not return anything" as None; and "has a singularity" by raising Invalid_argument or similar when the singularity check was considered a precondition, or returning Error (or an equivalent variant) for expected inputs.
Usage of Result in OCaml is also growing, thankfully. It's part of the stdlib, and we can use binding operators (let* foo = result) to do the same as ? in Rust (or let! in F#). OCaml 5.4 is even adding a Result.Syntax module so we can just open it instead of defining (let*) ourselves.
On the other hand, Result doesn't give us backtraces, and composes badly with other combinators or imperative flow. In my current project I'm instead giving a try to an effectul result_scope/get_ok API, which composes better.
Rust also has exceptions aka panics
That's an exaggeration.
You can use error types / monads like you would do in Rust/Haskell. When you use the Core standard library, you can use function who don't throw exceptions. Those who do use specific name conventions (foobar_exn).
Factor (Forth-like language) implements even its own ":" (defines a word, i.e. a function) using the language itself, it is not builtin, same with "if", and so forth. Thus, "MEMO:" or locals[1] ("::") being implemented as a library does not mean it is a bad thing, on the contrary, in the case of Factor, it makes it quite powerful. The object system is entirely implemented in Factor, too. "Large chunks of functionality are not part of the core language, they are in just as library".[2]
And to compare OCaml's type system to Python's is straight out absurd.
[1] Locals are entirely implemented in Factor, too, which is only about ~500 lines of code. It is not part of the core language, and on top of that, there is no performance penalty whatsoever!
[2] See more here: https://www.youtube.com/watch?v=f_0QlhYlS8g.
You criticized Haskell as not a great example of error handling. Well, Erlang/Elixir also have exceptions, and they are considered the industry leader in error recovery.
Exceptions are actually fine, it doesn't really take much to install handlers which take care of catching, logging, telemetry, re-raising etc. They mostly get a bad rep because of the latest fashions in the PL space.