I agree with the focus on teaching resources.
I also think there is some low hanging fruit in pursuing wider adoption by computer science research labs as well as research labs in other sciences. There are already success stories and there isn’t the usual commercial inertia against adopting anything outside of the mainstream. Researchers are under more pressure to squeeze out productivity from small budgets, so ocaml could benefit them.
In this process, you probably did an evaluation of the current state of the ecosystem. Can you make a public page on GitHub or the foundation website, and update your view of ecosystem strengths and gaps periodically? I think architects debating ocaml would find such content very helpful, if they can find it from ocaml.org
Unfortunately we don’t currently have something as structured as you are suggesting (we probably should!). We’ve been mostly looking at specific pieces so far (as in: “well obviously Lwt is important, is there something we should do there?”.)
@rizo, who maintains the Awesome OCaml resouce list, started an effort similar to what you describe a few years ago, under the name State of the OCaml Ecosystem. “Awesome” is a not-so-curated list of things out there (in a sense it’s similar to Maxence Guesdon’s now-defunct “OCaml Hump”), while “State” tried to do a bit more of a critical assessment of the maturity of the OCaml ecosystem for important application domains. Unfortunately “State” is not getting as many contributions as “Awesome”, because it’s harder and, understandbly, less motivating.
(Recently @K_N wondered, on the Foundation’s behalf, what are the typical application domains that newcomers would expect our ecosystem to provide, and are currently missing. One way to get data on this is to look at what some other languages (Python, Go) which use a batteries-included approach are providing. If some people around here are interested in helping identify those weak points, we can always use help! The Executive Board, which is doing the heavy work for the Foundation, is staffed by volunteers contributing part-time.)
I will contribute to state of ecosystem, thanks for pointing it out. Should post a call for updates to this forum, every four months.
Regarding the “State of OCaml Ecosystem” it is quite related to the What libraries are missing? discussion here and the “Help Needed” page in OCamlverse.
Since “state of the ecosystem” has been initiated in the past, the main piece missing for me is to see github table of companies and organizations listing what libraries they use, so that outsiders to ocaml can quickly understand what libraries they might end up using when shopping for languages. the lowest friction way that I can think of collecting this information is to have each github org create a small single file repo called “dune-stack-share” and have them fill in the dune file with a union of the dependencies their projects use.
While I like the idea, I don’t think that a simple dune file would be interesting. I have currently 242 packages installed at work, many of them being used directly. Simply listing that without providing any explanation is noisy and hard to navigate.
I am trying to set a low barrier, so that people reluctant to share or who don’t want to produce a separate text file might still participate. Could be multiple dune files like “base”, “library”, “service”, “cli”, “client”
Will mull over how to group deps to provide more useful information
If we come up with an idea that will be useful for sharing ocaml library stacks, we can use a custom Sourcegraph instance that indexes github, gitlab and other repos, to make the distributed dataset searchable.
Looks like creating a thread on this discourse to share stacks every six months or year will work well. It’s getting great responses currently. So, using github to share is not necessary