[RyanZAG]

That this kind of issue exists in javascript should come as a surprise to no one - there are probably a huge number of these kind of issues just waiting to be found. It's actually the key difference between a 'designed' language and an 'evolved' language.

EDIT: I find the down-votes very amusing. Has javascript now developed a cult? Read up on the history of javascript if my message above comes as a shock to you.

[crazygringo]

I think the down-votes are because you're attacking JavaScript without basis, and not constructively. This "memory leak" has nothing to do with the distinction between languages you make. And indeed, this kind of behavior in closures is by design (as I understand it), and not by evolution at all.

[RyanZAG]

Fair point, but I disagree with you - fulled specced out designed languages generally specify how exactly the implementation should handle these cases. How references should be retained, when references fall out of scope, etc.

eg:

http://clang.llvm.org/docs/Block-ABI-Apple.html

http://download.oracle.com/otndocs/jcp/lambda-0_5_1-edr2-spe...

http://www.microsoft.com/en-us/download/details.aspx?id=7029

etc etc. I also don't believe I'm attacking javascript here, merely repeating what people have always known about evolved languages. Evolved languages have a lot of pros (mainly speed of new features and practical application), and they have cons too. What I'm saying is very simple: this type of bug in javascript should not be a surprise - it should be expected. There will be more.

EDIT: Laughably enough, while the ObjC and Java specifications both specifically address this issue, the C# specification actually formalizes this exact bug into the language specification. So I concede your point, C# - a designed language - simply designed the exact same bug into the language itself. See section 7.15.5.1 Captured outer variables.

Feel free to downvote this post - I now concede that designed languages are just as likely to design stupid bugs into the language as evolved languages are to create them by mistake. ;)

[mattmanser]

This is going to come across as incredibly condescending but I honestly don't mean it as such.

When you have some more experience and a greater breath of knowledge programming you will see this kind of thing happens all the time. Whether by design, by accident, by omission, by not quite being explicit, by implicitness, it happens in every spec, in every language and in every protocol.

You can find something like this in them all.

[viraptor]

It's a bug in a complex element (GC). They happen. I wouldn't attribute it to a specific language, since even this post only mentions the latest Chrome.

There's a small reproducer example, so there will be a new version issued shortly. Not really something to get excited about in my opinion.

(Yes, I know this behaviour could be actually called ok and allowed, but you can do analysis on that code that will show the variable is not used. Even if not now, it can be fixed at some point in the future.)

((Downvoted as language bashing, rather than because I like JS - I hate it with passion for other reasons. "there are probably a huge number of these kind of issues just waiting to be found" is just a silly claim unless you're actually working on finding them or a true claim for any kind of general purpose software.))

[RyanZAG]

I believe you are correct, my misconception regarding the disparities between designed and evolved languages that was nicely cleaned up for me by reading the specification for the designed C# language. Down-vote for my stupid comment appreciated, it got me to actually read the thing.

[nknighthb]

I hate JavaScript myself, but you're blaming it for what is actually an implementation problem, not a property of the language itself. It's also a problem I could see occurring in the implementation of any other language that supports closures.

[pcwalton]

This is a V8 problem, not a JavaScript problem. Any implementation of any garbage-collected language with higher-order functions could have this issue.

[wtetzner]

Actually, in this case it's not the design of JavaScript that's the problem. It's V8's implementation of closures. The two functions are sharing the same environment object, but there's nothing in JavaScript the language that dictates this implementation.

[lquist]

I wonder if this will temper the rise of the server-side JS frameworks?

[RyanZAG]

Not likely - these kind of bugs are generally fixed when found, or remain hidden simply because that part of the language is very rarely used. You'll likely see this bug in Chrome fixed within a few months.

I was commenting more on the practical effects of having an evolved language - this is a known and likely outcome in an evolved language. Designed languages generally spend a lot of time trying to avoid these kind of issues - it makes sense that not spending that time and adding in features as they are thought up means issues like this will creep in somewhere.

[pcwalton]

The only language features at play here are closures and garbage collection. Pick your favorite "designed" language: if it has those two features, an implementation of that language could have this bug.

[PommeDeTerre]

This problem is quite minor and obscure compared to many of the other inherent flaws (type coercion and the broken comparison operators, the lack of proper namespacing, broken scoping, semicolon insertion, hoisting, prototype-based OO, and so on) we see all throughout JavaScript.

If those problems weren't enough to convince certain developers that JavaScript is a bad idea, and unsuitable for use, then it's likely that nothing will. This is especially true for server-side usage of JavaScript, where there are so many far better alternatives.