Please doc. the diff. bet.n `Stream<Value>` and distinct {`Iterable<Future<Value>>`(pull-based) ,hypothetical `Channel<Value>`/`Channel<Future<Value>>`(push-based)}

[atototenten]

title ,along with ,the following

• the latter kind-of makes the former obsolete ?
• what about the memory efficiency ?
• the computation cost ?

NOTE : Ignore the Syntax (cost in lines-of-code) ,or mention at last .

thanks

[lrhn]

I'd rather not suggest any connection between a Stream and an Iterable<Future>, or define what things are in terms of what they aren't. APIs should be documented in terms of what they do. For related things, it may be worth highlighting the differences, whether subtle or not.

Streams and iterables of futures are not really related. There are several functions that take an Iterable<Future> as argument, fx Future.wait, and they would not work with a stream.

An iterable is an abstraction over a collection, a number of values that all exist right now. If those values happen to be futures, it just means you have multiple futures right now.

A stream will yield events over time as they become available.

Performance is hard to say anything specific about, other than that asynchrony always comes with a cost. Going back to the event loop and triggering a new event takes more time than not doing that. Plus anything async also goes through zones, which is only a small overhead if you don't add slow callbacks to those zones, but still an overhead.

And iterables may be faster or slower than creating a list of the values, depending on what you do with the iterable.
If the first thing the code does is to convert it to a list, it'd have been faster to create it up front. If the iterable is iterated more than once, it'd likely have been faster to create a list. If the code only looks at the first three values of the iterable, no matter how long it is, it's going to be faster to not create a long list.
It's impossible to say anything general other than "don't do unnecessary work" and "use the right tool for the job".

Other than that, it depends much more on how you compute the stream/iterable values than delivering them.

There shouldn't be any job where Iterable<Future> and Stream are both good tools.

(I'll definitely not document existing classes relative to some hypothetical API from another language.)