so, workflows described in yaml? I also am a bit ambivalent about Airflow and the way workflows are built up in it, but YAML seems really weak and unlikely to handle complexity well.
Also - it's entirely built around Hadoop from what I can see? Seems a limited use case compared to Airflow.
> it is very complicated to install the base stack to develop in OCaml
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.
While I didn't try to use Docker (though we did use the same pxhere image :-p), I also struggled to get a productive setup of OCaml. Getting a switch running wasn't the hard part, it was making the environment suitable for real project work. I had a set of Make targets in mind (test, build, shell), some language dev features I wanted (jump to definition, type of expression under cursor), and some properties of the project (pinned dependencies) such that it took a fair bit of fiddling with dune/opam to get it working https://morepablo.com/2019/08/fresco-jesus-ocaml-setup.html
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.).
I agree it's quite annoying to set up an OCaml project, and all the Jane Street stuff makes it even more confusing for newcomers. But to be fair, it may be the case with other languages as well. I recently tried to learn some Javascript, and I spent some time understanding the tooling and package management (npm/yarn, bundling, transpiling, node vs browser, difference between javascript versions).
.NET you install either Visual Studio or just the SDK and everything just works. And it's not just the initial setup. It's the best debugging experience available. It has a robust extension system, though honestly, you don't need to engage it and you're still having an amazing experience.
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.
VS installation is also a PITA if you have your C:\ on an SSD. The installer doesn't give you choice of what partition to install to (for most of its huge disk space demands) so you need to fake it with a bunch of symlinks. The VS team recognizes this problem but doesn't do anything about it, as follows from the comments on https://developercommunity.visualstudio.com/content/problem/...
Good question. Their libraries are robust and certainly useful if you want to develop real applications. I'm not sure but I'd say no because I think they add an extra level of complexity of a newbie. They are also quite opinionated which some people may dislike.
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.
This seems sort of like comparing the complexities of learning German to a level of fluency with the complexities of learning English, differences between major variant forms of English, with a deep dive into the history of the English Language and its poetics.
It is complicated to figure out a straightforward way to do builds in OCaml. If you're not tapped into the Current Way, you kind of have to read this blog, read that fragment, piece it together. I worked it through for a project of mine, and it was unusually unpleasant vs, say, Haskell.
Docker because, presumably, he didn't want to dink with installing it locally.
- 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.
> Tree-like heirarchy of dune files confused me since it wasn't really explained anywhere.
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.
I can't find it complicated at all. I control my OCaml builds mostly from simple, hand-written Makefiles. Reading up on the pertaining compiler and linker options is something you'd have to do for any compiled language. Building with dune isn't that much harder, either.
Agreed, the choice to use obuild was also bizarre. Dune has been standard for the last ~2 years and before that Oasis was the most popular build tool I believe.
It's been a few years since I tried opam... When I did it just barfed out some obscure error message and I wasn't encouraged to try ever again. I realize that that's not really helpful towards improving the UX, but maybe it helps as a single data point?
(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.)
Opam has gotten quite good. When you set it up, you're being guided through all the steps. Works best on Mac, with Linux a close 2nd. Windoze may pose some extra challenges for setting up a working environment.
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.
