3 ms·
Yeah I would be concerned about the Future/Stream dual in Dart, the dualism seems to currently be baked into the API in unfortunate ways - http://api.dartlang.o
by swannodette 13y ago
Yeah I would be concerned about the Future/Stream dual in Dart, the dualism seems to currently be baked into the API in unfortunate ways - http://api.dartlang.org/docs/releases/latest/dart_async/Stream.html http://api.dartlang.org/docs/releases/latest/dart_async/Stre...
- mraleph 13y agoWell, this dualism is used to communicate important distinction: single value vs. multiple values, so streams return futures in the places where it is absolutely meaningful to do so e.g. first element of a stream can be obviously viewed as a one element stream but it is also a Future because it is at most one value.
- munificent 13y agoI'm on the Dart team and spent time talking to the corelib team when Streams were first added. I had a proposal at the time to unify streams and futures. My contention was that a future was just a stream that only emits one value and then closes. Florian convinced me that that was trying to hard to jam them together. Instead, there's methods to convert from one to the other when you want: new Stream.fromFuture() Future<List> Stream.toList() Future.asStream() Asynchrony is still quite hard to work with compared to a language with coroutines and blocking, but the Future/Stream distinction doesn't seem to cause many problems in practice.
- swannodette 13y agoYes but I'd argue that your original intuition was probably correct - we don't have this distinction in core.async because we have channels and they can be used for both one offs and stream processing. Of course the reason to eliminate the distinction would be to simplify sugar over asynchronous code a la F#, C#, Scala and now core.async. mraleph seemed to suggest this is being considered for Dart.