Hacker News Reader

> the recommended tools never seem to work together on anything but the latest version

Whenever a package is added to the repository, the CI tests (the latest compatible version of) every package that depends on it to check everything still works. However, non-current packages may break if they're missing upper bounds (it doesn't check all previous releases).

However, since opam-repository is just a Git repo, you can clone a known snapshot of it at some point in time and keep using that. That allows you to continue using old versions of packages without the risk of new software causing unwanted upgrades.

> My impression is that INRIA is too eager to add features and tweak the language.

That's strange. I've always had the opposite impression - that they maintain compatibility at all costs, including leaving sub-optimal APIs in the standard library.

> Next, everything builds so slowly, and just trying to set up Core, utop, and ocp_indent is a trial in patience, watching the same dep build again and again

The Core alternative standard library is pretty huge, indeed (I don't use it). I just tried installing all the tools you mention in a fresh container:

$ time docker run ocaml/opam:debian-9_ocaml-4.05.0 opam install core utop ocp-indent

6:03.75elapsed

So, 6 min to set up a dev environment with those tools. That installed 67 packages, so compilation took about 5 seconds/package on average. I'm not sure why it would build the same dep twice - I haven't seen it do that.

"> My impression is that INRIA is too eager to add features and tweak the language.

"That's strange. I've always had the opposite impression - that they maintain compatibility at all costs, including leaving sub-optimal APIs in the standard library."

When I started using OCaml, many standard library functions weren't tail recursive---you couldn't get the length of a list with more than ~10,000 elements, for example. The library definitely seems like an afterthought compared with the language. (And that would be why there are so many of them.)

Why would you hold 10,000 elements in a linked list?

I couldn't hold them in my cupped palms.

That's just - for example - every point in 100×100 R^2 cartesian grid. 10k elements is not by any measure a 'large number of elements'.

Just pick your algorithmic use case for a good excuse to use list and not an array from here:

http://bigocheatsheet.com

When you first write design your program, you might indeed use a different data structure than a linked list when you anticipate 10k+ elements.

But often programs are used long after they are designed, and it is great if they can degrade gracefully as you move outside their original design parameters.

> However, non-current packages may break if they're missing upper bounds....

Out of curiosity, how feasible is it for opam packages to use lockfiles like npm is nowadays? Then packages which depend on some other package will continue to build against the exact same version they always did, until and unless they are explicitly upgraded to the latest version of that dependency.

> I'm not sure why it would build the same dep twice - I haven't seen it do that.

Maybe https://discuss.ocaml.org/t/why-does-opam-recompile-so-much/... provides a clue to that.

I largely agree with you on OCaml, which was one of my favorite languages for quite a while and still is somewhere near the top. Last I checked, there were 3 (?) standard libraries, counting Core and the OCaml release.

But,

"I'd prefer OCaml to Haskell, I find it more practical, but I feel much better depending on Haskell-based software, which generally "just works.""

I take it you haven't been bitten by cabal? It's a nightmare every time I touch it.

On the other hand, I've been using stack (https://docs.haskellstack.org/en/stable/README/) with hakyll, which seems to improve the situation dramatically. It's just that first build for a new project that's very slow.

I think a first build with cabal is also very slow.

Haskell could solve that with binary distributions - but that requires more resources than are devoted to it, it seems.

`cabal new-build` basically fixes the problems you have had with Cabal, and the development experience with Haskell under Nix(OS) is pretty great too.

I've been working on a side project in OCaml and I can totally relate. I'm an OCaml old timer and I find amazing the amount of development that has happened recently. There's a lot of ongoing development in the libs and the surrounding tools (more so than in the language). I've spent a lot of time just to set up my environment and I had to pin several packages to their development version to make things work (jbuilder, merlin, ppx...). Moreover, a lot of these tools lack proper documentation, and it's difficult to get answers to your questions since it's a very small community.

I'm also an OCaml old timer and I think I can relate too. I believe the recent tooling changes are going in the right direction and will eventually fix several of these problems, for example:

There's a push to remove "optional dependencies" which are the reason why opam dependencies rebuild again and again: http://rgrinberg.com/posts/optional-dependencies-considered-... For example in the Mirage project we've been working on this https://discuss.ocaml.org/t/ann-major-releases-of-cohttp-con... but it has caused some breakage here and there.

jbuilder (from Jane Street) is excellent: expressive, easy to understand, builds packages extremely quickly, is actively developed, has minimal dependencies and a lovely manual http://jbuilder.readthedocs.io/en/latest/ It takes care of generating boilerplate for other tools like merlin (which to be honest I never got around to manually configuring). There's also work to integrate it with utop https://github.com/janestreet/jbuilder/issues/114

jbuilder also supports building multiple libraries in one big source tree, so we could switch to a package lockfile model: the author uses opam to create a solution to the package constraints and checks in the specific versions known to work, the build clones the dependency sources and jbuilder builds it all simultaneously. I'm keen to try this on one of my larger projects so that "git clone; make" just works, irrespective of where the host OCaml comes from.

PPX syntax extensions depend on specific compiler versions, so when (for example) homebrew updates to OCaml 4.05 you might find that extensions you need have not been ported yet. ocaml-migrate-parsetree aims to fix this problem http://ocamllabs.io/projects/2017/02/15/ocaml-migrate-parset...

There's obviously still plenty of work to do, but I think things are improving!

Yes, I agree that things are going in the right direction.

But a lot of things I'm trying to use aren't quite there yet. You mention jbuilder and the generated .merlin... it just doesn't work with current opam packages (at least not with ppx - I'm not doing anything fancy, just basic project with core). To fix this, I had to learn about opam pinning features, and then I had to carefully choose the jbuilder commit that works (the one after the bug has been fix, but before it breaks the compilation of bin_prot that I also use) and so on... As for Merlin, it's great, but the documentation is minimal. When it doesn't work as expected, it's hard to find where to look.

Core and Async are great, but besides 'Real World OCaml' that is a bit outdated and insufficient, there is little documentation and not much help on Stack Overflow.

That being said, I'm not complaining and I'm grateful to the guys developing these tools. But I think newcomers should expect some difficulties if they want to do anything serious using these most recent tools.

> It's like Rust, but without the "young language" excuse.

Howso? Stable Rust has been nothing but 100% solid for the past 1+ year I've worked with it.

Tools depend on Rust nightly. My points are more about the respective ecosystems than the core languages. For instance, getting up and running with RLS is a real hassle (in my experience, but I'm sure it's improving).

RLS is a pretty new thing and is very much a nice to have but not in any way required. I haven't used it until about a month ago. Racer worked just fine on Stable.

I dunno, maybe you had a bad experience but considering how well Cargo and the stable compiler work I don't thing it's fair to categorize Rust as never working correctly.

There's a path to RLS, and eventually Clippy, both working on stable, and to be distributed via rustup. The work isn't quite done yet. I'm guessing ~3 releases for RLS, counting the release next week.

The opam is pretty new. When I looked at OCaml a few years back my phd work, it didn't exist, so there's some churn in the tool chain

I think your overstating the pain though. Even in other languages, best practice demands you pin a library version so you wouldn't have some of those issues.

OPAM was released in 2013 and I recall it being mainstream by 2014. Maybe I am overstating the pain, but I've jumped through hoops for plenty of languages, and OCaml stands alone here. As somebody who's pretty good on the command line and at solving installation issues, the thought of a junior developer trying to get started with OCaml gives me shivers (probably another impetus for Facebook's Bucklescript).

> Facebook's Bucklescript

I think you mean FB's ReasonML. Buckle is Bloomberg's OCaml-to-JS compiler.