Five years ago, I tried to tackle Haskell first, and found it way too weird. OCaml was a lovely way of getting used to a lot of concepts in the space while being able to be quickly productive in it (which is kinda necessary if you want to really learn the thing).

Learning OCaml then motivated some issues that Haskell addressed, so I was quite ready and enthused to learn about Haskell’s take.

You may find this route works for you.

I’ve used both in significant anger and Haskell in production. Both are good next steps and both will take some serious getting used to over Erlang. Your personal goals will dictate the right next moves, so it’s worth noting that Haskell will introduce you much more forcefully to ideas of “purity” which can be very useful. OCaml is made somewhat simpler to understand by avoiding this issue. OCaml will introduce you instead to the idea of “modularity"—which is not precisely what you might think it is based on prior experience—and I’d say you should take a detour though learning that concept regardless of which one you end up investing more time into.

If your goals are more project-oriented then either can work, but Haskell’s library ecosystem is vastly better developed today. Haskell in production is tricky due to laziness—you will have to learn new techniques to deal with it. OCaml I’ve not used in production, but the challenges there seem more likely to be around getting the right initial momentum as you may have to write some significant portion of library code and work around a bit of ecosystem incompatibility.

Speaking of ecosystem again, OCaml has a standard library problem in that its genuine standard library is often not what the doctor ordered and there’s a choice of “extended” standard libraries. This choice sometimes feels a little forced which is slightly ironic due to the aforementioned modularity goals of OCaml, but c'est la vie.

The Haskell community has issues or benefits in that you will undoubtedly run into someone sooner or later who will happily try to explain the solution to a problem as a mere application of recognizing your algorithm as being a catamorphism over an implicit data type or will suggest refactoring your effect stack according to mtl or a Free monad. It might even be me that does this. Jargon aside there’s some significant insight that Haskell can be a gateway drug to. On the other hand, this can be the absolute last thing you want to hear when trying to get your project working. Mileage varies here.

The OCaml community has issues in that it’s small and sometimes speaks a lot of French.

Both communities are great in that they’re full of passionate and damn smart folks, though.

I’ll throw my hat in for Haskell since you’ve gotten mostly “OCaml then Haskell”, “OCaml”, and “Both” answers.

Learn Haskell. It can be easier and less noisy than OCaml too. The ability to do ad-hoc polymorphism with typeclasses in a way that is more conventionally what people want out of polymorphism without giving up type-safety is pretty nice. If your goal is to learn new things, the overlap-but-different bits between Haskell and OCaml won’t do a lot of good either. Haskell’s built on a simpler core semantically as well.

tl;dr I got tired of writing .mli files, I prefer my types to be next to my code, and I found modules tedious for everyday work. YMMV.

You won’t harm yourself by learning both, but you’ve got to make a choice of where to start. I think there’s a lot to be said for learning Haskell first, hitting some limitations of typeclasses, then playing with modules in OCaml or SML.

Disclosure: I am quite biased, but this is stuff I actually use in my day to day, not night-time kicking around of pet projects. Haskell is my 9-5 and I wouldn’t replace it with OCaml. That said, if Haskell disappears tomorrow the first thing I am doing is writing a Haskell compiler in OCaml and I can’t say I wouldn’t enjoy it :)

Why not dip your toes into both and see which you prefer? You’ll only be better for it.

I’ve programmed a bit in both, and I would say either one would do. Personally I’m doing a bit more with Haskell lately, and typeclasses are a nice feature (as others have mentioned). On the other hand, perhaps the very rigid way in which Haskell deals with effects can be a little overwhelming at times, and OCaml would be a little less rigid on this front. Two other things I can think of which might also push you towards OCaml may be the recent excellent O'Reilly book Real World OCaml by Minsky et al (the same author as the blog post), and the similarity between OCaml and other ML'ish languages such as F#. F# is a fully open-source project and Visual F# is a first-class citizen within the .NET ecosystem, if that happens to be of interest to you. In short I would say you are choosing between two excellent and well-designed languages and really can’t go too wrong. You’ll probably want to check out the “other one” (as I have) irrespective of which way you step now. Good luck!

I personally prefer Ocaml, although I wish it had haskell style typeclasses.

Coming from Erlang, getting used to either one will require a bit of mental rewiring. Haskell more than OCaml, since with OCaml you’re allowed to throw printfs (not literally) around. OCaml’s type system is not as expressive than Haskell’s but it is certainly very advanced in its own right and it probably is easier to learn.

Fundamentally, both belong to the ML family, so learning either one first will help in learning the other. If I could choose I would learn Haskell first, because it is stricter in the type system sense. Moving to OCaml will feel like loosening a belt, so to speak. That said, OCaml isn’t a simpler language by any means: it has a powerful OOP system, module functors (think parametrized static classes) and a great record system. Recent versions added GADTs. Concurrent and parallel programming on OCaml is a sadder story, but work is being done on it.

Both, but start with OCaml.

Both haskell and ocaml are very similar in many ways. Type signatures, HM-like type inference, etc. However, in Haskell, many things are more “magic”, whereas in OCaml, code is typically more explicit.

It depends on what you want to accomplish. I would feel much more comfortable deploying Ocaml to production than Haskell. Ocaml (currently) is very easy to reason about how it will perform, as it does not do any super interesting optimizations. The computation model is also much closer to how I feel comfortable thinking (eager evaluation). Haskell on the other hand can be deployed to production (Facebook is doing it), but they also have Simon Marlow on the team so I’m not sure if that is an unfair advantage. That being said, if you want to expand your world of how computation can be, Haskell is well worth diving into.

Haskell, or F# instead of OCaml. You’ll find that F# is more widely used because of Microsoft’s backing.