> > // async
I think that is very verbose, It will not be very helpful to someone who doesn't know galaxy well or even does know coroutines. ( is it a coroutine, is it a generator ? its both ! ) If your APIs return promises, you'll need to provide wrappers to transform > both ways between promises and callback-based APIs. Bruno, that is simply not true. If a library returns promises u can just use the promise. You will always need to write more code to convert a promise to a callback style function then to just *use* the promise. I'm using streamline which works directly with node.js callbacks. Streamline.js also provides "futures", also by using a special syntax. *!_* ( which is also noise imo ) So if you use both libs, you are using two different type of control flow libraries ( of which one is a pre-processor ) , that both allow you to create async encapsulations with special syntaxes, to workaround callbacks. I think I will just stick to promises. I can't help but feel that they are more uniform, cleaner and how ECMAScript is intending async control flow in the future. On 18 April 2014 13:55, Bruno Jouhier <[email protected]> wrote: > > > 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 a topic in the > Google Groups "nodejs" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/nodejs/NpZ4WT1eOnw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- 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.
