Re:Cancelable Promises: Why was this proposal withdrawn?
by staltz on Monday December 19, 2016 @09:55AM
(#13211733)
flatMap isn't memory safe but switchMap is, and it's often used for the type of request/response chaining that we do with Promise.then.
With pratical experience using Observables in production for any use case people normally use Promises, I disagree with you about not being a substitute, and specially about being "broken".
Re:Cancelable Promises: Why was this proposal withdrawn?
by naasking on Monday December 19, 2016 @10:17AM
(#13211887)
From the FRP literature, an observable can be viewed as a stream of promises, something like:
{ "value" : ..., "next" : new Promise(...) }
Re:Cancelable Promises: Why was this proposal withdrawn?
by bad_user on Monday December 19, 2016 @02:49PM
(#13214444)
An observable is definitely not a stream of promises, because an observable is push-based, while a stream of promises would be pull-based.
Big difference in performance, implementation and what operations are possible or not. Even if you add back-pressure in that protocol, it's still a big difference.
And yes, my point is that an observable is close to being a sort of superset of a promise, but not close enough.
Re:Cancelable Promises: Why was this proposal withdrawn?
by naasking on Monday December 19, 2016 @04:36PM
(#13215179)
> An observable is definitely not a stream of promises, because an observable is push-based, while a stream of promises would be pull-based.
Why would a stream of promises be pull-based? That seems like a pretty odd assumption to me.
The fact of the matter is Observables get used for different use-cases than Promises. And for the use-cases for which Promises end up being used Observables are broken.
For example Observable's flatMap operation is most likely not memory safe and so it cannot be used in a "tail recursion". This is because we have to wait on the "onComplete" event in order for resources to be de-allocated and that cannot happen before the last Observable emitted by the last "onNext" signals its own "onComplete". But tail-recursion is a primary use-case for a Promise type and so its "flatMap" needs to be memory safe.
I've thought long and hard about it btw, I even have a library that implements both a lazy Task abstraction and the Observable pattern: https://monix.io
I love observables obviously, but Observable isn't a substitute for a Promise and I hope we don't go down that road.