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.
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".
{ "value" : ..., "next" : new Promise(...) }
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.
Why would a stream of promises be pull-based? That seems like a pretty odd assumption to me.
the bizarre meme is that they are 'replacements' for promises, they are really intended for (as you rightly put it) push streams which is a different, though occasionally overlapping, use case then promises.
Otherwise, its like using Arrays or Lists instead of Maybe. Hope that clears up why its "bizarre", but if not, its because the contract is not restrictive enough.
Example: `let x:Observable<Row[]>`. Does this generate a single event with all the rows? Or does it do row batching? No idea. Can I consume both the same? Not really, depends on the use. e.g. if I want to sort the items, I'd have to implement merge sort for the second case.
Given any Observable `obs`, you can consume it with `obs.take(1).subscribe()` instead of `obs.subscribe()` and then you'll be sure it only generates one value per subscription.
But in practice the generation of multiple values in itself is rarely an issue to worry about. Often you just want to drop consecutive duplicates, there's an operator for that: `distinctUntilChanged`. You can also end an observable based on a timeout.
Multiple values emitted is a pseudo-problem, and often your programming becomes more powerful ("does more in less lines of code") by using that capability.
Observables are just an API for any push system based on callbacks, to make it composable and lazy. Array.forEach uses callbacks, Promise.then uses callbacks, Node.js streams are consumed using callbacks. And observables can model those cases without losing their properties (e.g. Array.forEach is called synchronously).