As to why Haskell, I have not yet found any other language that combines its expressiveness and raw speed.
Good on you for using it in production though, that's more than most of us have achieved, I'm sure.
Legacy Code (almost 10 - not 5 - times as much C than Haskell). Can't transform it instantly, much as I would like to. (I did explicitly state that most of this is being moved to Haskell).
Why should a pre existing code base preclude the use of Haskell in production and be "not compelling"? I don't get it. But hey if it helps there's even a few thousand lines of Fortran in there (accessed through a C interface). Even less compelling now? ;-)
Fwiw, The 20,000 lines of Haskell would be (at least) equivalent to another 100,000 lines of code in C. So at least 1/3 d of my project is in Haskell. And the ratio is increasing everyday. The OP asked for examples of using Haskell in production. I am using Haskell in production. I didn't see any "purity constraints" in the OP's question. But maybe they were implicit who knows. I am just throwing out what I do with Haskell.
If you find it "less than compelling", that's fine. My clients (the users of the system) are delighted. Good enough for me!
It was my first real Haskell project, and although I had lots and lots of book knowledge about the language, the outcome was quite warty. Nevertheless, Haskell delivered what it promised: the software was completed much faster than a roughly comparable C product was before (by a better programmer than me) and making changes to a finished product was very easy and safe and did not cause new bugs.
Perhaps the worst problem was the lack of quality libraries for doing some practical things, such as simple socket listening (I had to pretty much code Haskell like it was C in that part), and I had some trouble (bad memory leaks) from the curl library.
And even worser than worst was the problem that only one person got interested enough in the language that he helped me with the project, and, although he was able to produce working code in a month from zero experience, he ended up disliking the language.
For instance, they have developed an air traffic analysis tool for NATS[1] which they briefly blogged[2] about.
This included: prototypes of image analyses (image registration), MIPS-alike CPU prototype, Direct3D pixel/vertex shader assembler language analysis (data flow patterns), prototyping various dynamic data flow CPUs, translator Fortran-to-Lisp (for our colleague who prototyped compiler analysis in Lisp), testbed for viodecontroller, VHDL-to-netlist translator (synthesable subset) for our modeling system, simple GUI for some kind of IDE for modeling system, DSeL for CPU model description.
I even tried to create integrator for "game physics" using infinite lazy lists using ideas from http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.32.4...
Most of my pet projects start as a Haskell source. Often they get abandoned, sometimes they evolve into something big.
This "pettiness" of Haskell projects play an important role: they can be thrown away because they are cheap, and they can evolve into something pretty big - easily.
We are looking for people.
We were planning to use it a lot for a server-side code, but as my Haskell is rusty, we decided to go mainly with Python.
Now, financial software may get away with those because they don't really have a choice: they are a narrow field, with a critical need for correctness.
Conversely, you could say that most projects get away with ignorance. They use sub-optimal languages, for the very short term benefit of not training people.
Haskell is beautiful because smart people find it to be a really good way to express their problems and solutions. Haskell is the way their thinking comes out. So if you're in that 3% you probably know and possibly even use Haskell already because you have that sort of train of thought. If you're in the remaining 97%, you could only do much less or barely nothing at all until you had had a long series of "aha!"s, not often even related to Haskell itself.
Instead of language training, effectively a mindset-changing smartness training is what would have to come first.
At $WORK I used to show some cool stuff in another language and tell my coworkers it is built-in in Haskell (the concurrency stuff is what interested them.) I hope some of them will have a look at it in their spare time.
The core Haskell module itself solved a specific problem beautifully, but it all got very messy outside the confines of the pure and pretty functional world.
Especially the Lisp community seems to be almost completely American to me (in Europe), with Racket in Boston, SBCL from CMU, and Clojure, too. What's going on in Lisp development in Europe?
Manager: WTF are you doing?
Employee: Making money
Manager: Fine, carry on
So there are a ton of exotic languages kicking around (and even banks where some ubergeek has gone off and created an entirely in-house language, and then implemented some key system in it).And not just programming languages either...
What stops me from using Haskell for the front end is that I'm familiar with RoR (and so my prototyping is fast) and I haven't been amazed by any of the templating systems in Haskell yet.
You may fight hard with the compiler to get your program to compile, but after that "it just works". Also functional programs are bite-sized, so making changes feels easier.