Hacker News new | ask | show | jobs
by p4bl0 4256 days ago
Small update: recent versions of OCaml have immutable strings too.

It also miss mention of package manager (OCaml has Opam, which is awesome, I don't know about SML).

And ocamlbuild is missing from the build tools section.

2 comments

Out of curiosity, why do you think Opam is awesome? I recently had to install a few OCaml projects and I had a hard time dealing with opam and ocamlfind (both on mac os and a linux VM). I suppose it's fine once everything is properly set up.

I have the impression that the OCaml world has seen a lot of changes recently with a lot of complexity added.

I think Opam is very cool because it simplifies OCaml development a lot, just like any language package manager does for its language.

With Opam I can deploy my code on different machines very easily by installing the right version of OCaml and library dependencies in just a few command, and it just works.

The problem with ocamlfind you are mentioning was just a temporary bug I think, I also encountered it, but it will be fixed real soon, see: <https://github.com/ocaml/opam/issues/1671> for instance.

> I have the impression that the OCaml world has seen a lot of changes recently with a lot of complexity added.

The first part of that is very true but the second part feels completely and utterly false to me. Where is this added complexity?

OCaml and OPAM were ridiculously trivial to set up on my system (via homebrew on a Mac) and OPAM 1.2, with many improvements, is due for release in the next few days [1]. Decent instructions are in the RWO wiki page [2]. The OPAM devs are responsive to bug reports and do a lot to maintain the health of the package ecosystem too.

If you're installing everything from sources then you're choosing to take on that burden and I wish you well but don't claim that more complexity is being added.

[1] beta announcement: https://opam.ocaml.org/blog/opam-1-2-0-beta4/

[2] https://github.com/realworldocaml/book/wiki/Installation-Ins...

> The first part of that is very true but the second part feels completely and utterly false to me. Where is this added complexity?

Recently, I tried to install a few ocaml projects. I had to learn what are Opam, OCamlfind, Batteries, Core... And unfortunately, it didn't work on my particular mac with homebrew. I had to use alternative ways of installing everything.

If you look at the installation procedure: https://ocaml.org/docs/install.html It may be rather complex depending on the platform, and if it doesn't work from the start, you have to dig deeply in this whole new ecosystem.

An other example. I was trying to install a project that compiles only using ocamlfind. Unfortunately, one of the libraries used wasn't available with Opam and I had to find it elsewhere and write myself the ocamlfind meta information.

So yes, to me, a lot of complexity was added. There are many new tools that you have to learn, a few standard libraries (I still don't know which one to use as a casual developer).

It's probably much powerful and it works well most of the time, but it's more complex than 10 years ago.

Nope, none of what you describe equates to 'complexity', there just happens to be more 'stuff' (unless you consider other, more popular languages with even more tools/libraries to be even more complex, in which case we have different viewpoints on what that word means in this context).

Sure, not everything is in opam and that can be quite frustrating but the improvements over the last few years have done a lot to reduce the pain that people experience (not increase it). Seriously, would you rather have the old ecosystem back? I know a large number of devs who would be quite hostile to that idea.

The standard library question isn't new and has been going on for some time but the options now are substantially better then they ever have been. Ask around and get feedback from others on what might suit your needs best. Until the community naturally converges on something, this is just how it is.

> "And unfortunately, it didn't work on my particular mac with homebrew."

So what went wrong? The instructions for homebrew are two lines and my experience here was flawless. The slew of instructions you point at are largely for Linux distros and most of those are also only a few lines. Were you trying any of these? It's clear that the install page you point to needs work (who still uses fink?) but in most cases it's just a time-consuming process, rather than a difficult one (i.e you just sit there while things compile). If something goes wrong, then reporting it on the list [1] or issue tracker [2] will help others to fix it.

[1] https://sympa.inria.fr/sympa/arc/caml-list

[2] https://github.com/ocaml/ocaml.org/issues

I find 'ocaml switch' very useful (sandbox functionality). Also, you can add a repo for your local stuff very easily. The CLI is pretty nice and well-designed.
My only reservation with Ocaml is that there does not exist a package management system for windows or even cygwin.

I cannot understand why OPAM takes so much to work on Cygwin. I like SML but it still does not have a good set of libraries.

I understand that these projects are sort of resources but supporting cygwin well should be easier than mingw or VS.

That was my biggest disapointment with "Real World OCaml", as the book requires OPAM to follow along.

Apparently it works with WOBI, an OCaml distribution for Windows. I haven't tried it though.

When on Windows I just go for F#.

WODI (not WOBI) didn't exist when we started Real World OCaml, and we developed OPAM along the way.

We've also started putting Windows support in place via Appveyor: https://github.com/ocaml/opam/blob/master/appveyor.yml

It just can't be activated by default since GitHub doesn't support multiple commit updates yet, so we have to chose between Travis and Appveyor. When GitHub sorts that out, we can have Linux, OSX and Windows tests for all new packages. In general, help porting packages to Windows is very welcome from interested parties.

> WODI (not WOBI) didn't exist when we started Real World OCaml, and we developed OPAM along the way.

Yeah, I was on the phone and did not check the right name. Thanks for the correction.

It is just that the work laptops I carry around are Windows based, so it was a bit limiting in that sense.

In spite of that, the book is quite good and I really enjoyed reading it.

> We've also started putting Windows support in place via Appveyor

Thanks for the heads up.

> In general, help porting packages to Windows is very welcome from interested parties.

Agreed, but on my specific case given that work is on the JVM/.NET ecosystems I am limited on time availability.

But at least now I can already give a better update on the current status.

Congratulations on the work that you guys are doing.