I find OCaml really enjoyable once I got going, but I do think the initial setup is a major barrier to larger adoption. I think a post on howistart.org might be useful, but it'd probably be polarizing since most functions have two major ways of doing it (Jane Street vs. not, Lwt vs. Async, etc.).
For a while, I grumbled that it had spoiled me for other languages, the "fun" looking stuff that everyone talks about online. But as with all... rustic... experiences, it's only fun for the weekend. I wouldn't want to spend my entire life chopping wood for fuel, either. Even after spending 3 years fully in JavaScript land, getting very comfortable with all of the tools, it never really got "good enough". Years of effort and my dev experience was still worse than a default VS install. So I went back and have been loving life again.
I talked about "confusion" because I suppose a newbie may quickly be confronted with this question, for intance if they want to follow "Real World OCaml" which is based on Jane Street libraries.
The tooling around OCaml has really improved a lot these last few years (opam, dune, core/async, merlin, ppx...). The downside is that it raises the bar for newcomers.
Docker because, presumably, he didn't want to dink with installing it locally.
Sorry, what is not straightforward in building with `dune`?
- How do I run tests? Oh, you can't really dune runtest on executables, only libraries. So how do I run tests on executables? Make a library with the core of the functionality and wrap it, I guess. Wasn't obvious.
- Tree-like heirarchy of dune files confused me since it wasn't really explained anywhere. I wanted my source files in a `src` directory; most of the examples assume your `dune` file is just hanging out with the source in the toplevel.
- Does `dune` handle dependencies (like I would declare them in a rebar.config, mix.exs, or a package.json)? Not really, it plays with opam, requiring one to read a bunch of docs for opam, and its files, and where they should go.
- The syntax of the dune files changed a bit from when I started the project (it was just moving from jbuilder -> dune). Less of an issue now, though I still question the use of s-expressions.
- Can I load an interactive shell with the definitions? There's a command in the documentation for it, but it didn't work quite right when I tried.
- If you look at other projects, you'll see they use opam files differently from one another.
- How do I add a dependency in my current switch (something like npm --save install <library>?) I tried `opam install --deps-only`, but it complained sometimes about the state of uncommitted files.
I understand why it's like this (trying to tie together a ton of use cases) and love developing in it after it's all said and done, but there are a lot of rakes to step on.
It's explained in project layout [1]. And it's not a tree like, it's basically flat, since it doesn't matter how deep in the file system your dune file is buried.
It's like `meson` in its concept.
> Does `dune` handle dependencies
It doesn't, and so neither do `meson`, `cmake` and most other build systems. As you may want to use various ways of installing dependencies: native packages, manual compilation, opam, esy.
> Can I load an interactive shell with the definitions?
Yes, you can run `dune utop ./path`
> If you look at other projects, you'll see they use opam files differently from one another.
Dune is independent of opam, opam file is needed to publish your package to opam. You can specify packages with dune without creating an opam file, see [2]
> I tried `opam install --deps-only`, but it complained sometimes about the state of uncommitted files.
If you use opam, you can do `opam install --deps-only`, or `dune build @install`, which would suggest a command to install missing packages.
[1] https://dune.readthedocs.io/en/stable/overview.html#project-...
[2] https://dune.readthedocs.io/en/stable/concepts.html#package-...
(Just to avoid accusations of <whatever>: I actually discovered FP through OCaml and wrote a few early-ish libraries in the ecosystem, but then discovered Haskell... and the rest is history.)
Probably never going to use OCaml again (just for business reasons, nothing against it per se), but good info for other readers.
EDIT: I also hope some of the OCaml'ers did get some of use of the things I wrote. I'm not going to doxx myself by naming the exact things, but just wanted to say... I hope you took advantage of them because the stdlib was quite anemic, so you might want to extend it. They were just missing bits of the ecosystem that I wanted to be more convenient... and I implemented a data structure paper or two.
I'm not sure why the author decided to use such a complicated setup using Make and Docker.
They could have just ran `opam switch create 4.09.0`, which would have created the compiler, then `opam install ...` for the dependencies.
Still, an interesting article. I wouldn't recommending using OCaml/ReasonML for gamedev since getting it to work with Windows is pretty much impossible.