There is no performance reason to make developers hand-code in the continuation-passing style.
node certainly recognizes this. However, there is no need to do anything here since JS is taking care of this with ES6. Even if you don't want to use ES6, there are now multiple ways to compile it down to ES5.
Hence the slowly rising mindshare of Promises
Promises are declining, and honestly doesn't really solve the problem in most cases. A couple of years from now, you won't see promises on the server. You should see tjholowaychuk/visionmedia's co[1]; that's how JS is going to look like in future.
In terms of expressiveness, there isn't much to choose between dynamic languages. While it took some getting used to, programming JS wasn't that different from writing Python. However, JS/node is succeeding because this is the first time ever that we have a language/platform that is truly write-once, run-anywhere. A significant advantage in favor of node.
Yes, I'm looking forward to ES6. And I agree that Node's strength is that Javascript is truly the lingua franca of the modern web, which I why I would even bother using it.
But the value of running everywhere is also why ES6 is not a panacea. As you say, soon we won't need promises "on the server". But I want my codebase to run correctly everywhere. Promises are a bandaid that I'll need for quite a while yet.
Something silly is like putting shit-tons of fish into a box and expecting it to make HTTP requests. Writing a web server in PHP, regardless of what you think of the language, isn't. Comments like that are just gonna clutter someone's Google search one day.
If all you have is a room full of PHP developers and all you need is a REST site, then well you could do worse but I would like to discourage you from the practice.
Similarly, unless you have a highly specialized need - fun asynch chat server or complex app where business logic is being directly shared between client and server - I too would discourage locking one's self into that platform.
Javascript is not the worst thing ever, but why bother if you don't have to?
1) Laravel is a fantastic choice for building web servers if your team is primarily PHP. 2) There is no such thing as locking yourself into the JS platform, because JS has the advantage of being our lingua francua, is a general purpose programming language (servers, clients, and more!) AND is the language with the most momentum TODAY. Not last year, not 20 years ago.
Promises are declining, and honestly doesn't really solve the problem in most cases. A couple of years from now, you won't see promises on the server. You should see tjholowaychuk/visionmedia's co[1]; that's how JS is going to look like in future.
I'm impressed that you apparently completely failed to realise co is an abstractive layer over promises, something it states upfront:
Generator based flow-control goodness for nodejs (and soon the browser), using thunks or promises
What you yield from your generator is not magical pixie dusts, it's promises.
The generator is the driver, but the driver on its own its useless if it's got nothing to drive.
And what it has to drive is promises (or thunks since most existing node code is thunks-based I guess it makes sense to support that. taskjs uses promises more or less exclusively for the same purpose, Python 3.4's asyncio uses behaving much like JS promises, etc...)
Typically in apps using 'co', functions will return generators, not promises. Promises were probably added because of all the existing code out there.
Again, generators in and of themselves don't do anything (for async code). Something needs to be generated/yielded, and that thing is the reification of an asynchronous operation. Such as a promise[0]. Generators and promises fulfil different roles, generators are used as imperative "sugar" for chaining promises.
The generators you yield will ultimately resolve into a series of async operations (promises or "thunks"), yielding a generator is convenience (not very useful convenience either, since `yield*` exists the ability to yield generators just complexifies the driver)
[0] and in the case of co a "thunk"[1], because node
You can also use plain functions, objects, array, and even other generators too. Least, that's what the framework tells me when I fuck up my tests. It's not just all promises under the hood.
Comments
There is no performance reason to make developers hand-code in the continuation-passing style.
node certainly recognizes this. However, there is no need to do anything here since JS is taking care of this with ES6. Even if you don't want to use ES6, there are now multiple ways to compile it down to ES5.
Hence the slowly rising mindshare of Promises
Promises are declining, and honestly doesn't really solve the problem in most cases. A couple of years from now, you won't see promises on the server. You should see tjholowaychuk/visionmedia's co[1]; that's how JS is going to look like in future.
In terms of expressiveness, there isn't much to choose between dynamic languages. While it took some getting used to, programming JS wasn't that different from writing Python. However, JS/node is succeeding because this is the first time ever that we have a language/platform that is truly write-once, run-anywhere. A significant advantage in favor of node.
[1] https://github.com/visionmedia/co
Yes, I'm looking forward to ES6. And I agree that Node's strength is that Javascript is truly the lingua franca of the modern web, which I why I would even bother using it.
But the value of running everywhere is also why ES6 is not a panacea. As you say, soon we won't need promises "on the server". But I want my codebase to run correctly everywhere. Promises are a bandaid that I'll need for quite a while yet.
If you're not shipping your js code to the browser, then it's frankly kinda silly to write it on the server.
No one pay attention to this dude. Of course it isn't silly. Plenty of people build their servers with JS and put them into production.
Plenty of people build their servers with PHP and put them into production. It is still germane to ask if this is silly.
for LANG in Java Scala Ruby Python C C++ Groovy Clojure; do s/PHP/$LANG/; done
Something silly is like putting shit-tons of fish into a box and expecting it to make HTTP requests. Writing a web server in PHP, regardless of what you think of the language, isn't. Comments like that are just gonna clutter someone's Google search one day.
"Right tool for the right job".
If all you have is a room full of PHP developers and all you need is a REST site, then well you could do worse but I would like to discourage you from the practice.
Similarly, unless you have a highly specialized need - fun asynch chat server or complex app where business logic is being directly shared between client and server - I too would discourage locking one's self into that platform.
Javascript is not the worst thing ever, but why bother if you don't have to?
1) Laravel is a fantastic choice for building web servers if your team is primarily PHP. 2) There is no such thing as locking yourself into the JS platform, because JS has the advantage of being our lingua francua, is a general purpose programming language (servers, clients, and more!) AND is the language with the most momentum TODAY. Not last year, not 20 years ago.
Dont you mean you won't see standalone Promises, and instead Promises + Generators?
The linked page doesn't really convince me.
What do we get using this new shiny instead of the older shiny bluebird or the old shiny Q?
I'm impressed that you apparently completely failed to realise co is an abstractive layer over promises, something it states upfront:
What you yield from your generator is not magical pixie dusts, it's promises.
Actually, it's not promises. It's generators.
co thunkifies promises: https://github.com/visionmedia/co/blob/master/index.js#L209-...
The generator is the driver, but the driver on its own its useless if it's got nothing to drive.
And what it has to drive is promises (or thunks since most existing node code is thunks-based I guess it makes sense to support that. taskjs uses promises more or less exclusively for the same purpose, Python 3.4's asyncio uses behaving much like JS promises, etc...)
Seems you have misunderstood how it works. https://github.com/visionmedia/co/blob/master/index.js
Typically in apps using 'co', functions will return generators, not promises. Promises were probably added because of all the existing code out there.
Here is a file from my ongoing project, should explain how generators are being used. See getPosts() or addPost() https://github.com/jeswin/fora/blob/master/server/src/models...
[Edit: Just read your earlier (Gr.GP) comment. Might want to avoid the unnecessary snark, especially when there's a chance you might be wrong.]
No.
Again, generators in and of themselves don't do anything (for async code). Something needs to be generated/yielded, and that thing is the reification of an asynchronous operation. Such as a promise[0]. Generators and promises fulfil different roles, generators are used as imperative "sugar" for chaining promises.
The generators you yield will ultimately resolve into a series of async operations (promises or "thunks"), yielding a generator is convenience (not very useful convenience either, since `yield*` exists the ability to yield generators just complexifies the driver)
[0] and in the case of co a "thunk"[1], because node
You can also use plain functions, objects, array, and even other generators too. Least, that's what the framework tells me when I fuck up my tests. It's not just all promises under the hood.