Raynos, I have a feeling that you are comparing apples and oranges. Streams are awesome, Promises are awesome but it's not the same, and not every use case can be addressed on equal level by both of them.
From my experience there can be promises that are also a streams, but among them are also promises that fulfill before stream ends. There can also be promises that are not streams, of course you may represent them as stream but if they bring no value and just emit 'end', it doesn't fit well stream concept, does it?
On Wed, Oct 3, 2012 at 1:11 AM, Mariusz Nowak <mari...@medikoo.com> wrote:
> Raynos, I have a feeling that you are comparing apples and oranges.
> Streams are awesome, Promises are awesome but it's not the same, and not
> every use case can be addressed on equal level by both of them.
> From my experience there can be promises that are also a streams, but
> among them are also promises that fulfill before stream ends. There can
> also be promises that are not streams, of course you may represent them as
> stream but if they bring no value and just emit 'end', it doesn't fit well
> stream concept, does it?
> Same way you can just use callbacks instead of promises, but the point is
> that promises gives you better abstraction, so it's easier to construct
> complicated flow with it and maintain it. See this:
> https://github.com/medikoo/deferred#promises-approach How would you write
> it with streams instead? Would it be more friendly than callbacks version:
> https://github.com/medikoo/deferred#plain-nodejs ?
> On Wednesday, October 3, 2012 6:40:02 AM UTC+2, Raynos wrote:
> On Wed, Oct 3, 2012 at 1:11 AM, Mariusz Nowak <mari...@medikoo.com> wrote:
>> Raynos, I have a feeling that you are comparing apples and oranges.
>> Streams are awesome, Promises are awesome but it's not the same, and not
>> every use case can be addressed on equal level by both of them.
>> From my experience there can be promises that are also a streams, but
>> among them are also promises that fulfill before stream ends. There can
>> also be promises that are not streams, of course you may represent them as
>> stream but if they bring no value and just emit 'end', it doesn't fit well
>> stream concept, does it?
>> Same way you can just use callbacks instead of promises, but the point is
>> that promises gives you better abstraction, so it's easier to construct
>> complicated flow with it and maintain it. See this:
>> https://github.com/medikoo/deferred#promises-approach How would you
>> write it with streams instead? Would it be more friendly than callbacks
>> version: https://github.com/medikoo/deferred#plain-nodejs ?
>> On Wednesday, October 3, 2012 6:40:02 AM UTC+2, Raynos wrote:
Raynos, Streams are very powerful and I agree with that, but as your examples shown you just cannot take asynchronous functions and configure them with streams directly, so they're not that helpful when dealing with asynchronicity that's not stream based.
You're point is not against promises but rather against typical asynchronous CPS. Question is whether you can (or whether it makes sense) to address all asynchronicity use cases with Streams, I doubt whether it make sense.
You made a one good point about writing to file while, having already some files ready, this is where indeed streams win, I was thinking about it recently. Currently in deferred implementation promise is an event-emitter, with 0.7 I want to push it forward so it can also be stream (both readable and writable). I've got use cases where it's beneficial to have promises that are also streams.
Anyway I find a lot of great stuff in your examples. Thanks for sharing that!
>> On Wed, Oct 3, 2012 at 1:11 AM, Mariusz Nowak <mar...@medikoo.com<javascript:> >> > wrote:
>>> Raynos, I have a feeling that you are comparing apples and oranges. >>> Streams are awesome, Promises are awesome but it's not the same, and not >>> every use case can be addressed on equal level by both of them.
>>> From my experience there can be promises that are also a streams, but >>> among them are also promises that fulfill before stream ends. There can >>> also be promises that are not streams, of course you may represent them as >>> stream but if they bring no value and just emit 'end', it doesn't fit well >>> stream concept, does it?
>>> Same way you can just use callbacks instead of promises, but the point >>> is that promises gives you better abstraction, so it's easier to construct >>> complicated flow with it and maintain it. See this: >>> https://github.com/medikoo/deferred#promises-approach How would you >>> write it with streams instead? Would it be more friendly than callbacks >>> version: https://github.com/medikoo/deferred#plain-nodejs ?
>>> On Wednesday, October 3, 2012 6:40:02 AM UTC+2, Raynos wrote:
promises only work if everything is a promise. Streams only work if
everything is a stream.
Making everything a stream is cool because streams represent the endless
flow of data through your entire program. It's basically doing reactive
programming.
Making everything a stream instead of a promise has the advantage of most
things in node core are already streams. Domains work cleanly with streams,
etc.
Oh and streams are composable! You write a stream I can use it with any of
my streams. You write a promise, I have to use promises everywhere or
ignore all your work.
On Wed, Oct 3, 2012 at 10:38 AM, Mariusz Nowak <mari...@medikoo.com> wrote:
> Raynos, Streams are very powerful and I agree with that, but as your
> examples shown you just cannot take asynchronous functions and configure
> them with streams directly, so they're not that helpful when dealing
> with asynchronicity that's not stream based.
> You're point is not against promises but rather against typical
> asynchronous CPS. Question is whether you can (or whether it makes sense)
> to address all asynchronicity use cases with Streams, I doubt whether it
> make sense.
> You made a one good point about writing to file while, having already some
> files ready, this is where indeed streams win, I was thinking about it
> recently. Currently in deferred implementation promise is an event-emitter,
> with 0.7 I want to push it forward so it can also be stream (both readable
> and writable). I've got use cases where it's beneficial to have promises
> that are also streams.
> Anyway I find a lot of great stuff in your examples. Thanks for sharing
> that!
> On Wednesday, October 3, 2012 7:11:18 PM UTC+2, Raynos wrote:
>> The other feature is that this is all in node core. Isaacs 0.9 streams
>> will have the notion of a transform stream.
>> We can also petition node core to make fs.createReadStream(dirname) work
>> because a directory is just a fd with a list of files so it should work.
>> Then the program becomes
>> ```
>> var fs = require("fs")
>> , d = require("domain").create()
>> , Transform = require("stream").Transform
>> d.run(function () {
>> var onlyJsFiles = new Transform()
>> , mapToFiles = new Transform()
>> , addNewLine = new Transform()
>>> On Wed, Oct 3, 2012 at 1:11 AM, Mariusz Nowak <mar...@medikoo.com>wrote:
>>>> Raynos, I have a feeling that you are comparing apples and oranges.
>>>> Streams are awesome, Promises are awesome but it's not the same, and not
>>>> every use case can be addressed on equal level by both of them.
>>>> From my experience there can be promises that are also a streams, but
>>>> among them are also promises that fulfill before stream ends. There can
>>>> also be promises that are not streams, of course you may represent them as
>>>> stream but if they bring no value and just emit 'end', it doesn't fit well
>>>> stream concept, does it?
