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.
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.
I have the impression that the OCaml world has seen a lot of changes recently with a lot of complexity added.
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.
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...
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.
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.
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.
Apparently it works with WOBI, an OCaml distribution for Windows. I haven't tried it though.
When on Windows I just go for F#.
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.
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.