1. 18

  2. 14

    I guess by now it’s useless to complain about how confusing it is that OCaml has two (three?) “standard” package managers; the ecosystem around the language is kind of infamous for having at least two of everything. I trust the community will eventually settle on the one that works the best. At least it looks like esy is compatible with opam libraries (though the reverse is not true), so it might have a good chance against opam.

    Also this is kind of unrelated, but I’m really salty about ReasonML recommending JS’s camelCase over OCaml’s snake_case. This is one of the few rifts in the ecosystem that can’t really be fixed with time, and now every library that wants to play well with both OCaml and Reason/BS ecosystems will have to export an interface in snake_case and one in camelCase.

    1. 12

      I second the choice to use JS’s camelCase for ReasonML as a salty/trigger point. It seems like a minor syntactic thing to make it more familiar for JS developers making the switch, but as someone who primarily writes Haskell for day job - camelCase is just less readable, IMO. Something I constantly am irritated that I even have to think about is casing acronyms consistently - which is avoided by snake_case or spinal-case - ie. runAWSCommand or runAwsCommand, setHTMLElement vs setHtmlElement - run_aws_command, set_html_element, etc.

      1. 3

        The strangest thing for me is the “hey, there’s two mostly compatible syntaxes for this language we call ReasonML” but it’s mostly the same thing as Bucklescript from which we use the compiler anyway, except this, and this, and … oh and by the way, it’s all ocaml inside. What ?!

        1. 1

          “Oh and also the docs for all these things (which you need) are all in completely different places and formats”

        2. 2

          I think the ReasonML team wanted to match the conventions of JavaScript, where camel case is the norm.

          I can see the annoyance though… and I have to wonder, is ReasonML syntax much better than OCaml’s? Was it really worth the break?

          1. 6

            It’s not “better.” Yes, there are some cases where they’ve patched up some syntactic oddities in OCaml, but it’s mostly just change for the sake of being near JS.

            Is it worth it? Depends. ReasonML and its team believe that OCaml failed to catch on because of syntax. If you agree, then yes, it’s worth it. And based on the meteoric rise I’ve seen on ReasonML, they may be right. That said, I believe, with good company, think OCaml didn’t catch on because it had two of everything, had really wonky package managers (and again, two of them), and still lacks a good multithreading story. In that case, no, the syntax just is change for no reason, and the only reason ReasonML is successful is because Facebook is involved.

            1. 2

              I’m all for functional alternatives displacing JavaScript but my main frustration with ReasonML is that any niceities you gain from using it are outweighed by the fact that it’s just one more layer on top of an already complex, crufty, and idiosyncratic dev environment. I think that’s what’s holding OCaml back as much as anything else.

            2. 4

              Some people seem to think that OCaml’s syntax is really ugly (I quite like it) and unreadable. I’m guessing they’re the same who complain about lisps having too many parenthesis.

              ReasonML does fix a few pain points with OCaml’s syntax, mostly related semicolons (here, here, here), and supports JSX, but it also introduces some confusion with function call, variant constructor and tuple syntax (here, here, here) so it’s not really a net win IMO.

              I think ReasonML was more of a rebranding effort than a solution to actual problems, and honestly it’s not even that bad if you disregard the casing. Dune picks up ReasonML files completely transparently so you can have a project with some files in ReasonML syntax and the rest in OCaml syntax. The only net negative part is the casing.

            3. 1

              Esy and bsb are build orchestration tools, not package managers.

              Esy is not OCaml-specific, it can e.g. include C++ projects as build dependencies. This is how Revery ( https://github.com/revery-ui/revery ) is being developed, for example. Esy also solves the problem of having to set up switches and pins for every project, with commensurate redundant rebuilds of everything. Instead, it maintains a warm build cache across all your projects.

              Bsb specifically supports BuckleScript and lets it use npm packages. It effectively opens up the npm ecosystem to BuckleScript developers, something other OCaml tools don’t do (at least not yet).

              Having ‘two of everything’ is usually a sign of a growing community, so it’s something I’m personally happy to see.

              Re: casing, sure it’s a little annoying but if C/C++ developers can survive mixed-case codebases, hey, so can we.

            4. 3

              So many language specific package managers. Still looking for a good one that works across languages. Is this not possible?

              1. 4

                Nix with the tooling in nixpkgs fills this need for me, but requires a certain amount of buy-in.

                Perhaps there is a better way.

                1. 3

                  Have a look at Nix and Guix

                  1. 2

                    This is possible if you have a build system that works for all languages, Buck and Bazel are the best candidates for such a build system imo.

                  2. 2

                    OCaml could do with a CI site. Circle and travis can do it but it requires a hell of a lot more effort than explicitly supported languages. Inria has a CI site, iirc https://ci.inria.fr/ but when last I looked was for Inria people only.

                    1. 3

                      For upstream repositories, people normally seem to use Travis or AppVeyor (for Windows), using the scripts at https://github.com/ocaml/ocaml-ci-scripts.

                      Another option is to provide a Dockerfile and then configure Travis to build that (e.g. https://github.com/mirage/capnp-rpc/blob/master/.travis.yml). That also means you can test the build locally easily and get the same result as the CI.

                      For opam-repository, there are various CIs, e.g. http://check.ocamllabs.io/ shows the status of every version of every package in the repository against each version of the compiler.

                    2. 0

                      So many language specific package managers. Still looking for a good one that works across languages. Is this not possible?