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

[Jason Dagit]

On Wed, May 6, 2009 at 1:01 PM, Don Stewart <dons at galois.com> wrote:
> fft1976:
>> I've heard it's hard to contain a long-running Haskell application in
>> a finite amount of memory, but this is probably not a problem if your
>
> Hmm. Gossip driven development?

I don't mean to undermine your marketing efforts, but I don't think
this is gossip driven.

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.  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.

>> web site sleeps 0.001% of the time (like XMonad), or you can restart
>> it every once in a while without anyone noticing.
>
> Keeping footprints small and stable isn't so hard. After all, we have
> wonderful heap profiling tools. I recommend the type-based heap
> profiler, in particular. Run your app for a week, and look at the heap
> graph. You'll know if things are ok. (Try this in C++ !)

In C++ we have valgrind right?  But, yes, C++ has issues too with
memory leaks.  I think Java does as well.  In fact, probably every
programming language has issues here :)  Garbage collectors are good
at removing errors from freeing too soon and other manual memory
management issues, but in my experience they actually cause an
increase in space leaks by being conservative.

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 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?

In particular, we need expert Haskell programmers, such as Don, to
write more about how they avoid space leaks in long running apps.
Again, profiling is nice, but that's more of a tuning effort.

Thanks,
Jason