If you need performance why not go with scala. The play framework is super easy to use. Anyone who is familiar with mvc will pick it up very fast. There is also Martin Odersky's course which is a great intro.
Which is a shame, since it's otherwise somewhat interesting.
Haskell is a much better choice than Scala, as long as JVM isn't required.
A professor I knew, who was easily one of the more decorated in my university, claimed he knew Haskell.
I had used Haskell to parse biomedical data for my course on biometrics, as the data was inconsistent and full of errors, the correct design was to create a monadic structure. I consulted that professor, and he was flummoxed, just on the basic structure of the program (which was done in a basic top down style of declaring the types and breaking large functions into small ones).
I fully accept my inability to use the language in a useful way may just be symptomatic of me being an idiot. I fully accept that my professors inability to understand the language in a any way may be symptomatic of him being an idiot.
But as big a failure as I am at learning this language, I can't imagine the result of tasking someone who doesn't enjoy programming with maintaining Haskell.
If scala is worse, then that's just horrifying.
But if we consider the resources to learn the language along with the language, then I think Scala dominates Haskell. Haskell was painful for me to learn because to become proficient I had to trudge through not only books but wikis, blogs, and code. There is nothing like Odersky's Scala book in Haskell. Learn you a Haskell, the Haskell wikibook, and Real World Haskell are all _terrible_ at preparing someone to become a proficient haskeller because while they show you the language they don't train you to think functionally.
In imperative languages you're giving a lot of sequential instructions to a robot. In functional languages you're programming the robot to understand a new language, and then you describe the way things ought to be in that language.
"It's a paradigm shift, you're used to programming
imperatively, this is not imperative. Think back to when
you first started programming, you got caught on doing
simple things, right? This is the same."
Of course, this library only gives you a toolbox to cover some fundamental logic, you can express really interesting things in short lines if you're skilled enough to abstract your problem out into general behaviour. Even I got this far, but when the problem your working on is best modelled through state, which is basically everything, you now have to understand monads.
What portion of the population do you think can utter these words confidently? "I Understand Monads"
Haskell provides no ramp up, there is no learning curve. I don't believe Haskell's problem is that it's different, I believe it's problem is that it's different and difficult.
Hofstadter says analogy is the core of cognition. We tie unknown things to known things to understand them, and I think that's why you get all these bad analogies where people try to tie the more abstract concepts of fp like monads to everyday things ( "monads are like burritos," for example).
And this really doesn't make sense because monads and such are pure abstractions. How do you tie a pure abstraction to something concrete? It's like saying zero is like a burrito.
The better analogies tie pure abstractions like monads and arrows to other abstractions that you already understand. For instance, Odersky trains you by iteratively refactoring imperative Scala code into more functional code, and thereby gradually carrying you up the ladder of abstraction.
What OCaml lacks, is a more modern implementation; I hear that the company OCamlPro are currently implementing a per-task GC strategy to allow for better multi-programming, there are alternatives to the rather minimalist standard library (Jane Street Core and Batteries Included), OPAM is poised to become the de factor OCaml package manager. I'm still hoping that built-in Unicode support will become a reality as well.
If OCaml gets better parallelism, it'll rival F# in usefulness, but without the annoying VM.
Haskell is much cleaner than Scala. But I think most people will get stuck reasoning about laziness (which is necessary to avoid space leaks). Another problem is that many modules require extensive use of the type system and advanced concepts to use (monads, arrows, lenses, existential typing, etc.).
I think that on the JVM Kotlin is a good candidate for eventually fixing most of Java's immediate shortcomings. Scala is there for people who'd like to go all-functional (regardless' its complexity). One of the nice things is that you get at least some amount of interoperability, e.g. one can perfectly write Play applications in Java and still get many of the benefits of Play.
Not to mention that many modules require various GHC extensions.
I'm not so sure about Kotlin. From what I can see, it's pretty straightforward, with no risk or ambition of achieving the anxiety-inducing Scala method signatures. On the other hand, it seems to be seriously lacking in the marketing department, which can often be enough to push forward a language even when a better option is available.
As a programming language, Haskell has many interesting features, and I would happily use it in various context, including as language of choice for a first "Introduction to Programming" course, but Haskell has several problems too. The most glaring is the 2nd rate support of state. The state monad has several good features, but in particular, it lacks a destructor, so local state use can't be hidden, even when global behaviour is purely functional. Moreover, modularisation is better supported in Scala than in Haskell.
I've looked at it a number of times, I don't like the syntax. When Java came out in August 1995 I was one of the first downloaders (and not even a fan of Sun in particular at that time, just interested in checking out Java) and it was clear just looking at it I would like it.