Yes, a lot of people seem to have this grouse against OCaml that dune, opam, utop, odoc etc. should be a single tool and the current situation is intolerably fragmented. It indeed has become a popular trope.
To be honest I kinda like it this way. I like picking and choosing my tools and a lack of totally monolithic “blessed” OCaml specific “mega-tool” allows innovation. The “unix philosophy” is to do one thing and do it well. I don’t think the philosophy yields the optimal system in every scenario but it works well in practice. Linux for instance has a plethora of tools coming from different creators and they are brought together by system integrators like Debian, Red Hat, etc. The important thing is if the whole system is reasonably consistent and works well. So as far as I’m concerned let there be many tools and let them work well together. At this point the dune+opam+ocaml-lsp-server+utop+odoc “suite” of tools are mature, featureful and reasonably well documented.
What about cargo you might add? Yes, cargo is cool and Rust was lucky to have had visionaries who have produced such a nice integrated tool. But OCaml has a secret weapon: gc . Rust can be quite tough to program in (I have done a good amount of Rust). The time I’ve probably saved using cargo has been expended many times over thinking about memory in Rust . I would recommend using Rust only when you really need the low-level performance. OCaml is definitely more “general purpose”. But I digress…
I think the solution to increase OCaml uptake is simple – make good software. A few more anchor OCaml projects that are ground breaking and innovative will attract more developers. Haskell is a difficult language to learn but yet seems more popular. Why? Haskell programmers have built some innovative software projects that are ground breaking. I see that there are definitely some cool OCaml project around. If some of more these projects hit the popular imagination, I feel OCaml will definitely attract more people. And they will be willing to deal with the non-integrated tooling story as long as the language will help them produce some cool software.
This is well and good but there is clearly a desire for an integrated tool in the OCaml world too, because two different projects are working on it: esy/pesy and drom.
The problem with the Unix philosophy is that it adds another layer of complexity to deal with when you’re new and just trying to get started with the language. From the perspective of an experienced OCamler it’s great because as you say you can pick and choose, but by the same token, newcomers suffer from the ‘tyranny of choice’.
The important thing is if the whole system is reasonably consistent and works well.
Right now we have two places to put project metadata: opam files and dune-project files. The latter mostly supports the fields supported by the former, with exceptions where we have to use a template file to inject the unsupported ones. It works but the whole thing is rather clunky. Pretty regularly people come here and ask about this kind of issue.
The time I’ve probably saved using cargo has been expended many times over thinking about memory in Rust
These are two separate issues, we are not asking to add the language complexity of Rust to OCaml, only the simplicity of its build tool, cargo.
I think the solution to increase OCaml uptake is simple – make good software.
Everyone wants to make good software, I wonder why they don’t just do it
Seriously though, I touched on this in another thread, but imho the biggest impact on OCaml adoption would be a dead-simple Windows install and dev experience. As much as everyone loves to ‘critique’ it, I think this is one thing (among several) that Node.js absolutely nailed. You run the installer and get the node and npm executables in your path, and everything just works even from a Windows command prompt.
It’s worth remembering that we’re chasing a moving target. While the OCaml experience has improved a lot in the last couple of years, other languages with no baggage have popped up, and old competitors have improved their experiences, too, and they were ahead to begin with. There’s no objective measure here – it’s all about the competitive advantage and experience relative to other languages vying for programmers.
I don’t think that I really buy the argument that Ocaml tooling is rubbish, at least for unix-like platforms. opam in my view is a work of art. To install ocaml on a unix-like platform you just need a C compiler, download the latest opam binary for your platform from Releases · ocaml/opam · GitHub , do opam switch create ..., and away you go. dune takes a bit of getting used to but it is a great deal easier to use than cmake or autotools and has the benefit in my view of being pretty well documented.
Sure, some of the windows tools for C/C++ and the CLR are pretty good, and Rust happened to start from the ground floor with cargo which gives it a good story to tell. But leaving aside ocaml on the windows platform (which appears to need further work) I think ocaml’s position on tooling, for a compiled language, is pretty good.
On a different topic, as an outsider I was also impressed when I first came across js_of_ocaml. For code which fits within the js_of_ocaml/node or js_of_ocaml/browser subset of ocaml, it makes programs highly portable.
It works very well and since I know OCaml it was easy to look at the code and figure out how to use it. But a person learning OCaml would be discouraged by the absence of clear documentation, the lack of small examples in the README, by the syntax used in some places (>>= in wscat.ml which one needs to look at to start using the library etc), and by the lack of clear signs that the library will be maintained. And this lack of “inviting” documentation is common in OCaml, where some quality projects seem to be made “by OCamlers for OCamlers”.
And just to be clear, I’m very grateful to the person who wrote this library and made it available, for me it’s perfect.
Compare with a popular websockets library for Python (random result):
This kind of approach, making every effort to sell the library and help the user become productive as fast as possible, is much more attractive to new users.
Having said all that, some projects like for example Dream, Owl, and many more have amazing documentation.
This is very much a function of the number of contributors to the library. The problem is that as a user, one doesn’t judge a library by the amount of work done per contributor, but rather by the result.
I have to disagree with this. I’ll take Dream as an example, due to personal experience, but this undoubtedly applies to other projects as well.
The initial extensive documentation was done when Dream had only one contributor. Of course, since then, the repo got a lot more very nice examples and other documentation from more contributors.
Conversely, aaugustin/websockets doesn’t have that many contributors — only 43, according to GitHub. I took a superficial look at the history of the docs/ directory, and the vast majority of the commits are from aaugustin.
The next claim might be inaccurate, but based on the above, I would suggest that quality of documentation or marketing is a function of the initial effort of the original authors, or a small number of initial or major later contributors. These initial contributors set the tone — that good documentation is valued, welcome, that more such documentation will be worked in, that the project cares about its users and contributors, etc.
Contributors with less time to create whole-project documentation are then naturally and reasonably more willing to work on parts of it. I claim that in OCaml, many (not all!) individual authors either do not have time to, or do not care to, set such a tone for their project. So if this is a problem, it can probably be considered a cultural problem, at least in this line of reasoning.
I agree and I’d also like to point out Daniel Bünzli’s software doc as an
example of quality libraries that have really good documentation even
though they have mostly only one author.
This guy nailed it, and IMO people is missing the point by asking him to provide concrete details. He gave a great overview of the overall problems of the ecosystem, it’s not meant to solve his particular experience.
I hesitated, because of the syntax variants (ppx!), standard lib confusion and dune configs scaring me. Avoided complexity here and never regreted, however.
Presumably, when there are more users, there are more people able to write and publish libraries, and a growing package ecosystem makes our favourite language more feasible in many different use cases
If by ‘going down the drain’ and ‘disgusted’ you mean ‘they became wildly popular and mainstream tech’, then sure Another way to look at it: the more mainstream OCaml is, the better the chances that enthusiasts like us get to write it one day in our day job.
I’ve been programming in OCaml and caml-light since 1991. I’m the sort of guy who thinks comments are for weaklings, and if I can’t figure out a piece of code I wrote 10yr ago, then that’s on me for being weak. Honestly, “sometimes the best documentation is the source code”. Etc.
But even I can see that the leaders of OCaml have every right to want OCaml to be more popular, and that it’d be a good thing for the world. I agree with Yawar, that a big obstacle is the lack of a seamless newbie experience on Windows. And I say this (again) as somebody who wouldn’t touch Windows with a ten-foot pole.
I’m glad you guys are trying to figure this out, even if it will never affect me.
. Rust can be quite tough to program in (I have done a good amount of Rust). The time I’ve probably saved using cargo has been expended many times over thinking about memory in Rust 
. I would recommend using Rust only when you really need the low-level performance. OCaml is definitely more “general purpose”. But I digress…
.
not sure what happened…
OCaml.