Excuse my pedantry but these aren't technically memory leaks, great article nonetheless :)
This really is just pedantry though, because the net effect is "the memory usage chart keeps going up and to the right" in both cases. "Memory leak" is a fine enough term for what's happening in this case.
The Full Article is talking about handing over data with references to live objects to some library that doesn't let go of those references, it seems. That is a space leak and can and will happen anywhere in any language regardless of whether you're using a perfect GC or not.
So the difference is this:
Ruby has a memory leak -> not my fault, I'll just stop using the offending method that leaks memory, thanks article!
Someone caused ruby to space leak -> duh, it's your fault, no need to write an article about it, you should be letting your references be GC'ed if you don't need them anymore, learn that memory is a scarce resource, etc.
Totally different problems. I was very confused reading the comments here because people are afraid of being called a pedant. Folks, our trade comes with a jargon. If you don't learn it you won't know what you don't know.
Saying simply "unneeded memory is not being reclaimed" is not constructive. Why is it not being reclaimed? Because the reason matters to programmers, we invented different names for those occurrences.
Yes it is. It's a description of a problem your monitoring tool has reported that needs investigation.
> Why is it not being reclaimed?
That's the first step of the investigation of the memory leak.
It's OK if you don't understand the difference yet - you'll get it eventually - but there is a big difference.
Oh I understand the difference. But losing track of memory and accidentally keeping memory in play are both called memory leaks. I would still call it a memory leak if it's due to cyclic references or stale entries in a hash table or other container.