This article does a really poor job explaining what memory leak is and barely even mentions JS specific pitfalls (what could be expected by reading a title).
It is called toddlers guide for a reason. It’s meant to be a very gental introduction and I try to avoid going knees deep into the topic.
There are references to other great articles which tell you about pitfalls.
This is just “using lots of memory”, not a “leak”.
If you careful read the code
```
function sayHi() {
var allNames = [];
return name => {
allNames.push(name);
return ' ' + name;
}
}
```
It leaks memory on every invocation of the returned function
In the context of a language with a working garbage collector, doesn't "memory leak" just mean "accidentally using lots of memory"?
With cyclical references add "freed sometime between now and eternity".
If this is not a definition of a memory leak I don't know what is.
Well no, cyclical references only stop the object from being deleted if it's still accessible. That's what the 'mark' part of 'mark and sweep' does - it marks all objects still accessible somehow from inside the program. Then the 'sweep' bit runs through all allocated blocks and frees the unmarked ones.
Now, if you're merely approximating garbage collection with reference counting then sure, you have a problem.
Just monitor your production memory profile, and occasionally run load test on your app. It is fine.
All of these issues could’ve been avoided if we didn’t use functional programming. I think imperative languages are better because things like memory leaks and algorithmic errors are easy to conceptualize in the first place, hence less chance of typos.
All of these issues could’ve been avoided if we didn’t use imperative programming. I think functional languages are better because things like memory leaks and algorithmic errors are easy to conceptualize in the first place, hence less chance of typos.