Hacker News Reader

Comment by sirclueless | Hacker News Reader

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.

View on HN

> 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.

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.

> 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.

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

In the case where you've got an incoming stream of real time events?

"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).

Reply on news.ycombinator.com