Ask HN: Anyone using Haskell in production?
If so, what projects/products? I'm curious to know what jobs you found that Haskell was awesome for and other languages couldn't keep up.
14 comments
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.
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.
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.
I think jrockway is if he wants to comment. Financial services seem like one of the few industries that can get away with it.
what is there to get away with?
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.
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.
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.
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.
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.
Have a look at XMonad to see how dealing with the messy real-world (i.e. X) can be done beautifully with Haskell. (See http://cgi.cse.unsw.edu.au/~dons/blog/2007/05/01#xmonad_part... for a simplified introduction.)
Classic Dunning-Kruger effect.
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?
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?
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?
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).
As said earlier, we are using OCaml at Citrix.
Demand for OCaml and F# people here is insane right now. I just turned down a £390k job offer.
One workplace != France != 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.
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'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:
And not just programming languages either...
Manager: WTF are you doing?
Employee: Making money
Manager: Fine, carry on
And not just programming languages either...
Well-Typed, a Haskell consultancy, seems to do quite a bit of work exclusively in Haskell.
For instance, they have developed an air traffic analysis tool for NATS[1] which they briefly blogged[2] about.
[1] http://www.nats.co.uk/
[2] http://www.well-typed.com/blog/39
For instance, they have developed an air traffic analysis tool for NATS[1] which they briefly blogged[2] about.
[1] http://www.nats.co.uk/
[2] http://www.well-typed.com/blog/39
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.
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.
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!
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!
Thanks for explaining. I guess rbxbx was just curious, and did not think about the possibility of legacy code.
I find it more compelling, actually. Its not how much code there is, it's what it does. Haskell is way more compact than C.
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!)
My co-founder uses it for scripting and we do a little data manipulation on our game dev toolchain with it.
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.
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.
Barclays Capital uses Haskell to describe equity derivative instrument payoffs: http://lambda-the-ultimate.org/node/3331
Dammit... Avoid success at all costs?
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.
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.
Here is the section on commercial users from the most recent Haskell communities report: http://haskell.org/communities/05-2010/html/report.html#sect...
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.
We are looking for people.
We are looking for people.
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.
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.
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.