OCaml Weekly News

The https://watch.ocaml.org video site is now promoted to a production quality ocaml.org site, as discussed at the start of the year (doesn’t that seem like a long time ago?) For those interested, this means that the software stack is now part of the deploy.ci.ocaml.org pipeline (see ocaml/infrastructure#23 and the infra@ocaml blogpost.)

Now that this is done, it’s a good time to put a call out to any other interested OCaml meetups, workshops or conferences that also want to host OCaml related content. See the watch/about page for more information about how that works. If you do have a stream of videos (historical, or recent, both are good), then we can mirror it there or host it directly. As a reminder, anyone on a ActivityPub-compliant service (such as Mastodon) can follow channels hosted on the service and leave comments.

Thanks to @mtelvers @patricoferris @cuihtlauac @sabine for loads of ocaml.org updates as well to make this possible! That was lots of work, but https://ocaml.org/community now links to the site and each workshop page should be up-to-date back to 2012.

I am curious about something. There are many companies using OCaml, some of them very successful and famous. Others more obscure. They all obviously have one thing in common–they need to employ developers to maintain their OCaml codebase.

I can tell you a little bit from my experience at LexiFi. (This is strictly my personal opinion, and in no way it should be understood as an official statement of any kind.)

My question is, how have they been finding developers for a niche language?

Most programmers hired at LexiFi already know some (or a lot) of OCaml. Often, they have a two-year Master program in CS (called “M2” in France) or an Engineering degree under their belt, where they learn OCaml, but this is not a requirement. Typically, we advertise the position in the usual places, and candidates send in their applications. A few remarks:

• For the last couple of years, hiring was noticeably tight. My feeling is that this was in large part due to certain blockchain-backed companies in France siphoning a disproportionally large number of OCaml programmers off the market. I say “was” because since the recent bitcoin downturn, we have seen a noticeable increase in the number of good candidates, and hiring has loosened up again.
• We are a small team, so don’t need to hire more than one or two people at a time. I am not sure what the situation would look like if we wished to hire tens of programmers at one time.

Also, our experience may be a bit particular because we are based in France, where (I guess) the supply of OCaml programmers is higher than average.

I’ve heard that Jane Street has developed a 2-week crash course and many internal tools, idioms, and best practices.

We haven’t had to onboard many programmers who did not know OCaml before, so we don’t have a dedicated training program. We try to document workflows, but the truth is that a lot of the institutional knowledge about the code is not written down anywhere, and new hires learn it by talking to people around them. This probably works as long as your team is relatively small, but will not scale beyond a certain point, which is why more structured onboarding processes are needed in larger companies.

As another data point, our “quant” team, which consists entirely of quantitative programmers which typically arrive to LexiFi with little or no OCaml experience, developed a “crash course in OCaml”. New arrivals typically go through it to get up to speed so that they can start contributing to the codebase. On the other hand, quant programmers have very specific skills and don’t typically “roam” over the whole codebase, so it is easier to tune their training for the kind of tasks they will be doing.

I’ve also heard of some companies which had to move away from OCaml (or Reason/ReScript) codebases due to the usually cited reason–lack of support.

This would be unthinkable at LexiFi; we use OCaml for everything, are are fully invested in it. But I can see how this could be a problem in a company where OCaml knowledge is the reserve of a small number of people.

How are companies in general convincing good developers to join, learn OCaml, stay on in the job instead of flying to greener pastures, and building up engineering continuity with training/documentation so that their whole OCaml codebase is not at the mercy of one or two engineers deciding to stay or leave?

I can only hypothesize about my colleagues, but my personal feeling is that I’m quite happy to be able to make a living programming in OCaml, so this acts as an incentive to remain, rather than to leave. More generally, for whatever reason, the turnover at LexiFi is extremely low, so we haven’t had to deal with issues stemming from high churn rate. I think it would definitively be a problem if this were to happen.

The recently released Dune 3.7.0 includes native support for watch mode on Windows. This feature was implemented by a student, Uma Kothuri of the US, who interned at LexiFi last year for this project.

To mark the upstreaming of the feature, we wrote a brief technical note about it, which you can find at https://www.lexifi.com/blog/ocaml/dune-watch-mode-windows/. Don’t hesitate to take a look if you would like to get an overview of how the feature is implemented.

I gave an introduction to Eio talk at Tarides last week, and afterwards we thought it might be worth sharing it more widely. I covered more about how Eio compares with Lwt than the README does, and the video includes a short example at the start of me converting some existing code to use effects:

https://watch.ocaml.org/w/02a7accc-2a2c-44d5-889e-d75e1489946e

Dear (aspiring) MirageOS hacker,

it is my please to announce that there will be the 12th MirageOS retreat in early October in Marrakech, Morocco. Please find more details, including writeups of earlier retreats at https://retreat.mirage.io.

Everyone is welcome, be kind to each other. There won’t be much Internet connectivity – but there’s plenty of sun, discussions, impromptu talks, and a local network mainly constructed by MirageOS unikernels.

If you have questions, don’t hesitate to ask them here in this thread, or contact me directly via eMail “my first name” at mehnert DOT org

Hi all!

Liquidsoap 2.1.4 is out: https://github.com/savonet/liquidsoap/releases/tag/v2.1.4 ! 🎉

Liquidsoap Rolling Release 2.2.x is now available: https://github.com/savonet/liquidsoap/releases/tag/rolling-release-v2.2.x ! 🎉

The 2.1.4 release contains important bug fixes, including a last-minute memory issue with http requests and queries that was introduced in 2.1.3. All users are encouraged to migrate to it but make sure to use a staging environment before pushing to production just in case! Full changelog is here

Next, we would like to shift our focus to the 2.2.x release cycle. We are done with the changes there and will now focus on fixing issues there. We do encourage new projects to start with it and users to report issues. We will prioritize these issues over other ones.

The 2.2.x release contains some exciting changes, in particular a switch to dune as the build system and a new support for multitrack decoder/demuxing/muxing/encoding. You can read more about it here. Full changelog is here.

Dear users (of the opam-repository in particular, but also of the container images and various other pieces of infrastructure that we publish from ocaml.org),

After that mouthful of an intro, just a brief note to solicit opinions over at ocaml/infrastructure#20 on what would be most useful to users of the opam-repo on what sort of change tracking would be most useful for you to find out what’s breaking (or has been fixed) as the live infrastructure evolves.

There’s a lot of improvements going in thanks to all the contributions to the various CIs, and your inputs on that issue, or this thread, would be welcome.

Hi, I’ve just released a VS Code extension to integrate PPX Expect and PPX Inline Test to VS Code. It also works in combination with Alcotest Test Explorer

Expect and Inline Tests GitHub: VS Code Expect and Inline Tests

It always adds/updates/deletes expect and inline tests when opening or saving an OCaml source file. By default, it also runs all inline tests of all inline test runners to discover tests on startup. If this takes too long or you don’t like that, you can disable that behavior in the settings. The Refresh Tests button in the upper right of the Test Explorer view also runs all expect and inline tests to fill the tree.

Hi, a new version - 0.2.0 - of the Expect and Inline PPX extension with minor cosmetic changes is ready for you.

Expect and Inline Tests GitHub: VS Code Expect and Inline Tests

I’ve also released a new version - 0.3.0 - of the Alcotest extension (with more substantial changes). See: https://discuss.ocaml.org/t/ann-vs-code-testing-extension-for-alcotest-and-inline-alcotest-ppx-0-1-0-initial-release/11514/6?u=release-candidate

Changelog:

I’m happy to announce ppx_minidebug:

• Which is a syntax extension to instrument type-annotated bindings and functions with logging.
• The extension supports 3 value conversion mechanisms: pp and show from deriving.show, and sexp from ppx_sexp_conv.
• The minidebug_runtime package provides 3 logging backends: Format based purely on formatters, Flushing that converts to strings first and flushes output after every entry, and PrintBox that pretty-prints as trees using the printbox package.
• I reference a VS Code extension that builds flame graphs for the Flushing logger out-of-the-box.

Hi, a new version of the Alcotest extension, 0.3.0, now retries running dune every 2.5s if another process holds the directory lock. There are also some additional, minor, changes.

I’ve also released a new version - 0.2.0 - of the Expect and Inline PPX extension. See: https://discuss.ocaml.org/t/ann-vs-code-expect-and-inline-tests-extension/11593/2?u=release-candidate

Changelog: