4 ms·

It's not even a particularly unexpected leak. When you create unbounded recursion, you leak memory. This is true if you don't use Promises, and remains true whe

It's not even a particularly unexpected leak. When you create unbounded recursion, you leak memory. This is true if you don't use Promises, and remains true when you do. This is really just another complaint about lack of Tail-Call Optimization. This issue has come up for any number of languages and libraries. Often I think that the "O" in TCO is a misnomer. If it was really an "Optimization" it wouldn't affect correctness of the program, but there are many cases where a program is correct if TCO is happening but undefined if not. It's more akin to lazy/strict evaluation: equivalent in simple cases, a major correctness issue in more complex ones.

_nalply 9y ago
But even with Tail-Call Optimisation the code would run forever. In which world is never-terminating hot running code «correct»?
- bad_user 9y ago
  In the case where you've got an incoming stream of real time events?
- scarlac 9y ago
  "Forever" is obviously just a reference to would happen with memory usage. Proper optimized code could run "forever" (or a long time) without increasing in memory usage, ie. memory would scale as O(1) as opposed to O(n).
bad_user 9y ago
> This is really just another complaint about lack of Tail-Call Optimization TCO needs to be supported by the runtime, but what I'm talking about only needs to be supported by the Promise implementation, so in this case it's just a sloppy library we are talking about. > When you create unbounded recursion, you leak memory This is only true in weird universes, like that of JavaScript. It's actually really easy to end up with a really long chain of tail recursive calls - for example when processing streams or when doing functional programming in general. Having to explain why this is a huge problem is one reason for why I feel that JavaScript's ecosystem is so broken. In case you're wondering, given Promise's surprises, I actually think going for the callback hell is saner, because in such cases you just pass a callback around without surprises.
- sirclueless 9y ago
  TCO is classically a compiler/runtime optimization, but that's only because people didn't commonly implement fundamental control flow as libraries until relatively recently. Whether it is the runtime introspecting function calls to decide whether it can elide the current stack frame, or a futures library introspecting return values to decide whether the current future can delegate to the returned one, it's the same concept. As for "weird universes", it is typically only functional programming languages that guarantee TCO as part of their standard. Most programmers live in a world where they can't rely on their implementation to optimize tail-calls, which is to say they don't make unbounded recursive calls. If they do, they end up with an insidious form of non-portable code.
- bjpbakker 9y ago
  > Having to explain why this is a huge problem is one reason for why I feel that JavaScript's ecosystem is so broken This! Exactly this.

_nalply 9y ago

But even with Tail-Call Optimisation the code would run forever. In which world is never-terminating hot running code «correct»?

bad_user 9y ago
In the case where you've got an incoming stream of real time events?
scarlac 9y ago
"Forever" is obviously just a reference to would happen with memory usage. Proper optimized code could run "forever" (or a long time) without increasing in memory usage, ie. memory would scale as O(1) as opposed to O(n).

bad_user 9y ago

> This is really just another complaint about lack of Tail-Call Optimization TCO needs to be supported by the runtime, but what I'm talking about only needs to be supported by the Promise implementation, so in this case it's just a sloppy library we are talking about. > When you create unbounded recursion, you leak memory This is only true in weird universes, like that of JavaScript. It's actually really easy to end up with a really long chain of tail recursive calls - for example when processing streams or when doing functional programming in general. Having to explain why this is a huge problem is one reason for why I feel that JavaScript's ecosystem is so broken. In case you're wondering, given Promise's surprises, I actually think going for the callback hell is saner, because in such cases you just pass a callback around without surprises.

sirclueless 9y ago
TCO is classically a compiler/runtime optimization, but that's only because people didn't commonly implement fundamental control flow as libraries until relatively recently. Whether it is the runtime introspecting function calls to decide whether it can elide the current stack frame, or a futures library introspecting return values to decide whether the current future can delegate to the returned one, it's the same concept. As for "weird universes", it is typically only functional programming languages that guarantee TCO as part of their standard. Most programmers live in a world where they can't rely on their implementation to optimize tail-calls, which is to say they don't make unbounded recursive calls. If they do, they end up with an insidious form of non-portable code.
bjpbakker 9y ago
> Having to explain why this is a huge problem is one reason for why I feel that JavaScript's ecosystem is so broken This! Exactly this.