I understand the approach they’re taking but it’s funny to praise this approach while also praising how scalable the tools are. The hand-curated opam approach will have a tough time scaling to even a moderately-sized project that needs to control its dependency graph. Right now the best advice on offer is to vendor the entire dependency subtree into the project directly if you need to customize anything.
Well, let me just point out that this isn’t actually as straightforward as it looks. Sure, I’m perfectly happy that the unwashed use dune. Great, great. But when I was writing my camlp5-based work-alikes for all the standard PPX rewriters, I found that it was well-nigh impossible to figure out from the documentation, how to invoke them directly. Sure, you could do it thru dune, but I wanted and needed to do it thru Makefiles. I had to reverse-engineer how to do it by inspecting the (ridiculously verbose) build log.
If I could ask one, only one thing of dune, it would be to map their libraries and other large-scale build-artifacts to findlib packages, so that those of us who don’t use dune could interact with dune-based builds. Instead of having to rip out dune and redo everything.
When starting to use OCaml I found https://ocamlverse.github.io/ really, really helpful. For example, like others have said I was distracted by having to choose Base or Containers or pure Stdlib, but Ocamlverse gave me a good overview and guidance on that. I’ve found the same on other things like web servers and database libraries. And the information was pretty up to date.
So I think it’s extremely worthwhile to maintain Ocamlverse and it seems like it should be more prominent. I can’t find a link to it from ocaml.org. Is there some reason it is separate, or it just happened that way and there hasn’t been time to integrate it?
The other complaint that resonated with me is the lack of library doc. It’s true the code is very readable, but I think everyone (beginners or not) would benefit greatly from good library doc, including at least a minimal example, for each function. Some Ocaml libraries are good in this respect but a lot are not. I suspect this is a cultural thing – once it becomes acceptable to leave out the doc, people will do it. The only way to change that is to make it unacceptable by example and peer pressure. Is that worth it?
7 Likes
I’ve said this before but I really think we can learn a lot from Go’s tooling and attention to supply chain security. I wouldn’t even mind a build system that forced me to declare my library dependencies at the top of each OCaml source code file.
I wouldn’t mind more explicitness either. Even having to declare, in one
file per library, the list of modules in a OCaml file, and having to
import them? That’d be quite neat and clean. Currently you just find
modules that are magically in the namespace 
2 Likes
This “vendorizing” is precisely what got those Rust modules in trouble. The Rust approach is to “automatically vendorize” when deps can’t be met without it. So when package B exports types from package A, and package C needs a different version of package A directly, you can end up with types from both versions of A visible, and no way to prevent it.
I’m 100% OK with a package-writer deciding to vendorize. I am adamantly against a package-manager that automatically does so without the package-writer’s knowledge.
2 Likes
Yeah, and in fact many beginners don’t like how magical the implicit imports are, they prefer explicit imports! It would even solve 90% of the namespacing problem. E.g. imagine:
(* test.ml *)
#depend "decimal";;
let s = Decimal.of_stringI believe something like this will be possible with Bazel modules, which I hope to support in OBazl 3. The tricky bit is making it work with legacy libraries. I haven’t figured out how to do that yet.
2 Likes
I’m curious about this. A lot of OCaml beginner struggles are made easier with support from your organization, but here you are saying you’re forced to use it? Are you the first person in your org assigned to carve out a path here?
4 Likes
I came across the discussion and I wanted to share my newcomer perspective. I’ve started learning OCaml only a couple of months ago, but I do have experience with various FP languages (e.g. Clojure, Erlang, Elixir, Haskell, Scala).
Yeah, the rant was poorly written and rants generally serve little purpose, other than venting out. While you can’t please everyone I do think that some of the points about the experience of beginners make sense. I’ve started to play with OCaml recently after seeing some people I know from the Clojure community endorse/praise it here and there (e.g. @cemerick, who has always been one of Clojure heroes). My initial impression of the language is quite positive, but like many others I was somewhat put off by RWO leaning heavily on the Jane Street libs. I understand that some of the authors work at Jane Street, so I totally get their perspective, though - after all that’s how they do OCaml in the real world.
I also went over much of the Cornell course, which is good, but it’s clearly geared towards students (who does formal verification on the job? ). There’s clearly space for more entry-level books/resources on OCaml. If that wasn’t the case we probably wouldn’t be spending some much discussing the choices made by one particular book.
Syntactic preferences aside (like everyone I can bikeshed all day every day on trivialities), my only real gripe with OCaml so far is the small scope of the standard library - e.g. dealing with unicode strings and regular expressions in our day and age should be easy right? These days the expectation of most people is that a language comes with batteries included and plenty of great languages have “failed” because of this (e.g. Common Lisp, Scheme, etc). People are lazy and don’t want to reinvent the wheel all the time.
The OCaml tooling is an area where many people complain about, but I found it okay overall. Yeah, dune and opam don’t have the best docs, but they are relatively similar to what you’d find in other langs. Merlin/OCamlLSP provide adequate support for most editors. I even quickly hacked a few small patches for utop.el, flycheck-ocaml and tuareg-mode, as Emacs is my programming fortress.
Still, I was quite confused for a while what the hell is esy, jbuilder, etc. The relationship between OCaml and ReasonML definitely adds some complexity to the ecosystem. The more you read and practice the more you know and the pieces of the puzzles slowly get into place. Most people probably are not willing to go that far.
Third-party libs were also a mixed bag for me as I’d often notice libraries with little document or concerning little dev activity (e.g. the popular Dream framework).
I’ve been in plenty of small/fringe dev communities to not be super bothered by this, but I guess that’d be much more concerning to people who have spent their time mostly in the “mainstream”. Half my friends were telling me that learning OCaml in 2022 is a complete waste of time, as I already know to a different extent half a dozen FP languages and Haskell in particular is quite similar. Still, I don’t regret the time I invested in OCaml so far and hope to get even further with it. There’s a certain air of simplicity and pragmatism around it that I really like that reminds me from time to time of my beloved Clojure. I don’t like dogmatic languages, I like languages that help me solve a wide spectrum of problems
21 Likes
I agree, it should be easy. However, I think that the way this is supposed to be made easy in OCaml is to have an easy way to depend on something, and I think the OCaml story on that is quite good. Batteries not included, but the battery store is really convenient if you want. It still could handle improvements, but the choice of not putting to much stuff in the stdlib is reasonable in my opinion.
3 Likes
There are actually two parts to this story. The batteries should be easy to get, but you also need to what which battery to get. For example, for Unicode support you need to decide between Camomile and uutf, depending on your needs. You need to be aware of those libraries, what they do, and why you’d want to use one over the other.
Practically speaking, this means a place where you can easily access and digest this information. The obvious place for this is the OCaml website, and I’ve noticed that people have asked why ecosystem information available on the OCamlverse and ‘Awesome OCaml’ sites has not been made available on the main OCaml website as well.
Instead, notice that the second main header above the fold on the Learn OCaml page is ‘Papers’, pointing to academic papers. The link to the OCaml Platform, arguably the key page for users to understand what tools they need to use OCaml, is at the very bottom of the left panel, where you have to scroll quite a bit to get to.
The emphasis on ecosystem and industrial use is still not at the level it should be. In short, most of the ecosystem is effectively hidden behind a couple of layers of obfuscation.
4 Likes
On Unicode the problem may be underestimated.
As far as I can tell, Uutf is only a low level codec and the higher level functions that I would normally use are in Camomile. But Camomile has no published doc that I can find. It’s mli files are nested inside src folders and the doc in those files is very sparse. When looking for the mli files I saw the github readme says See CamomileLibrary.mli file. but that file doesn’t exist.
Also OCamlverse, and a tip page it links to, have warnings that Camomile uses an outdated unicode standard.
https://ocamlverse.github.io/content/unicode.html
https://erratique.ch/software/uucp/doc/unicode.html#tips
My impression is that Unicode support is being moved to the standard library but that is still only partially done – is that right?
I’m not sure I understand this comment. I don’t think there’s anything to decide between the two things you mention.
First the only thing that uutf provides, namely UTF codecs is nowaday available in Stdlib.Buffer and Stdlib.String. Except if you rely on the non-blocking stuff, which most people don’t, there’s no reason to use uutf anymore. People should move away from it and consider it deprecated.
Second if you need to access Unicode character data or perform normalisations, AFAIK Camomile has not updated its Unicode data for quite some time. Last time I looked it was Unicode 3.2 which was released in 2002, twenty years ago.
Since then thousands of characters, dozen of scripts and few new characters properties have been added. This makes Camomile entirely impractical to deal with the Unicode of today.
So I don’t think there’s any choice to be had here. You will be better served by uucp, uunf and uuseg (this one not provided by Camomille).
One thing that is missing from that small library set is collation, for which I have a design but never got the time to implement it so far (same for a proper Unicode text datastructure).
Note that the tips do not mention the new Stdlib decoders yet. This will be updated when Unicode 15.0.0 gets released – i.e. any time soon.
7 Likes
Thank you. It would be very helpful if the Ocamlverse page is updated to refer to these and a warning notice is added to the Camomile github readme and package description. When searching for “unicode” in opam, Camomile comes out on top.
One thing that is missing from that small library set is collation, for which I have a design but never got the time to implement it so far (same for a proper Unicode text datastructure).
That would be very useful. It was the first thing I looked for.
2 Likes
Exactly the kind of thing newcomers or casual users would absolutely never know unless they did a lot of research 
9 Likes
It is somehow mentioned in the Unicode tips – of course people have to find the tips in the first place, it’s nice to see they are linked from the ocamlverse but then I don’t know if newcomers read the ocamlverse.
I could be more vehement against using Camomile in the tips but I won’t unless the project is definitively deemed dead by its authors.
Yawar, you make an interesting point, which I hadn’t grasped until now.
-
In the past, I’ve felt that having a large standard library is a bad thing, b/c it discourages innovation: I saw that with Java, and hooboy was it a PITA.
-
BUT you are right, that having a standard set of tools that are the recommended choice for a large number of tasks that are beyond the remit of the standard library, is also useful. And a web-page with a list of such things isn’t really enough.
Maybe what’s needed, is a sort of single opam meta-package that wil pull in the entire recommended-toolset, and that some maintaners verify for compatibility and freshness. With a process for adding new tools/libs and removing outdated ones.
Idunno, just echoing what I heard from you. And gotta say, I agree.
8 Likes
It’s been discussed OCaml future development - #32 by yawaramin
3 Likes
Btw. in general there’s a good solution to this problem which is:
opam install camomile odig
odig doc camomile
2 Likes
Or, nowadays, Documentation · camomile 1.0.2 · OCaml Packages