I am using a Haskell/C combo for a distributed (on a "supercomputing" cluster) Machine Learning (commercial, non academic) project. About 20k lines of Haskell. A couple of 100K lines of C (Most of this will be moved to Haskell over time). Works like a charm.
As to why Haskell, I have not yet found any other language that combines its expressiveness and raw speed.
While kind of you to share this datapoint, the fact that there are 5 times more lines of C than Haskell is a bit less than compelling. Especially considering the fact that Haskell can achieve c-like performance (ie: not necessarily a glue language).
Good on you for using it in production though, that's more than most of us have achieved, I'm sure.
"While kind of you to share this datapoint, the fact that there are 5 times more lines of C than Haskell is a bit less than compelling"
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!
what's the machine learning project? (if you can't give specific details for privacy reasons, i would still be very interested to hear how ml is practically used in commercial production!)
I wrote a pure Haskell solution that implements a messaging middleware from a proprietary legacy DB system to a network for activating mobile devices.
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.
I used Haskell on my every job last 12 years to quickly prototype various things to get problems exposed early.
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.
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.
Citrix is using Haskell for XenClient. Drop me an email, if you want to know more. My team at Citrix is using OCaml for XenServer. Both teams are in Cambridge, UK.
Lack of training and lack of awareness. Here at work (in France), probably less than 3% of programmers ever used Haskell or ML. Less than 10% knows they even exist. And no-one would be willing to train a team so these languages can be used in a new project.
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.
I don't think Haskell training per se would ever work.
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.
For most people Haskell is the first introduction to some concepts (lazy eval, functional purity, etc.) that makes Haskell compelling in the first place. So as Haskell looks so foreign and they do not see the benefits they will reap, they do not even start. When learning Haskell you get rewarded as you progress but you have to work a little at the beginning (same with Common Lisp, at least for me.)
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.
Another possible issue, depending on your approach, can be how to integrate with external systems. I have seen teams trying to deploy a Haskell based common library to a heterogenous production environment and it wasn't pretty.
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.
Also, financial companies have a lot of money to attract top talent. Your average company probably can't easily find people who would get up to speed quickly with Haskell, whereas they'll surely be able to get people who do Java or PHP, and these days, probably also find Python and Ruby developers without too much trouble too.
I'm shocked, shocked to hear there's such little ML going on in France. After discovering OCaml and its progenitor INRIA, I've always just assumed that MLs and functional programming was more of a European thing, especially since they're more oriented toward proofs and program correctness, which I also thought was more a characteristic of European CS and software engineering. But no?
OCaml is still quite academic, Caml-light (Caml without object and with some difference) is used to teach CS in some Math undergrad and it is use by academic researcher who don't want to go back to C. That's said there is not so much Engineering/Commercial use of it. (Some blame INRIA for not pushing it, supporting it enough, especially the lack of extended library and threading trouble).
There are pockets here and there, like INRIA and the Scala people around Odersky in Lausanne, Switzerland. But it's not something on a larger scale. I think Erlang is somewhat prominent in some places, too.
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?
2 workplaces plus a good deal of acquaintances, in fact. In my niche (custom technical or scientific software, mostly for the government), I'm 99% confident that ML makes less than 0.1% of currently written code. 80% of my colleagues even never heard of ML.
I've always thought it was really weird how little OCaml was used in France, the French as a people tend to prefer do to things "the French way" (as opposed to the Anglo-Saxon way).
In an investment bank you get a lot of conversations like this:
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).
My site isn't production ready yet, but I'm writing my back-end in Haskell. It's exposing a REST API via HappStack to the RoR front-ends.
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.
I am using Haskell to simulate data for a machine learning system. The project has other components we are planning to implement in Haskell.
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.
As to why Haskell, I have not yet found any other language that combines its expressiveness and raw speed.