Have you found any drawback so far?

What is your take on the "you have to write clever, complicated code to make haskell work" (1). I've read that a lot of the code use for the language shootout is far from idiomatic haskell, but just plain clever, in order to get decent performance...

(1): http://jxyzabc.blogspot.ca/2009/03/haskell-vs-ocaml-or-ravin...

>"you have to write clever, complicated code to make haskell work"

Haha, no. I write pretty dumb Haskell myself. The author might've tripped into a library beyond their faculties. Also possible, they might've tried to make something "practical" before they really knew what they were doing. I made this mistake in the past myself.

The library I've been working on makes my boring Haskell obvious: https://github.com/bitemyapp/bloodhound/

I even tweeted a sample of my code making fun of how "stupid-simple" my Haskell is :)

I might refine the code later, but for now I'd rather KISS until I'm prepared to firm up the design.

You can get down a rabbit-hole with Haskell if you want, but the same is equally true of Clojure/Scala/C++/Ruby/Python/Perl.

Even then, the rabbit-hole at least has typed hand-rails.

Negatives?

Uhhh, missing libraries (which I am working to help remedy)

You develop a "nose" for libraries for which you aren't the audience. It's not a big or unavoidable negative, but there are definitely libraries on Hackage made to prove a point rather than for use in production. These libraries are easy to identify. Some of them are prefixed acme-*

The primary negative that matters is simply that Haskell is deeply unfamiliar to most working programmers, so while it's 100% worth it, the road to Haskell isn't as well-trodden or smooth as it would be going between Python <---> Ruby.

I'm working to remedy this as well. I've been teaching Haskell for the last ~6 months.

The source for Bloodhound really is clean and simple. I might actually just use the Types.hs file as a my goto reference for the ElasticSearch query format next time I need to write some of those!

You could even load it up in a REPL and generate the JSON to see what stuff looks like.

The general approach for functional programming is to make some thing right (provably correct), and then transform it into something performant. There are books (pearls of functional programming) that elaborate on this technique. The thing is, the series of transformations retains the correctness of the original implementation.

In reality this isn't necessary very often. It is important to understand persistent data structures, how they differ from imperative ones, and which to use in different situations. However with a good understanding of the fundamentals (just as in imperative code) you'll be writing idiomatic performant functional code fairly easily.