The future of OCaml, 2023 edition?

Hi folks,

The Future of OCaml page on OCamlverse needs some love, considering that an issue on GitHub from 2021 is still relevant. Although I have just posted what I am aware of on the GitHub issue, some of you should know even more.
The page is the top result when you search “Future of OCaml” on Google, so leaving the page outdated will affect the impression of the language negatively. Shall we improve it?


PRs are more than welcome.


At the time I am reading this, the page sections are:

  • Flambda 2.0
  • OCaml 5.0 (multicore stuff)
  • Typed algebraic effects
  • Modular Implicits (marked as long-term)

A trivial change would be to just remove the “OCaml 5.0” section, as it is already released. The page would not be outdated anymore, as far as I can tell. You could also:

  • move “typed algebraic effects” to a long-term plan (more realistic)
  • consider replacing the “OCaml 5.0” section with medium-term plans on multicore-related changes in the broader ecosystem; but that would be much more work

In summary, I think that it is relatively easy to make the page good again: just remove the stuff that has been merged.


Absolutely, so do I: Update the "Future of OCaml" page by omasanori · Pull Request #184 · OCamlverse/ · GitHub

Thank you for your guidance!

I have been revising the page on the PR above, so please feel free to review and drop a comment.

1 Like

The PR is ready for review.

Update: It was merged, thanks @bluddy!

1 Like

So, I started to revise the page again: More update on the Future of OCaml by omasanori · Pull Request #185 · OCamlverse/ · GitHub
(I put multicore thing into short-term plans since I feel like it is not the same time-scale as Flambda2 is.)

Does anyone have any other ideas or opinions? Unboxed types? Locality and ownership? (I, as a former Rust compiler contributor, am so excited with these articles.) Others?


I chose WebAssembly (mid-term) in addition to modes (locality and ownership) and unboxed types (both long-term). It will take some time to summarize modes and unboxed types. Comments are highly welcomed.

The PR is ready for review.

You did an impressive amount of work compiling links and preparing descriptions for these features. Some of the writing I find a bit optimistic (Is Flambda2 highly anticipated?), but you did you work, so you get to choose the style.

I wonder what people have in mind when they read “the future of OCaml”. There is a difference between Multicore OCaml, which for several years was known as “not merged yet but we are hoping to merge it eventually”, and the 50 shades of mode systems for ownership that no one except the blog post author understands. When we say “future”, do we mean that we collectively believe that all of these things are eventually going to be integrated? Or is it to be understood more like “a bunch of cool experiments, some of which may be in our future”? It could be useful to clarify that.

With a broad interpretation of “cool stuff for maybe someday”, other language-related experiments that I personally find interesting include:

  • the COCTI project
  • verification tools for OCaml, in particular Gospel combined with Camleer
  • BER MetaOCaml
  • Malfunction (the idea of a well-specified untyped IR that other tools can produce), that the MetaCoq people seemed to seriously consider using at some point

Thank you for your feedback, @gasche !

Indeed. I chose the topics that, at least, someone in major contributor company is actively working on and/or someone has presented at conferences or workshops. I think this criteria would reject cool ideas with no one getting one’s hands dirty nor considered seriously. The point may be the interpretation of the first sentence.

Some interesting news/developments coming up in OCaml’s future:

I felt that it is not a strict roadmap with consensus but rather a list of hints one can imagine the future from. Nevertheless, my choice is admittedly optimistic and need some adjustment.

Can I ask about the other two new topics (WebAssembly and unbox types) I picked from your point of view?

Both are interesting topics. I believe that a wasm backend will happen real soon – medium-term. There are two groups working on this (@zapashcanon and @chambart working on a compiler backend, @vouillon working on a js_of_ocaml backend), and the js_of_ocaml approach will be easy to deploy without any compiler change whenever it is ready.


Thank you for sharing your opinion!

So, I found that the word plans sound assured. I think it is better to have a separate section for noteworthy things in early stages like modes. I will revise the text this weekend…

Daemonize the compiler and tools so they can run as [Remote Persistent Workers - EngFlow Documentation](https://persistent workers). (Bazel: persistent workers).

1 Like