If you are familiar with Julia language, you might know that part of their success is the ability to effortlessly call functions from other languages, commonly used in scientific computations - Python, R, Java. To achieve that, they made an officially supported wrappers:
Note, they have a special organizations for that - JuliaPy and JuliaInterop. I think, unifying such existing interfaces, like pyml and ocaml-rs under a similar OCaml organization would help the integration, will attract more attention, and would allow to show that it’s relatively easy to interop with other languages.
I agree with your sentiment of encouraging OCaml usage across the board. However, “blessing” certain libraries and putting into the OCaml github org means:
There is an expectation from the community that these libraries will be maintained in the long run. If this expectation is not met going forward, the image of OCaml as a whole suffers a bit because then these libraries will be in the OCaml organisation and OCaml may come across as “stagnant” or “unmaintained”
The expectation is that these libraries are already somewhat “standard” for their problem space. For rust inter-op I believe there are some other libraries – so we will need to have a debate for each library why that library was chosen to be included in the OCaml github organization and something else was not
There is an expectation that the usage of these libraries is above average by OCaml standards and the library has been “battle tested” in multiple projects. This is subject to debate because different people have different parameters and thresholds
In general I see a lot of posts on this forum for “official” package managers, “official” frameworks, “official” interop. There are two different approaches – a diffuse community approach and a more top down “corporate approach” in which there are “official” solutions.
It is a continuum, of course, in each language ecosystem. DotNet is more corporate style while Haskell/OCaml is more diffuse. DotNet has a lot of blessed Microsoft owned/controlled “official” solutions for web development etc. while Haskell/OCaml try to keep “official” packages to a minimum.
I personally would like there to be as little blessing on what is “official” and what is not and let the “market” decide through sheer excellence on which solution wins. There are rare cases where we want to provide some standards and blessings – dune, opam, ocaml-lsp according to me are important enough to be on that list.
In general, “blessing” stuff occupies a lot of debate and time that could be better spent on just programming stuff. When something gets really big and important then, yes, we should consider including it in the “cannon”.
TL; DR I’m not very big on this idea but I can see why others might have a valid and opposite viewpoint. This is subject to debate and I am just giving you my opinion…
It’s often not obvious to a programmer what the “market” currently thinks is the best solution. In the long run, do we want users to try out all the options in order to discover the best one? Blessing a library as official has the advantage of making implicit knowledge about what works best explicit and discoverable, improving usability of the ecosystem.
That is correct. But the flip side of it is that by blessing certain solutions as “official” it stagnates the ecosystem. People (often misleadingly) think the problem is solved or implemented “best” in that official approach. As an example, Microsoft produces “blessed” or “official” solutions – but some (not all) of them are highly bloated and may not be best of breed. It discourages people from building solutions in the same area and builds a high barrier of entry to that space.
I feel that programmers do need to try different approaches. See other (imperfect) parameters of quality like github stars, variety and size of contributions in repository, number of dependent projects, issues tracker, discussions etc. All this will give you a good idea of a quality of a project. Why always need to bless something as “official” ?
I am in favor of “official” things for extremely core things like build, package management and editor integration as they are important enough to deserve some standardization but not other areas so much.
We are indeed having a debate and it is a good thing. But then when we get to the next stage of blessing certain libraries and omitting others it is likely to take a lot of time and energy with uncertain gain achieved. If you’re in favor of a particular approach then blogging about it and advocating for it is much more egalitarian. For instance, @rgrinberg 's blog post Abandoning Async was quite influential for me. Lwt was never “official” (and I liked that) but it has really become the more popular approach in the OCaml community. So rather than want to anoint some project or another I would suggest we simply advocate for it. That can be quite effective.