Hacker News new | past | comments | ask | show | jobs | submit login

Excuse my pedantry but these aren't technically memory leaks, great article nonetheless :)



"technically". Almost any comment containing this word is not helpful. So is this, we don't need a definition debate of memory leak every time it comes up for dynamic languages.


I'm curious what you mean by this!


Memory leaks are technically when you allocate memory, then lose the reference to it without freeing it, thus leaving the memory permanently allocated without a way to free it. Outside of a serious VM bug, you won't leak memory in a GC'd language; instead, you can leak references (leaving objects alive and uncollectable even after you've finished using them, because you've left a reference to the object laying around somewhere without intending to). The memory is still reclaimable, if you can eliminate the references keeping the object from being GC'd.

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.


They are both memory leaks. Unneeded memory is not being reclaimed. It's not even pedantry. It's just incorrectly applying one type of problem to the whole range of problems captured by the term.


Relax. It's not pedantry. If I click on a link titled "Memory leak in Ruby" I'm concerned the GC has a problem and I should avoid some particular method call or something else because the GC is currently having trouble collecting something in particular. That would be a memory leak.

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.


>Saying simply "unneeded memory is not being reclaimed" is not constructive.

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.


You can have space leaks without memory leaks (if you build up big enough thunks/delayed computations/promises or otherwise run out of heap space) and you can have memory leaks without space leaks (malloc 1 byte and lose its pointer).

It's OK if you don't understand the difference yet - you'll get it eventually - but there is a big difference.


>It's OK if you don't understand the difference yet

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.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: