[Haskell-cafe] Is Haskell a Good Choice for Web Applications?
Anton van Straaten
anton at appsolutions.com
Wed May 6 18:54:13 EDT 2009
Jason Dagit wrote:
> I know from experience that lambdabot tends to be leaky. Otherwise,
> lambdabot wouldn't be running on my server to begin with. And, even
> so, Cale monitors lambdabot to make sure it is not using too many
> resources (and I complain when/if I notice it). I have heard similar
> stories related to hpaste and happs.
FWIW, I have an internal HAppS application that's been running
continuously since November last year, used daily, with stable memory usage.
> I have also experienced it with
> writing a forever loop in Haskell that did polling from channels. I
> would leave my app running for, say, 4 hours and it would be using
> tons of memory.
If you posted an example of that, there are probably people who'd be
interested in debugging it.
> I think it's fair to say that keeping the memory usage low of a long
> running Haskell app is hard, but that is a general issue not just a
> Haskell issue. It's hard in most languages.
I don't agree with this. This should not be hard in language
implementations with good garbage collectors, that don't have known
limitations (this excludes e.g. conservative GC and reference-counting
systems). In my experience, it's not hard to write stable long-running
code in good implementations of languages like Haskell, Scheme, Common
Lisp, or Java.
> I think what we need to
> address this is more information about preventative measures. What
> programming styles cause the problem and which ones solve it. I would
> say that I lack confidence recommending anyone to use Haskell for long
> running processes because I don't understand well the problem of
> keeping the usage low. If it is a well documented problem with
> documented solutions (more than just profiling), then I would regain
> my confidence because I know the problem can be worked around
> reliably. Does this make sense? Maybe it's already well documented?
This doesn't completely make sense to me, in that either a program has a
space leak, or it doesn't. If it does, you debug it and resolve it. If
a leak really is due to a problem with the language implementation or
standard libraries, then that should be identified and reported. There
shouldn't be any deep mystery here. At the very least, it should be
possible to point to the relevant trac tickets if there really is a problem.
More information about the Haskell-Cafe