Paul Brannan wrote:

> On Fri, May 24, 2002 at 02:28:42AM +0900, Patrick May wrote:
> 
>>A gc language prevents memory leaks, it makes no performance guarantees :-)
>>
> 
> It helps to alleviate memory leaks, but it does not prevent them.  I can
> still get memory leaks by forgetting to remove a reference to an object
> from a hash, or by not being careful when registering finalizers.


In C++, I use the stack to create/destroy objects and if the objects 
themselves need to dynamically allocate large amounts of memory, I use 
the destructors to free up that memory.  Garbage collection and the lack 
of destructor functions are a nightmare to me...it's those two features 
precisely that will keep me from using Ruby in any large projects. 
Don't get me wrong, I love Ruby to death, it's an amazing language...but 
garbage collection is terrorizing me...I can't abide memory usage 
building up to a critical point and then having this giant collection 
process kicking in, dominating my application.

Memory management has been such a minor issue in all the projects I've 
been associated with in the past.  Once in a great blue moon we'll get a 
memory leak with C++ and it will take a day or two to figure it out. 
I'll trade the occassional memory leak over this garbage collection 
business any day.

I wish we could ditch it for stack-based memory management, with real 
object destructors to allow clean-up mechanisms for the dynamic memory 
allocations.  But, I assume there's some fundamental design issues that 
would make that impossible.

Oh well...I guess it's going to be what it's going to be.  Ruby is 
definitely a great script language, so I guess it's not a bad thing that 
it's memory management is so rubberized.  At least it will keep the ASP 
converts from hurting themselves.

	Sean