[Haskell] Re: [Haskell-cafe] Is Haskell a Good Choice for Web Applications? (ANN: Vocabulink)

[Anton van Straaten]

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.

Anton