"OCaml -- first impressions"



I do use ;; quite often, mostly to limit the search scope for syntax errors and of course the REPL.


Going to state the obvious here: that is a serious and avoidable usability flaw.


you mean ;;? in my opinion, it’s actually useful in the toplevel: easy editing of multiline input. as long as ;; is not typed, you can just continue editing. within a module i would agree that it’s not so useful but i find it not serious.

my personal serious usability flaw is the amount of work needed to get pretty-printing of user defined types…


[@@deriving show] is pretty easy to add to your type declarations, IMHO…


i guess you’re right. but when i started i wanted to keep out anything that adds complexity, including syntax extensions or preprocessors. i think it’s odd that one has to use something that generates invisible code in order to get printing. maybe that’s a price to pay for abstraction and strong types?


Given some sort of ad hoc polymorphism (typeclasses, modular implicits, etc.) one can handle printing a bit nicer, and someday, OCaml will have such a thing. However, as thing stand in OCaml, using the deriving ppx is the easy choice.


Even then, though, I don’t know/think that we’ll get printers for things like variant and record types for significantly less cost than we have now. So there will continue to be a place for deriving-like functionality.



Indeed. The question perhaps is, should we bundle certain ppxs with dune by default?


The deriving extensions are included by default in the compiler in Haskell and Rust and are advertised as the recommended way to implement pretty-printing and similar trivial functionality.

We should do a better job at guaranteeing a smooth usage of ppx_deriving on the tooling level and promoting them in official docs.


Yes, more features “out of the box” (like printers, to_sexp and of_sexp) could be nice for the user experience.


Just finished my first 8 hours of OCaml, a year later since this original post, and I reached a lot of the same feelings. I’ll try not to re-hash all but the most important annoyances. Biggest things that jump out to me today:

  • There’s not a consistent tooling/building/project setup story to be told. A tutorial on ocaml.org pointed me to use Oasis. Most of the packages I’ve looked at are using jbuilder. There’s this out there called dune? Seems like what I should be using. Ok now, I’ve picked a build tool, how do I actually start a project? A tool like npm init could do wonders for dune.
  • In general, the tutorials on ocaml org seem pretty dated. I went through most of them and didn’t find Real World OCaml until later. Seems like this might be a great resource to point people to first.
  • Where do I find package documentation? Many packages I tried looking at didn’t publish their own docs, and OPAM doesn’t seem to host any. Rust’s https://docs.rs/ site is a great resource for learning Rust packages. Is there anyone in the community working on something similar based on odoc? If there is or isn’t, I’d love to get involved in making it happen.
  • How do I know which packages/libraries are actually good? In the JS world, we get this basically via socialization/social proof on Hacker News. For OCaml, I’m really just leaning on awesome-ocaml and which packages have the best Google SEO.
  • Where is the language headed? How do I know about hot topics and the future of the language? Major versions not being released for over 6+ years could be good or bad, but I can’t tell?

Obvious things that have already been mentioned:

  • Default toplevel vs utop. Also I think one of the first tutorials should show you how to load and interact with an OPAM package from the toplevel. As a newbie to the language, I love jumping in and just playing with popular libs in the ecosystem.
  • Shell integration with fish took some digging to get working
  • The landing page for the site is pretty dated. Also, manual.

In general, I think a very opinionated story of how to learn, how to create projects, and how to share them would do a lot to move the language and ecosystem forward. Of course, take this all with a grain of salt, I’ve been here for literally single-digit hours.

Excited to get my hands dirty with the language and start contributing to the community and building real software. The commitment to practicality in the language’s design is very appealing!


jbuilder was renamed to dune in version 1.0


Josh, thanks for posting! I think it’s great to have constant feedback especially from newcomers to the language so that we could be reminded on what’s missing.

Addressing some of your points:

I think we can all agree that Dune is the way to go here. As to how to start a project, if you would allow me to shamelessly plug, I made an article on starting an OCaml app project using Dune. I think a dune init command is in the works?

Agreed. I think that page was originally built to aggregate tutorial articles by the community that otherwise would be scattered through the web. Hence, there wasn’t really a notion of sequentiality, and keeping it up-to-date would need an effort. As you said, RWO (and even the OCaml manual) would be better as a guided starting point. Perhaps we could make a note on this in that page. (I actually got a small PR merged to reorganize that page some time ago, and if you have an idea on how to improve it further, it would be welcomed).

I agree that package’s popularity can be a good enough first step on determining whether it should be considered, and to that end you can go to https://opam.ocaml.org/packages/index-popularity.html and do a search on what you’re looking for. Of course, you would need to do due diligence after that to ensure that it’s really what you need (which is also the case in JS world).

This is interesting. AFAIK currently there are works on algebraic effects, multicore, modular implicits, centralized docs website, etc. A page that could aggregate this kind of info would be nice to have indeed. Perhaps on ocamlverse.github.io?


@joshdover thanks for sharing your insights. I think it is very valuable in pointing out what we have to improve.

Where do I find package documentation?

You can build the documentation locally, using tools like ocp-index or ocp-browser but I agree it is not overly elegant. I usually either use the documentation if provided or mli files if provided or just the source. I got used to this workflow in my Clojure days since hardly any library provided documentation at all.

In the JS world, we get this basically via socialization/social proof on Hacker News. For OCaml, I’m really just leaning on awesome-ocaml and which packages have the best Google SEO.

How does that work? In my experience in Node people have been just picking whatever library has a sort of fitting name and maybe lots of downloads in the NPM registry. I have never seen any social proof on Hacker News, except of course blog posts about the really big frameworks like React or Angular, but we also have posts on things like Lwt, albeit at a smaller scale of course.


That’s true. (sadly)


This is a great idea. Currently the compiler page lists some interesting branches, but having it in a ‘Future of OCaml’ page would make more sense, together with articles describing these things.


Dabbling with Rust, makes me wish OCaml had something like Cargo, it makes starting with the language really easy: getting dependencies, building, running tests… and I agree Rust doc is impressive… they’ve nailed it


opam isn’t a good enough package system for you? What does cargo do that it doesn’t and you need?


AFAIK, Cargo is more like opam + dune + dune_release/topkg (+ others?) under a nice CLI. @avsm talked about a comparable tool codenamed “bob” in his 2017 slides. I think many people would be interested to know whether any progress has been made on this front.


Cargo also includes some of the functionality provided by Findlib in the OCaml world and by pkg-config in the C/FreeDesktop.Org world. In my copious spare time, I’ve been designing a thing that would hopefully be a useful combination of the features of both of those tools, and which would be opinionated about OPAM being its preferred application package manager. Copious spare time. Copious.