If you are interested, I think I adress this here https://xvw.lol/en/articles/why-ocaml.html#ocaml-and-f

Thanks, this is a very nice article.

In the `show_content` example, using first class modules: `module H : ...`. The type need to be specified and since module composition is hard, it leads to very verbose solution

We try to invest equal time between the OCaml platform (on VSCode) and OCaml-eglot (for Emacs). In fact, I find the VSCode extension to be rich (and generally iso-features with Emacs mode).

However, I (as maintainer of OCaml-eglot) find Emacs easier to extend (the VSCode extension is surprisingly complex when you stray from the beaten path), which seemed perfect for incubating an experimental feature. Furthermore, as mentioned at the end of the article, the feature can also be invoked from a code action, which makes it de facto callable from VSCode once the various PRs have been merged :)

The LSP features, in my experience, work very well in VScode, no shade there. But debugging features like breakpoints still seem to be experimental? Whenever I ask others about it online they usually try to tell me that print debugging is superior anyways

For the first point, you are right. We start by a common (but very useful) feature. Since OCaml allows an infinite level of nesting (and different kind of structure item) it was still a bit of a challenge, mostly for finding the right UX.

For the second point we delay the aeration convention to the formatter (ocamlformat). It can be configure in a different way :)

Thanks for your feedback!

PRs are mentioned at the end of articles. It is possible to `pin` repositories locally on their different branches to experiment with them locally!

Nop, for the moment, we try to not "infer user usages"! But if you extract an expression with variable, there will be, obviously, not be repeated:

    let tau =
      let pi = 3.14 in 
      pi + pi

if we extract `pi + pi` it will lead (if you do not give any concrete name) to the following code:

    let fun_name1 pi = 
       pi + pi

    let tau = 
       let pi = 3.14 in 
       fun_name1 pi

- Extremely dated: we have almost one new release every six month and in recent releases, the language runtime has been changed and user-defined effects have been introduced.

- No HKTs "in your sense" but: ```ocaml module type S = sig type 'a t end `` `type 'a t` is an Higher Kinded type (but in the module Level). - No typeclasses, yes, for the moment but the first step of https://arxiv.org/pdf/1512.01895 is under review: https://github.com/ocaml/ocaml/pull/13275 - no call-site expansion ? https://ocaml.org/manual/5.0/attributes.html look at the attribute `inline`.

Sorry, I never used ReasonML so I don't see any advantage of using ReasonML except it had the time to die twice in 4 years :)

Usually we speaking only about sum and product (because article usually refers to ADT, so Algebraic Data type). A function is not really Data, so it is not included. But you can use the same tricks (ie: a -> b has arity b^a) to compute the number of potential inhabitant

There is a lot of work on Dune Package Management that will fix some legacy issues related to OPAM, https://dune.readthedocs.io/en/stable/tutorials/dune-package... !! Stay tuned!

Dune is not a dependency manager, it is a build tool. Opam is the dependency manager. By default, Dune doesn't fetch dependencies, opam does that. That said, Dune does use opam, yeah.

And the next milestone of Dune is to become an alternative package manager via Dune package Management, using a store in a "nixish" way.

I suppose it is still going to use opam internally, right?

No, it is doing its own package management implementation.

So dune is going to replace opam? Where can I read more about this if so?

Package description, but it use its own engine.