On Friday, April 18, 2014 9:33:00 AM UTC+2, willem dhaeseleer wrote:
>
>
> What galaxy demonstrates is that generators are sufficient. You can do all 
> you want with generators, you don't need promises (or any other 
> abstraction) around them.
> In the node.js ecosystem "any other async function" is a function with a 
> callback, not a function that returns a promise.
>
>
> Claiming that promises ( or any other abstraction ) or not required seems 
> false to me. Here is an example from galaxy's readme:
>
> function* projectLineCountsParallel() {
>     var *future1 *= galaxy.spin(countLines(__dirname + '/../examples'));
>     var *future2 *= galaxy.spin(countLines(__dirname + '/../lib'));
>     var *future3 *= galaxy.spin(countLines(__dirname + '/../test'));
>     var total = (yield future1()) + (yield future2()) + (yield future3());
>     console.log('TOTAL: ' + total);
>     return total; }
>
>
> These *future*'s that galaxy uses are in fact abstractions around an 
> asynchronous process, just like promises. 
> The only difference being that they are only useful inside galaxy and they 
> do not conform to a standard, and they require you to use a special wrapper 
> function (spin).
>

Not quite: these futures are no abstractions, they are just generator 
functions aka function*! 

A galaxy API does not expose idiosyncratic types/abstractions, it exposes 
"standard" types defined by the JS language. For example galaxy.spin 
transforms a generator object (returned by a call to a function*) into a 
generator function (a function*) on which you can yield later to get a 
result.


> It doesn't seem like a good idea to me that you would have to rewrite the 
> way you call a function in order to affect parallelism.
> With promises you ether yield, or don't, and keep the promises for 
> reference. No need for a special spin function.
> ( The requirement to call a future when yielding it seems somewhat 
> cumbersome to.)
> This proves pretty clearly that you need *some *sort of an abstraction. 
>

Galaxy is rather a helper library that manipulates the abstractions that 
are already there in the language. 
 

>
> If you want an annotation, just add a comment.
>
>
> You can't really efficiently say in a comment that the generator is in 
> fact a coroutine that requires an invoke trough a specific library.
> A regular coroutine should be just a function, like any other async 
> operation should be. 
>

Yes you can: // async
 

>  
>

> Regarding performance, function wrappers are not always static...
>
>
> True, but let's not drag in actual performance in the discussion. We need 
> benchmarks to make any sort of point around them and I think the discussion 
> is more about api design then what V8 is capable of optimizing.
>
> It is the de facto standard in the node.js ecosystem. And it is more 
> efficient!
>
>
> de facto != de jure, that's my point, standardization is good, it allows 
> for a more stable ecosystem.
>

Yes. What do you prefer: a simple de facto standard, or a sophisticated de 
jure standard? I prefer the former. 


> The fact that you have to unstar a function that comes from galaxy if i 
> want to do an invocation from outside the library seems very uncanny.
> It's bad enough we have to wrap the core api's for coroutine management, 
> now we have to wrap functions from the library that tries to solve that as 
> well, It's only adding to the problem.
>

That's why I'm not using galaxy directly. I'm using streamline which works 
directly with node.js callbacks.

If your APIs return promises, you'll need to provide wrappers to transform 
both ways between promises and callback-based APIs. Same problem. Unless 
you manage to convince the whole node community to switch to promises. Good 
luck!

Bruno

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to