In other languages, I usually base my choice of libraries based on github stars and the most recent commit date. To ensure community and continued support.
I’ve been looking at ocaml libraries and they all seems to have low stars most <100 even popular ones are <1000.
How do you base your choice of a library? Am I thinking about this wrong should I opt to write stuff from scratch?
Appreciate any advice. I just don’t want to contribute/depend on something that will be discontinued because of little community support.
My process for choosing libraries is somewhat similar.
For a few common tasks, OCaml has a number of unofficially “standard” libraries that the community has settled upon (i.e think cmdliner for CLI, Caqti for low-level web requests etc.). In these cases, I usually dig the appropriate library by searching the forum for past questions.
In other cases, I typically choose libraries based on whether they have the features that I require — I check out the API for the library, does it support what I want? is it ergonomic? OCaml libraries aren’t too difficult to maintain, so in the worst-case, even if the library has bit-rotted, you can vendor a copy and maintain it locally.
Haskell has a similar problem of low signal-to-noise ratio as a niche FP language.
I can suggest reading the following blog post on the subject about evaluating a library in Haskell. If you throw away all the Haskell-specific parts (PVP, Hackage, Stackage, etc.), you get a pretty similar picture in OCaml.
If you search for packages on the ocaml.org site, it also shows you how many other packages depend on it. This is a reasonably objective measure of how viable a package is to use as a dependency – if many other people also do so, then it’s probably got some critical mass. For example, if you were to search for json, then you get:
It depends on your priorities. Is it security, ease of use or fashionablity.
if there is e.g. a @dbuenzli or @hannes lib, I take it and sleep well. Otherwise those without known issues but with
the least additional dependencies to the project,
the fewest lines of code
the fewest updates (including zero),
Good thing about small communities, you may know your usual suspects.
E.g. I choose jsonm over yojson for LOC and focused functionality and because others may have different priorities. I won’t interview the star-givers to check our objectives align.
I find that picking a library is easier in OCaml partially because of the smaller number of choices. For cases where there are a few different libraries for the same thing (such as JSON) they tend to be built around different design decisions, so figuring out which one works best for your use case isn’t hard.
But if the library in question is something I can easily write myself, then I don’t mind doing that either. I’d rather work with my own modules than have to learn how to use another library, if possible.
What does “vendor” mean, as a verb? I haven’t been able to find this usage in a dictionary, and this is the third time today (in three different threads on this forum) that I see it used as a verb.
Haha, yeah, I actually ran into this while writing a paper — as far as I’m aware, vendoring, in the context being used here, isn’t really something from the dictionary, but seems to be jargon that has naturally synthesised within programming communities.
Probably a succinct definition would be:
Vendoring in Software Engineering is the act of including 3rd party software directly in your product. The alternative is to let a dependency management tool install it.
(In this context, referring to creating your own copy of the outdated library and maintaining it yourself (either as a separate repo, or within the source-tree of your own project)).
