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