OCaml Weekly News

Recent actions

• Education and outreach
  

  We funded a new edition of the Spanish summer school on functional programming in OCaml, organized in Saragossa by Ricardo Rodriguez and Roberto Blanco.

  We continued funding the OCaml meetups in Paris and Toulouse, France. In 2024, a new meetup started in Chennai, India (first discuss thread), which we are delighted to support as well.

  We are sponsoring the JFLA 2025, a functional programming conference in France, and an OCaml Bridge Workshop at Functional Conf 2025, a large Asian conference on functional programming.

• Research
  

  The OCaml Software Foundation is typically not involved in funding research, focusing on actions that have an immediate impact on the language and its community. Nevertheless, in 2023 we funded one year of post-doctoral work for Takafumi Saikawa in relation to his maintenance work on the type-checker of OCaml. In 2024 we funded one year of research engineer for the Salto project, building a static analyzer for OCaml, and one year of PhD grant for Alistair O'Brien in Cambridge (complementing other funding sources for a full PhD), continuing his impressive work on constraint-based type inference for OCaml.

• Ecosystem
  
  • Infrastructure
    

    As in previous years, we fund the work of Kate Deplaix to check that the OCaml ecosystem is compatible with upcoming compiler releases; in 2024 Kate worked on OCaml 5.2 and 5.3.

    We are trying our best to support the work of opam-repository maintainers, through individual funding grants for the active maintainers. This year, on the suggestion of the repository maintainers, we are also funding the work of Robur to migrate unmaintained packages to a separate archive (discuss thread 1, thread 2).

  • Tools
    

    In 2024 we have funded one month of maintenance of the opam client by Raja Boujbel and her colleagues.

    We renewed our partial support for the work of Antonio Monteiro on Melange. For more Melange news, see for example the announcement of Melange 4.

  • Libraries
    

    We keep supporting the work of Petter Urkedal on the Caqti library, the main database connection library in the OCaml community.

    The Owl library for scientific computing has been restructuring in 2024, with its two maintainers moving to permanent jobs demanding their time and therefore less available. The OCaml Software Foundation is providing a small grant to help the maintainers transition to a different contribution model and/or preserve a part of their maintenance activity, as they think is best.

    We have been funding documentation work by John Whitington to collect or create usage examples of important OCaml libraries, prior to their upstreaming in the documentation of each project. See his ocaml-nursery repository.

    We support the contributions of Daniel Bünzli to the OCaml ecosystem. This year, Daniel used this support to fund the development of

    • jsont, a new library for declarative JSON data manipulation
    • bytesrw, a library of composable byte stream readers and writes, with support for various compression and hashing algorithms
    • support for Unicode 16.0 in his Unicode libraries

    Finally, we have been funding Nathan Rebours to take an active part in the maintenance of the ppxlib project, see his ppxlib maintenance summary.

Changes summary

• 5.3 compatibility
  

  ppxlib.0.34.0 is the first official ppxlib release that's compatible with the new 5.3 compiler.

  The ppxlib driver now also comes with a -keywords CLI option, similar to the compiler's that allow you to compile and preprocess with the 5.3 compiler code that uses effect as an identifier. This is pretty niche but it's there should you need it.

  Please note that means you can use ppx-es with a 5.3 compiler but not that ppx-es can consume/produce 5.3 language features. We're currently working on a fix allowing you to use the effect syntax in files that require preprocessing as it's not possible with 0.34.0. The fix should be released in the next few days as 0.34.1.

• AST pretty-printing
  

  We added a new Pp_ast module that allows you to pretty print AST fragments.

  The only way ppxlib would print ASTs before were as S-expressions. In practice we found that it was not always helpful and wanted a more readable and human friendly way of displaying the AST.

  The default output of those printer is a simplified version of the AST to keep things clear and avoid cluttering the output with information that is not always useful. For example, if you run Ppxlib.Pp_ast.Default.expression on the AST for x + 2, you'll get the following:

  Pexp_apply
    ( Pexp_ident (Lident "+")
    , [ ( Nolabel, Pexp_ident (Lident "x"))
      ; ( Nolabel, Pexp_constant (Pconst_integer ( "2", None)))
      ]
    )
  

  The alert reader will note that there are no locations or attributes and that the expression record layer is omitted here.

  You can of course configure the printer to display more information if you need to.

  We've been using these new printers internally to debug migration code and they have been a huge help so we hope they will make working with ppxlib easier for you too.

  In addition to this new module, we also added a command line utility called ppxlib-pp-ast to pretty print ASTs from source files, source code fragments or even marshalled AST files. It is very similar to the old ppx_tools's dumpast.

  Note that it will print ppxlib's internal AST after it's been migrated from the installed compiler's version. This is something that we could not simply achieve with OCaml's own -dparsetree.

  This should be a useful tool for debugging ppx related bugs or learning about the AST and we hope ppx authors and users will like it.

• Other changes
  

  As mentioned above, we also added some missing Pprintast~¹ entries such as ~binding, longident and payload.

  It is now possible to use [@@deriving ...] on class type declarations and therefore to write derivers for class types.

  ¹: To the confused readers: Pprintast is entirely different from Pp_ast mentioned above as it prints the source code corresponding to a given AST.

Plans for the next release

• Internal AST bump to 5.2
  

  Our next release will bump our internal AST to 5.2. It is a pretty big change because 5.2 changed how functions were represented in the AST and this impacts A LOT of ppx-es.

  @patricoferris has been working very hard on this over the past few months to minimize the amount of breakage and to send patches upstream where that was not possible to get the rest of the ecosystem ready for the bump.

  We wanted to first release the 5.3 compatibility but now that's out of the way we're able to focus on the bump again.

  @patricoferris will create a dedicated thread shortly to explain a bit what's been going on and what to expect from this release.

• Drop support for OCaml < 4.08
  

  It is time for us to drop support for very old compilers. Keeping support for OCaml 4.07 and before requires maintenances of quite heavy compatibility layers and prevents us from using some language features in ppxlib's source code while providing little to no benefits since the vast majority of users already upgraded to much more recent compilers.

  If you're still relying on those older compilers and the newest ppxlib, please reach out, either here or via a ppxlib issue.

Special thanks

Cachet, a library for mmap syscall

+--------------+-------------+----------------+-----------------+
|              | with cachet | without cachet | git verify-pack |
+--------------+-------------+----------------+-----------------+
|         time |       17.8s |          41.8s |            9.3s |
+--------------+-------------+----------------+-----------------+
| cache misses |        936M |          1933M |            246M |
+--------------+-------------+----------------+-----------------+

• Cachet & schedulers
  

  Like most of our projects, Cachet is independent of schedulers. There is therefore a variant with Lwt and a variant with Miou. However, we need to clarify a behaviour related to the use of Cachet. Reading a file, whether with read(3) or mmap(3P), does not block, but it can take some time.

  As we have already experienced and explained here, it may be necessary to explain to the scheduler whether it is appropriate to do something else after such a syscall. In the case of Lwt, it might be a good idea to insert Lwt.pause just after our syscall so that Lwt gives another service the opportunity to run despite the time taken trying to read from a file. However, particularly for Lwt, this means closing Cachet in the hell of the monad (in other words, there is no way to escape it) because of this possible Lwt.pause (which returns unit Lwt.t).

  The composition of Cachet with Lwt is therefore quite different from what we've been able to experiment with. One of our other articles suggests not using functors (too much), and although we can in fact abstract Lwt.t from unit Lwt.t (and even reduce it such that type 'a t = 'a) with the HKP trick, we opted for composition by hand.

  The problem relates to Lwt (and Async) and doesn't apply to Miou when it's possible to raise effects. However, from such a composition, a choice has been made to give Lwt the opportunity to do something else after mmap. We could, in other types of applications, make another choice on this precise question.

Carton

$ opam install carton.1.0.0
$ git clone https://github.com/ocaml/ocaml
$ cd ocaml/.git/objects/pack/

$ carton verify pack-*.pack

$ carton get pack-*.idx 89055b054eeec0c6c6b6118d6490b6792da7fef2

$ mkdir loose
$ carton explode 'loose/%s/%s' pack-*.pack > entries.pack

$ carton make -n $(cat entries.pack | wc -l) -e entries.pack new.pack
$ carton index new.pack
$ carton get new.idx 89055b054eeec0c6c6b6118d6490b6792da7fef2

+--------+-------------+----------+-------+--------------+
|        | pack-*.pack | new.pack | loose | loose.tar.gz |
+--------+-------------+----------+-------+--------------+
|   size |        355M |     648M |  8.3G |         1.8G |
+--------+-------------+----------+-------+--------------+

+--------------+-------------+----------+---------+
|              | pack-*.pack | new.pack | loose   |
+--------------+-------------+----------+---------+
| git cat-file |     ~ 0.01s |      N/A |     N/A |
+--------------+-------------+----------+---------+
|   carton get |     ~ 0.20s |  ~ 0.30s |         |
+--------------+-------------+----------+---------+
|          cat |         N/A |      N/A | 0.0006s |
+--------------+-------------+----------+---------+

• Carton & parallelism
  

  As always, our libraries are independent of schedulers. There is a version of Carton with Lwt and a version with Miou.

  Some of the tasks Carton performs, such as indexing, are highly parallelizable. In this case, the new derivation of Carton with Miou exists to take advantage of the latter's domain pool.

  It was also quite easy to parallelize the work on carton index and carton verify. Here are some other metrics which, thanks to OCaml 5 and Miou, bring us closer to Git performance:

  $ hyperfine \
    -n git \
      "git verify-pack pack-03a3a824757ff4c225874557c36d44eefe3d7918.idx" \
    -n carton \
      "carton verify pack-03a3a824757ff4c225874557c36d44eefe3d7918.pack -q --threads 4"
  Benchmark 1: git
    Time (mean ± σ):     329.2 ms ±   0.9 ms    [User: 384.2 ms, System: 27.8 ms]
    Range (min … max):   327.7 ms … 330.9 ms    10 runs
   
  Benchmark 2: carton
    Time (mean ± σ):     712.1 ms ±  10.9 ms    [User: 1111.8 ms, System: 1112.6 ms]
    Range (min … max):   695.4 ms … 726.8 ms    10 runs
   
  Summary
    git ran
      2.16 ± 0.03 times faster than carton
  

  NOTE: it may come as a surprise that Carton is 2 times slower than Git for analysing a PACK file, but it should be noted that almost the entire Carton implementation is in OCaml! At this stage, the idea is more to give you an idea, but we literally find ourselves comparing a Bugatti with a Citroën 2CV.

• Carton & Emails
  

  Finally, this in-depth rewrite of Carton allows us to take advantage of the PACK format for storing our emails.

  In fact, we are experimenting with and developing an email solution within our cooperative, and email archiving is one of our objectives. Based on our experience of implementing Git, we thought that the PACK format could be a very interesting format for archiving emails.

  It combines two features, rapid access to emails and compression by patches, which are very interesting when it comes to handling emails. Finally, it also corresponds more or less to the way we use email:

  • we don't want to delete them (more often than not, we want to keep them ad vitam aeternam)
  • and we don't modify them

  It therefore corresponds to a sort of read-only database. For more details on this aspect of Carton and the results of our experiments, I suggest you read our recent article on our cooperative's blog.

More precisely

User feedback and future development

:calendar: Agenda

:computer: Links

Better Tools: Toward a 1-Click Installation of OCaml

• OCaml.org
  

  OCaml.org is the main entry point for new users of OCaml. Tarides engineers are key members of the OCaml.org team. Using privacy-preserving analytics, the team tracked visitor behaviour to identify key areas for improvement. This led to a redesign of the installation page, simplifying the setup process, and a revamp of the guided tour of OCaml to better introduce the language. Both pages saw significant traffic increases compared to 2023, with the installation page recording 69k visits, the tour reaching 65k visits and a very encouraging total number of visits increasing by +33% between Q3 and Q4 2024

  

  Efforts to improve user experience included a satisfaction survey where 75% of respondents rated their experience positively, compared to 17% for the previous version of the site. User testing sessions with 21 participants provided further actionable insights, and these findings informed updates to the platform. The redesign of OCaml.org community sections was completed using this feedback. It introduced several new features: a new Community landing page, an academic institutions page with course listings, and an industrial users showcase. The team also implemented an automated event announcement system to inform the community of ongoing activities.

  Progress and updates were regularly shared through the OCaml.org newsletters, keeping the community informed about developments. Looking ahead, the team will continue refining the platform by addressing feedback, expanding resources, and monitoring impact through analytics to support both new and experienced OCaml users. Lastly, the infrastructure they build is starting to be used by other communities: Rocq just announced their brand new website, built using the same codebase as ocaml.org!

• Dune as the Default Frontend of the OCaml Platform
  

  One of the main goals of the OCaml Platform is to make it easier for users—especially newcomers—to adopt OCaml and build projects with minimal friction. A critical step toward this goal is having a single CLI to serve as the frontend for the entire OCaml development experience (codenamed Bob in the past). This year, we made significant progress in that direction with the release of the Dune Developer Preview.

  Setting up an OCaml project currently requires multiple tools: opam for package management, dune for builds, and additional installations for tools like OCamlFormat or Odoc. While powerful, this fragmented workflow can make onboarding daunting for new users. The Dune Developer Preview consolidates these steps under a single CLI, making OCaml more approachable. With this preview, setting up and building a project is as simple as:

  1. dune pkg lock to lock the dependencies.
  2. dune build to fetch the dependencies and compile the project.

  This effort is also driving broader ecosystem improvements. The current OCaml compiler relies on fixed installation paths, making it difficult to cache and reuse across environments, so it cannot be shared efficiently between projects. To address this, we are working on making the compiler relocatable (ongoing work). This change will enable compiler caching, which means faster project startup times and fewer rebuilds in CI. As part of this effort, we also maintain patches to core OCaml projects to make them relocatable – and we worked with upstream to merge (like for ocamlfind). Tarides engineers also continued to maintain Dune and other key Platform projects, ensuring stability and progress. This included organising and participating in regular development meetings (for Dune, opam, Merlin, ppxlib, etc.) to prioritise community needs and align efforts across tools like Dune and opam to avoid overlapping functionality.

  The Dune Developer Preview is an iterative experiment. Early user feedback has been promising (the Preview’s NPS went from +9 in Q3 2024 to +27 in Q4 2024), and future updates will refine the experience further. We aim to ensure that experimental features in the Preview are upstreamed into stable releases once thoroughly tested. For instance, the package management feature is already in Dune 3.17. We will announce and document it more widely when we believe it is mature enough for broader adoption.

• Editors
  

  In 2024, Tarides focused on improving editor integration to lower barriers for new OCaml developers and enhance the experience for existing users. Editors are the primary way developers interact with programming languages, making seamless integration essential for adoption. With more than 73% of developers using Visual Studio Code (VS Code), VS Code is particularly important to support, especially for new developers and those transitioning to OCaml. As part of this effort, Tarides wrote and maintained the official VS Code plugin for OCaml, prioritising feature development for this editor. We also support other popular editors like Emacs and Vim—used by many Tarides engineers—on a best-effort basis. Improvements to OCaml-LSP and Merlin, both maintained by Tarides, benefit all supported editors, ensuring a consistent and productive development experience.

  

  While several plugins for OCaml exist (OCaml and Reason IDE–128k installs, Hackwaly–90k installs), our OCaml VS Code plugin –now with over 208k downloads– is a key entry point for developers adopting OCaml in 2024. This year, we added integration with the Dune Developer Preview, allowing users to leverage Dune's package management and tooling directly from the editor. Features such as real-time diagnostics, autocompletion, and the ability to fetch dependencies and build projects without leaving VS Code simplify development and make OCaml more accessible for newcomers.

  The standout update in 2024 was the addition of project-wide reference support, a long-requested feature from the OCaml community and a top priority for commercial developers. This feature allows users to locate all occurrences of a term across an entire codebase, making navigation and refactoring significantly easier—especially in large projects. Delivering this feature required coordinated updates across the ecosystem, including changes to the OCaml compiler, Merlin, OCaml LSP, Dune, and related tools. The impact is clear: faster navigation, reduced cognitive overhead, and more efficient workflows when working with complex projects.

  Additional improvements included support for new Language Server Protocol features, such as signature_help and inlay_hint, which enhance code readability and provide more contextual information. These updates enabled the introduction of new commands, such as the "Destruct" command. This little-known but powerful feature automatically expands a variable into a pattern-matching expression corresponding to its inferred type, streamlining tasks that would otherwise be tedious.

  

• Documentation
  

  Documentation was identified as the number one pain point in the latest OCSF survey. It is a critical step in the OCaml developer journey, particularly after setting up the language and editor. Tarides prioritised improving odoc to make it easier for developers to find information, learn the language, and navigate the ecosystem effectively. High-quality documentation and tools to help developers get "unstuck" are essential to reducing friction and ensuring a smooth adoption experience.

  Tarides is the primary contributor and maintainer of odoc, OCaml’s main documentation tool. In preparation for the odoc 3 release, our team introduced two significant updates. First, the odoc Search Engine was integrated, allowing developers to search directly within OCaml documentation via the Learn page. Second, the odoc Cheatsheet provides a concise reference for creating and consuming OCaml documentation. We would like to believe that these updates, deployed on ocaml.org, were the main cause of a 45% increase in package documentation usage on https://ocaml.org/pkg/ in Q4 2024!

  

  Another area where developers often get stuck is debugging programs that don’t work as expected. Alongside reading documentation, live debuggers are crucial for understanding program issues. Tarides worked to improve native debugging for OCaml, focusing on macOS, where LLDB is the only supported debugger. Key progress included a name mangling fix to improve symbol resolution, restoring ARM64 backtraces, and introducing Python shims for code sharing between LLDB and GDB.

  OCaml’s error messages remain a common pain point, particularly for syntax errors. Unlike Rust’s error index, OCaml does not (yet!) have a centralised repository of error explanations. Instead, we are focused on making error messages more self-explanatory. This requires developing new tools, such as lrgrep, a domain-specific language for analysing grammars built with Menhir. lrgrep enables concise definitions of error cases, making it possible to identify and address specific patterns in the parser more effectively. This provides a practical way to improve error messages without requiring changes to the compiler. In December 2024, @let-def successfully defended his PhD (a collaboration between Inria and Tarides) on this topic, so expect upstreaming work to start soon.

• OCaml Package Ecosystem
  

  The last piece of friction we aimed to remove in 2024 was ensuring that users wouldn’t encounter errors when installing a package from the community. This required catching issues early—before packages are accepted into opam-repository and made available to the broader ecosystem. To achieve this, Tarides has built and maintained extensive CI infrastructure, developed tools to empower contributors, and guided package authors to uphold the high quality of the OCaml package ecosystem.

  In 2024, Tarides’ CI infrastructure supported the OCaml community at scale, handling approximately 20 million jobs on 68 machines covering 5 hardware architectures. This infrastructure continuously tested packages to ensure compatibility across a variety of platforms and configurations, including OCaml’s Tier 1 platforms: x86, ARM, RISC-V, s390x, and Power. It played a critical role during major events, such as new OCaml releases, by validating the ecosystem’s readiness and catching regressions before they impacted users. Additionally, this infrastructure supported daily submissions to opam-repository, enabling contributors to identify and resolve issues early, reducing downstream problems. To improve transparency and accessibility, we introduced a CI pipeline that automates configuration updates, ensuring seamless deployments and allowing external contributors to propose and apply changes independently.

  In addition to maintaining the infrastructure, Tarides developed and maintained the CI framework running on top of it. A major focus in 2024 was making CI checks available as standalone CLI tools distributed via opam. These tools enable package authors to run checks locally, empowering them to catch issues before submitting their packages to opam-repository. This approach reduces reliance on central infrastructure and allows developers to work more efficiently. The CLI tools are also compatible with GitHub Actions, allowing contributors to integrate tests into their own workflows. To complement these efforts, we enhanced opam-repo-ci, which remains an essential safety net for packages entering the repository. Integration tests for linting and reverse dependencies were introduced, enabling more robust regression detection and improving the reliability of the ecosystem.

  To uphold the high standards of the OCaml ecosystem, every package submission to opam-repository is reviewed and validated to ensure it meets quality criteria. This gatekeeping process minimises errors users might encounter when installing community packages, enhancing trust in the ecosystem. In 2024, Tarides continued to be actively involved in maintaining the repository, ensuring its smooth operation. We also worked to guide new package authors by updating the contributing guide and creating a detailed wiki with actionable instructions for adding and maintaining packages. These resources were announced on Discuss to reach the community and simplify the process for new contributors, improving the overall quality of submissions.

Playing Better with the Larger Ecosystem

• Concurrent & Parallel Programming in OCaml
  

  "Shared-memory multiprocessors have never really 'taken off', at least in the general public. For large parallel computations, clusters (distributed-memory systems) are the norm. For desktop use, monoprocessors are plenty fast." – Xavier Leroy, November 2002

  Twenty+ years after this statement, processors are multicore by default, and OCaml has adapted to this reality. Thanks to the combined efforts of the OCaml Labs and Tarides team, the OCaml 5.x series introduced multicore support after a decade of research and experimentation. While this was a landmark achievement, the path to making multicore OCaml stable, performant, and user-friendly has required significant collaboration and continued work. In 2024, Tarides remained focused on meeting the needs of the broader community and commercial users.

  OCaml 5.3 (released last week) was an important milestone in this journey. With companies such as Routine, Hyper, and Asemio adopting OCaml 5.x, and advanced experimentation ongoing at Jane Street, Tezos, Semgrep, and others, OCaml 5.3 is increasingly seen as the first “stable” release of the multicore series. While some performance issues remain in specific parts of the runtime, we are working closely with the community to address them in OCaml 5.4. Tarides contributed extensively to the 5.2 and 5.3 releases by directly contributing to nearly two-thirds of the merged pull requests. Since Multicore OCaml was incorporated upstream in 2023, we have been continuously involved in the compiler and language evolution in collaboration with Inria and the broader OCaml ecosystem.

  Developing correct concurrent and parallel software is inherently challenging, and this applies as much to the runtime as to applications built on it. In 2024, we focused on advanced testing tools to help identify and address subtle issues in OCaml’s runtime and libraries. The property-based test suite reached maturity this year, uncovering over 40 critical issues, with 28 resolved by Tarides engineers. Trusted to detect subtle bugs, such as issues with orphaned ephemerons, the suite has become an integral part of OCaml’s development workflow. Importantly, it is accessible to contributors without deep expertise in multicore programming, ensuring any changes in the compiler or the runtime do not introduce subtle concurrency bugs.

  

  Another critical effort was extending ThreadSanitizer (TSAN) support to most Tier 1 platforms and applying it extensively to find and fix data races in the runtime. This work has improved the safety and reliability of OCaml’s multicore features and is now part of the standard testing process, further ensuring the robustness of the runtime.

  Beyond testing, we also worked to enhance library support for multicore programming. The release of the Saturn library introduced lock-free data structures tailored for OCaml 5.x. To validate these structures, we developed DSCheck, a static analyser for verifying lock-free algorithms. These tools, along with Saturn itself, provide developers with reliable building blocks for scalable multicore applications.

  Another promising development in 2024 was the introduction of the Picos framework. Picos aims to provide a low-level foundation for concurrency, simplifying interoperability between libraries like Eio, Moonpool, Miou, Riot, Affect, etc. Picos offers a simple, unopinionated, and safe abstraction layer for concurrency. We believe it can potentially standardise concurrency patterns in OCaml, but we are not there yet. Discussions are underway to integrate parts of Picos into higher-level libraries and, eventually, the standard library. We still have a long way to go, and getting feedback from people who actively tried it in production settings would be very helpful!

• Web
  

  Web development remains one of the most visible and impactful domains for programming languages; JavaScript, HTML, and CSS are the most popular technologies in 2024. For OCaml to grow, it must integrate well with this ecosystem. Fortunately, the OCaml community has already built a solid foundation for web development!

  On the frontend side, in 2024, Tarides focused on strengthening key tools like js_of_ocaml by expanding its support for WebAssembly (Wasm). js_of_ocaml (JSOO) has long been the backbone of OCaml’s web ecosystem, enabling developers to compile OCaml bytecode into JavaScript. This year, we merged Wasm support back into JSOO, unifying the toolchain and simplifying adoption for developers. The performance gain of Wasm has been very impressive so far: CPU-intensive applications in commercial settings have seen 2x to 8x speedups using Wasm compared to traditional JSOO. We also worked on better support for effect handlers in js_of_ocaml to ensure applications built with OCaml 5 can run as fast in the browser as they used to with OCaml 4.

  On the backend side, Tarides maintained and contributed to Dream, a lightweight and flexible web framework. Dream powers projects like our own website and the MirageOS website, where we maintain a fork to make Dream and MirageOS work well together. Additionally, in 2024, we enhanced cohttp, adding proxy support to address modern HTTP requirements.

  While Tarides focused on JSOO, wasm_of_ocaml, Dream, and Cohttp, the broader community made significant strides elsewhere. Tools like Melange offer an alternative for compiling OCaml to JavaScript, and frameworks like Ocsigen, which integrates backend and frontend programming, continue to push the boundaries of what’s possible with OCaml on the web. Notably, Tarides will build on this momentum in 2025 through a grant to improve direct-style programming for Ocsigen.

• Windows
  

  Windows is the most widely used operating system, making first-class support for it critical to OCaml’s growth. In 2024, 31% of visitors to ocaml.org accessed the site from Windows, yet the platform’s support historically lagged behind Linux and macOS. This gap created barriers for both newcomers and commercial users. We saw these challenges firsthand, with Outreachy interns struggling to get started due to tooling issues, and commercial users reporting difficulties with workflow reliability and compilation speed.

  To address these pain points, Tarides, in collaboration with the OCaml community, launched the Windows Working Group. A key milestone that our team contributed to was the release this year of opam 2.2, three years after its predecessor. This release made the upstream opam-repository fully compatible with Windows for the first time, removing the need for a separate repository and providing Windows developers access to the same ecosystem as Linux and macOS users. The impact has been clear: feedback on the updated installation workflow has been overwhelmingly positive, with developers reporting that it "just works." The install page for Windows is now significantly shorter and simpler!

  In the OCaml 5.3 release, Tarides restored the MSVC Windows port, ensuring native compatibility and improving performance for Windows users. To further support the ecosystem, Tarides added Windows machines to the opam infrastructure, enabling automated testing for Windows compatibility on every new package submitted to opam. This has already started to improve package support, with ongoing fixes from Tarides and the community. The results are publicly visible at windows.check.ci.dev, which we run on our infrastructure, providing transparency and a way to track progress on the status of our ecosystem. While package support is not yet on par with other platforms, we believe that the foundations laid in 2024—simplified installation, improved tooling, and continuous package testing—represent a significant step forward.

Community Engagement and Outreach

What’s Next?