Looking Back on 2025: What Did We Do for OCaml?

Tarides' mission is to make OCaml mainstream by boosting adoption, supporting existing projects and industry applications, and creating new opportunities for the ecosystem. This post will share our biggest projects, their motivations, and the impacts we achieved in 2025 to give you an overview of how we worked toward our mission this year.

TL;DR: Last year, we organised our projects into three pillars: better tools and improved workflows; performance, runtime, and deployment; and improving the OCaml compiler. For the first pillar, we integrated both OCaml-eglot and OCaml.nvim with ocaml-lsp; introduced structured refactoring operations to Merlin; brought Dune closer to being a Cargo-inspired package management workflow; improved specification-based workflows in OCaml using Ortac and QCheck-STM; restored Solo5 support for MirageOS and introduced Unikraft support for MirageOS; released odoc 3.

For the second pillar, we adapted the memory profiler statmemprof to be compatible with OCaml5 and increased the visualisations available in memtrace; released the first feature-complete version of WSOO and improved its performance; collaborated with our partners to understand how they were using OCaml 5 and what improvements would help them use it to its full potential.

The last pillar saw the restoration of MSVC port; implemented support for OCaml 5 in LLDB to improve debugging on macOS; introduced a ‘relocatable compiler’; made several improvements to OCurrent’s build and CI pipelines; brought support for an unloadable runtime.

We also provided platform support and upstreamed new OxCaml features to mainline OCaml, and helped the community by sponsoring events like FUNOCaml, JFLA 2025, SPLV 2025 summer school, and the Outreachy internship programme.

Better Tools and Improved Workflows

Each year, we use community, industry, and internal feedback to identify opportunities to improve tools and development workflows. In 2025, this work included editors, package management, new specification-based workflows, unikernels, and documentation.

OCaml-Eglot & OCaml.Nvim:

Until recently, each editor shipped its own integration with its own features, failure modes, and maintenance burden. This approach made for an uneven experience for the users and created a lot of extra work for maintainers. The solution was to add first-class LSP support to both Emacs (via OCaml-eglot) and NeoVim (OCaml.nvim). Now, VS Code, Emacs, and NeoVim editors are all integrated with ocaml-lsp, meaning that their compatibility is managed through the LSP, while their plugins provide support for OCaml-specific features on top. You can read more about the new tools in our blog post on OCaml-eglot and our post about OCaml.nvim.

Merlin:

Merlin is the most popular editor service providing IDE services for the language. This year, we introduced structured refactoring operations to Merlin, taking inspiration from other languages and editors like IntelliJ, replacing brittle text-based transformations on large codebases. For example, experimental support for project-wide renaming arose out of the refactoring work.

Merlin also got a profiling framework, [Merl-an], that can generate queries to analyse the performance and behaviour of the editor service. We used Merl-an to start the process of checking and improving Merlin’s behaviour and performance on large codebases.

Dune Package Management

We have continued our efforts towards a unified Cargo-inspired Dune-based package workflow in OCaml in 2025. We have spent a lot of time prototyping the best ways to turn Dune into a package manager by conducting user research, analysing the outcomes when testing the prototype workflow, and adjusting designs to preserve compatibility with opam-based workflows and maximise compatibility with our target platforms.

In the process, we have fixed bugs, normalised rules and metadata, and ensured consistent behaviour for dependency resolution, cross-compilation, and documentation generation across Dune and the compiler toolchain. During the latter half of the year, Tarides has also tested and documented OxCaml support from within Dune-based package workflows.

Specification-Based Workflows: Ortac and QCheck-STM

Thanks to an R&D grant awarded as part of ETAPS’25, we have, in collaboration with Inria, been able to explore specification-based workflows through Ortac/QCheck integrations. Ortac translates computable Gospel terms into equivalent OCaml expressions, and different Ortac modes can use these translations to generate OCaml code. The Ortac/Qcheck mode generates black-box model-based state-machine tests based on the QCheck-STM framework. While the tools remain experimental, it is an important step towards providing easy dynamic formal verification in OCaml, and bodes well for future work.

MirageOS

MirageOS has also gotten several improvements over the past months. At the beginning of the year, we restored support for the Solo5 backend, which was a significant first step towards full OCaml 5 support for MirageOS. Unikraft support for MirageOS was achieved later in 2025, which brought performance improvements, new potential targets for MirageOS, including Firecracker, and the promise of future multicore compatibility, which will let MirageOS support the full set of OCaml 5’s features.

Thanks to funding from BPI France, SpaceOS and ORCHIDE have received further investment as part of the CEOS project. Its aims are to create the next generation of efficient, multi-purpose satellites. The operating system SpaceOS is built on MirageOS unikernel technology, and investment in one will ultimately benefit users of the other.

Odoc

2025 saw the release of [odoc 3.0](https://ocaml.org/changelog/2025-03-20-odoc-300), a big update to the documentation tool for OCaml that brought some major new features. Our team was happy to collaborate with experts in the wider OCaml community to bring big workflow improvements to not only odoc users but also the many more end users of the documentation itself.

The major new features include search by type, support for images and global sidebars, cross-package links, and more! Impressively, the search tool Sherlodoc can now find a value given its type in a vast sea of data and text. This makes editing and navigating documentation much easier.

Performance, Runtime, and Deployment

Another focus area for 2025 was performance, including restoring familiar monitoring tools and observability workflows, improving OCaml performance for a popular compilation target, and identifying how we can improve OCaml 5 and multicore in production environments.

Memory Profiling

Early in the year, we adapted the memory profiler statmemprof to be compatible with OCaml 5. It takes a random memory sample and executes an action decided by the user, such as determining the sample object’s size, where it came from, or what the program was doing at the time. Adapting the algorithm for parallelism was a delicate operation that took a lot of theoretical consideration and hands-on testing to get right. Thanks to this effort, profiling libraries like memtrace are available to OCaml 5 users.

The memtrace library can take statmemprof data in Common Trace Format and turn it into visualisations like flame graphs, making complex data easier to read. Another one of our 2025 projects was to create an even greater variety of visualisations for users of memtrace to give them more choice and simplify the task of monitoring performance. We added support for pprof traces, which can highlight the top allocating locations of an OCaml program and break them up based on memory size.

Wasm

Wasm_of_ocaml translates OCaml bytecode to WebAssembly, and 2025 saw the first feature-complete release of this compiler. WebAssembly provides a sandboxed environment and enforces memory safety, and is therefore well-suited for security-critical applications.

We can’t talk about wasm_of_ocaml without talking about performance. At the time of the release, the team had benchmarked Wasm_of_ocaml against both Js_of_ocaml and OCaml’s native compiler code ocamlopt, with results showing that programs compiled with OCaml’s WebAssembly compiler outperformed the others. During the course of this year, we have brought further optimisations to Wasm, including rewriting inline passes, updating the backend function supporting Bigarray accesses, introducing function call improvements, and more.

Helping Customers Make the Most of OCaml 5

In addition to monitoring and improving performance, we have been collaborating with our partners to understand how they are using OCaml 5, what challenges they have and which tweaks they would like to see. These insights have given us a clearer understanding of how multicore behaves in production. We have uncovered GC pacing issues, analysed scheduler behaviour under load, and discovered allocation patterns that only appear on large codebases. We will keep supporting OCaml 5 adopters and help them reach their goals with multicore in 2026.

Improving the OCaml Compiler

We are core maintainers of the OCaml compiler. In 2025, as is the case every year, we focussed on strengthening the existing foundations of the compiler and introducing new and improved workflows.

MSVC

We brought support for the MSVC port to OCaml 5 this year, restoring the toolchain for Windows compilation to users who prefer it. To restore the port, our team delved into C11 atomics, making suggestions to improve compatibility with MSVC since OCaml 5’s runtime requires it. Once Windows introduced support, our team tested its reliability, ported winpthreads to MSVC, and created a continuous integration workflow.

MSVC is popular among developers, and many are familiar with it, which is why we prioritised its OCaml 5 port even when it looked like it would be more complex than we first anticipated.

Debugging on MacOS

Following on from restoring familiar tools, we also updated [LLDB](https://lldb.llvm.org/) to ensure its compatibility with OCaml 5. LLDB is the primary supported debugger for macOS, helping users to trace, manipulate, and visualise the state of a target program running on their system. LLDB is not only popular and therefore a well-known workflow for users, but it is also well-maintained and comes bundled with XCode. Restored support for the latest version of OCaml is a big boon for our macOS users, providing an important workflow improvement for a significant chunk of the OCaml community.

Relocatable OCaml

In 2025, our teams also worked on ‘Relocatable OCaml’. The term ‘relocatable’ refers to its ability to “reliably distribute pre-compiled libraries for a given system”. The change allows users to clone their compiler and build it again on a different switch.

Traditionally, OCaml has compiled the compiler from source code, which takes a lot of time. Combined with needing a compiler installation for each project, a lot of time and resources were wasted on setup. Now, users can ‘move’ their compilers to new locations without the need to build a new one from scratch.

OCurrent

OCurrent, an embedded domain-specific language for describing workflows and pipelines, is the wider CI infrastructure that powers much of the OCaml ecosystem. Since OCurrent’s pipelines are self-adjusting, it is particularly well-suited for long-running, continuously evolving systems that emphasise correctness. In 2025, we made several improvements to OCurrent’s build and CI pipelines, and will continue to bring more tweaks to performance and reliability in 2026.

Unloadable Runtime

In the 5.4 update we brought support for an ‘unloadable runtime’ to OCaml 5 with a ‘memory cleanup on exit’ mode. This mode ensures that all OCaml runtime resources are ‘unloaded’ when control switches from the OCaml library to the main program. This includes the stack, heap sections, code fragments, custom operations, buffers, and tables. With a new ‘memory cleanup on exit’ mode compatible with multiple domains, OCaml 5 users can expect a clean handover from the runtime to the host program.

OxCaml

Jane Street released an open-source branch of OCaml, full of experimental extensions that they are using internally, to the wider community in 2025. Tarides has been providing platform support for OxCaml and helped upstream some OxCaml features into mainline OCaml. For example, labelled tuples and immutable arrays are two upstreamed features that we have supported.

The OxCaml branch is a great free resource for OCaml developers who want to benefit from Jane Street’s solutions to production-level challenges and test new extensions. We will continue to support OxCaml and the maturation of new features for OCaml in 2026.

FUNOCaml

Tarides was one of the sponsors for FUN OCaml in 2025. A two-day conference dedicated to OCaml, the weekend in Warsaw provided users with hands-on workshops, multiple talks, and several opportunities to mingle and form community connections. Tarides continues to fund programmes and events that benefit the OCaml community and provide opportunities for developers to get together.

Outreachy

Outreachy is an internship programme that provides paid, remote, three-month internships to candidates around the world. Their goal is to increase diversity in the Free and Open-Source Software space. Tarides supports Outreachy through sponsorships and by hosting internships. In 2025, the projects were

We also sponsored JFLA 2025 and the SPLV 2025 summer school in 2025, two more events which nurture up-and-coming talent and raise awareness about OCaml.

Coming Up in 2026

Our main pillars of focus for 2026 are:

• 1. Compiler evolution and upstream work,
• 2. Stable tooling that supports OxCaml and agentic workflows,
• 3. Performance engineering at scale.

More concretely, this means that for our compiler work, we are focussing on integrating OxCaml features that have already proved useful in production and moving more compiler logic from the tools to the compiler itself. The latter refers to features like cross-compilation, relocation, and Windows support, which should have first-class support in the compiler. A simpler toolchain, fewer duplicated patches, and faster feature development are all potential benefits of adopting this approach.

The stable tooling pillar includes finishing up dune pkg and establishing the package-management workflows, such as improvements to dependency vendoring, better integration with other ecosystems, faster setup for OxCaml environment, and more. We also want to make the OCaml Platform friendly to agentic tools which need structured, machine-readable descriptions of projects. Thirdly, we will strengthen the security tooling in line with the requirements of the [OCSF] to create a single, predictable tooling environment where the Platform components expose the information necessary to build correct and reliable tools. Lastly, the performance engineering work includes pushing performance boosts and other optimisations to the runtime and Platform tools. We will build and deploy the new benchmark framework, Sandmark 2, to compare OCaml 4, 5, and development branches under realistic conditions.

Until Next Time

You can connect with us on Bluesky, Mastodon, Threads, and LinkedIn or sign up for our mailing list to stay updated on our latest projects. We look forward to hearing from you!