3 ms·

His code is creating an infinite promise chain. Did the author really expect it would not eat all his memory and crash? If the author had written the same code

His code is creating an infinite promise chain. Did the author really expect it would not eat all his memory and crash? If the author had written the same code with callbacks, a stack overflow would have been thrown. So misunderstanding of promises (and/or async coding) is the problem here, not promises.

_nalply 9y ago
That's it. It's like a stack overflow. The code contains a function which calls itself via a Promise. There's no guard which will eventually terminate the recursion.
bad_user 9y ago
> His code is creating an infinite promise chain. Did the author really expect it would not eat all his memory and crash? Processing an infinite or really long promise chain is what ends up happening when you're working with streams and functional programming in general. Yes, I expected it to not leak memory, because sane implementations don't leak. One such implementation is Scala's Future [0], using an implementation trick which I then ported in Funfix.org, so it's definitely possible. > If the author had written the same code with callbacks, a stack overflow would have been thrown. That's not true. For one, asynchronous calls will not trigger stack overflows. And a callback approach won't leak heap memory either, because you don't have to return a value-wannabe to the caller, so you're not building a stack. > So misunderstanding of promises (and/or async coding) is the problem here, not promises. I'm involved in no less than 3 libraries [1] [2] [3] implementing Promise and Haskell IO alternatives in JavaScript and Scala, so I'm pretty sure that I understand promises by now :-) I'm also pretty fond of this article I wrote a while back, asynchrony being sort of a fetish of mine: https://alexn.org/blog/2017/01/30/asynchronous-programming-scala.html https://alexn.org/blog/2017/01/30/asynchronous-programming-s... [0] http://www.scala-lang.org/api/2.12.3/scala/concurrent/Future.html http://www.scala-lang.org/api/2.12.3/scala/concurrent/Future... [1] https://monix.io https://monix.io [2] https://github.com/typelevel/cats-effect https://github.com/typelevel/cats-effect [3] https://funfix.org https://funfix.org
- weddpros 9y ago
  My bad, I was probably a bit aggressive and didn't read through. Thank you for correcting a few points. However, I'm still convinced that calling Promises "memory unsafe" is largely incorrect: - if it wasn't for the setImmediate, I insist the callback version would cause a stack overflow - you can't create an infinite number of objects (promises in this case) linked to each other without expecting a memory overflow. If it works in the Future example, it means the Futures are somehow not connected to each other, which must violate the contract for Promises. Can a Future object be resolved/flatMapped more than once without rerunning, ie. does it cache its value? I suspect this is the difference between a Promise and a Future... - "You can't have infinite loops with Promises" would make a better title I'm sorry, however, for trolling. Cheers

_nalply 9y ago

That's it. It's like a stack overflow. The code contains a function which calls itself via a Promise. There's no guard which will eventually terminate the recursion.

bad_user 9y ago

> His code is creating an infinite promise chain. Did the author really expect it would not eat all his memory and crash? Processing an infinite or really long promise chain is what ends up happening when you're working with streams and functional programming in general. Yes, I expected it to not leak memory, because sane implementations don't leak. One such implementation is Scala's Future [0], using an implementation trick which I then ported in Funfix.org, so it's definitely possible. > If the author had written the same code with callbacks, a stack overflow would have been thrown. That's not true. For one, asynchronous calls will not trigger stack overflows. And a callback approach won't leak heap memory either, because you don't have to return a value-wannabe to the caller, so you're not building a stack. > So misunderstanding of promises (and/or async coding) is the problem here, not promises. I'm involved in no less than 3 libraries [1] [2] [3] implementing Promise and Haskell IO alternatives in JavaScript and Scala, so I'm pretty sure that I understand promises by now :-) I'm also pretty fond of this article I wrote a while back, asynchrony being sort of a fetish of mine: https://alexn.org/blog/2017/01/30/asynchronous-programming-scala.html https://alexn.org/blog/2017/01/30/asynchronous-programming-s... [0] http://www.scala-lang.org/api/2.12.3/scala/concurrent/Future.html http://www.scala-lang.org/api/2.12.3/scala/concurrent/Future... [1] https://monix.io https://monix.io [2] https://github.com/typelevel/cats-effect https://github.com/typelevel/cats-effect [3] https://funfix.org https://funfix.org

weddpros 9y ago
My bad, I was probably a bit aggressive and didn't read through. Thank you for correcting a few points. However, I'm still convinced that calling Promises "memory unsafe" is largely incorrect: - if it wasn't for the setImmediate, I insist the callback version would cause a stack overflow - you can't create an infinite number of objects (promises in this case) linked to each other without expecting a memory overflow. If it works in the Future example, it means the Futures are somehow not connected to each other, which must violate the contract for Promises. Can a Future object be resolved/flatMapped more than once without rerunning, ie. does it cache its value? I suspect this is the difference between a Promise and a Future... - "You can't have infinite loops with Promises" would make a better title I'm sorry, however, for trolling. Cheers