Add "Are we X yet?" pages

[tmattio]

Inspired by Rust's arewewebyet, I thought it useful to have similar pages for OCaml for some parts of the ecosystem.

The goal of these pages is three-fold:

• For newcomers, it offers an overview of the usability of OCaml for certain applications.
• For OCaml users, it can help the discovery of libraries and frameworks to perform certain tasks
• For community members, it can serve as a roadmap to focus our efforts on addressing specific pain points to make OCaml competitive with other languages for specific use cases

TODO

The PR isn't ready to be merged yet.

• Needs a description of the state of each category
• The UI is a bit rough and could use some improvements
• When complete, I'd like to get feedback from people who are working on improving OCaml web ecosystem and the community.

[tmattio]

@bluddy this is similar to OCamlverse in many ways - are you interested in contributing? In terms, I'm thinking we could have pages like these for GUI, Machine Learning, Gaming, etc.

[tmattio]

Also, cc @aantron and @anmonteiro as you probably know the state of the OCaml web ecosystem much better than I do.

I'll try to write a description for each category with my understanding of the state of things, but in case you see value in having this page on ocaml.org and have some spare time to help, don't hesitate to share some insights or even rough bullet points that could help me understand where we're at and what's missing.

[dinosaure]

I added few things into your list

[tmattio]

Thanks @dinosaure, I've pushed your suggestions. Do you maybe want to share a few thoughts on the status of the different categories? I still need to write a description for each and having your input would be very helpful

[dinosaure]

I wrote a little description which involves JaneStreet and I'm not sure that they want to communicate on such field:

Industry and research have done a lot of work on email, where JaneStreet currently uses an OCaml implementation to manage email (https://signalsandthreads.com/building-a-functional-email-server/) and Cambridge University has funded further work on email analysis (https://www.youtube.com/watch?v=kQkRsNEo25k). As a result of this work, a number of projects exist which, among other things, allow emails to be sent and generated according to standards. Tools have been developed to verify and/or sign emails using mechanisms such as DKIM.

So we should probably ask them if they are fine with this little description. Also, you probably should add dkim and uspf.

[dinosaure]

Also, if you can remove facteur, nobody really use it and I will probably archive it soon.

[tmattio]

Thanks for the suggestions and the description! Would you be able to give some insights on what's missing to get the ideal state for email support in OCaml? Could be gaps in supported protocols, missing libraries, or robustness/maturity. From a developer perspective, what's the story like at the moment if they want to send emails from their web applications?

[c-cube]

Should this also list ocurl? Curl supports SMTP(S): https://everything.curl.dev/usingcurl/smtp (edit: to be fair, I don't even know if ocurl exposes that)

[dinosaure]

Would you be able to give some insights on what's missing to get the ideal state for email support in OCaml?

Currently, when it comes to sending emails, we can consider that all the tools are available to a developer. What remains experimental is the implementation of an SMTP service. We can nevertheless extend the existing system with new authentication mechanisms but, as far as I know, those currently available are sufficient.

Could be gaps in supported protocols, missing libraries, or robustness/maturity.

Robustness & maturity are there. JaneStreet has been using its service for a long time and it's been 3-4 years since I've needed to make a major update to the email sending function - even though this part seems to be used by several web frameworks (like dream or sihl).

From a developer perspective, what's the story like at the moment if they want to send emails from their web applications?

I think, still for sending emails, that the main thing is there (generation, protocols, authentication mechanism, verification and signature).

[dbuenzli]

From a developer perspective, what's the story like at the moment if they want to send emails from their web applications?

It depends.

If you are just sending emails to a reasonably sized group of users or administrators then you can just shell out to sendmail like basically any php application does (which on debian can be a proxy for something much simpler like msmtp if you install msmtp-mta that you connect to the mail server of your email provider). So it can be as simple as that (modulo the escaping :-).

If you need massive mailing then you likely better off with a mailing service like mailgun and then it's simply REST interaction with a webservice. You don't even need to bother with all the standards. The twist here, like with all webservices, is that if you use a popular language the REST interface is likely already implemented for you as a library so it's a bit more work. But are we ready ? Definitively.

[yawaramin]

It should probably be mentioned here that templating is not the only option for generating HTML in OCaml and that libraries like Tyxml also exist to embed an HTML DSL directly into the language, which may be preferable for several reasons.

[dbuenzli]

It should probably be mentioned here that templating is not the only option for generating HTML in OCaml and that libraries like Tyxml also exist to embed an HTML DSL directly into the language, which may be preferable for several reasons.

That's the problem you get with this kind of page, it makes you think you need things you may well never end up using and misses things you may end up doing differently. If you ask me, "we" have been web for an extremely long time it just depends on what you need regardless of what other people try to make you think you absolutely need because of groupthink or whatever marketing and hype they have been enslaved by.

There's always a lot of enthusiasm when this kind of page gets created and then it slowly rots away (especially because people who really work with the language couldn't care less). That's not very good from a marketing viewpoint since it won't give an accurate view of the eco-system.

These pages are already starting to feel like a very broken index of the packages published on opam. I think it would be much better to invest time in taking time to formalize and maybe gently police opam tags a bit more – have a guide page for package publishers on which tags to use for which kind of service and perhaps opam-repository maintainer having an eye for them when packages are submitted.

You can then have "are we X yet" page mentioning and linking on the tags so that people can dynamically check for themselves the options they have at hand for that task.

[sabine]

formalize and maybe gently police opam tags a bit more – have a guide page for package publishers on which tags to use for which kind of service and perhaps opam-repository maintainer having an eye for them when packages are submitted.

I agree: we can (and should) use the categories that emerge here as basis for a set of opam tags "blessed" by the UI. With "blessed" I mean that it will be possible to browse packages by the blessed category tags and that search filters on the package search page prominently offer them.

So I think the major outcome here should be to establish a good taxonomy. 🙂

Daniel, even if these pages rot away in 2 years time (which is not certain by any means!)... Not everything we build has to be for eternity. It has to serve a purpose now - and I think it does because
(1) it helps people see that there's so much going on in the OCaml community and ecosystem these days,
(2) it brings us together to look at how to make the ecosystem better, and
(3) it makes us build out a category tree for the opam packages to the point that we can rally to make one big effort of going over all the existing packages and assigning them to the proper categories.

When the search UI and package browsing UI for this blessed set of categories is live, motivation to go over all opam files will be at a high point. While at the moment, there just isn't a lot of momentum for this effort of tagging opam packages in a consistent fashion.

I know you don't really care so much about (1) and (2), but let's use the momentum to do (3).

When this effort here has settled, we take the categories that emerged and we look up the best existing matching tags for those. We build out the UI that effectively blesses these tags so it becomes very very obvious how this benefits the community and then it's time to rally people to help out with tagging the opam packages.

[dbuenzli]

I think you are a bit overthinking all that. There's no need to bless anything nor any need to establish a taxonomy upfront. Tags will evolve anyways over time as technologies and hype cycles come and go.

So you don't want a system that hardcodes anything, it should be easy to add any tag and get a widget for the tag – how many packages have the tag (if any), how many stable packages have the tag (self-assessed by the package owner via a stable or unstable tag), links to the lists of packages and maybe if that's your thing a fancy indicator based on the stats to indicate if we are blabla yet for the tech corresponding to the tag.

Just let these things organize themselves: watch what people are already using, filter and maybe clarify or improve them (e.g. unifying diverging terminology). As soon as people see there's a page where their stuff automatically advertises itself if they use the right tags, you absolutely won't have to rally people to help with tagging the packages, package owners will naturally use them (and at moment the community is sufficiently small to leave out the spam problem out of the equation).

[chshersh]

I would love to see a separate category (or two) on CLI and TUI ❤️

For CLI, I can think of:

• cmdliner
• clap
• ANSITerminal

And for TUI:

• notty

[sabine]

I'm merging this now.

If you (the reader) feel you want to contribute, it's very welcome to open a PR to add more stable packages or write something to entice people to add to the ecosystem, or add more pages for other topics you care about.