credentials := NewCredentials(token)
   User.findByName(credentials.userName)   

  var withThis = (object, f) => function bound() {
    return f.apply(object, arguments);
  }

  function getCredentialsByToken(token) {
    return newCredentials(token)
    .then(withThis(User, User.findByName));
  }

When you're writing in functional style, you'd use arrows, which work nicely both for small lambdas and for writing combinators that can be partially applied. When you're writing in a more procedural style, generators are your "do syntax" equivalent(-ish):

  async(function* getCredentialsByToken(token) {
    credentials = yield NewCredentials(token)
    return User.findByName(credentials.userName)  
  });

The difference between "functional" and "procedural" style here is nothing more than monadic bind operator vs do-notation, but what you have above or in the initial response is nothing like that.

Also I'm not sure "arrows" -- http://www.haskell.org/haskellwiki/Arrow -- means what you think it means in the context of functional programming? It's not sugar for `function(){}`...

As for style, using combinators is usually considered to be specific to functional programming, right?

IMO the interesting part is how the terse arrow function syntax in ES6 puts combinators on the same level of expressiveness as everything else. Contrast to ES5 you have to use the awkward `return function() {}` syntax, and you have to do something similar in go - `return func (param type) type { ... }`

Both styles are now almost equally terse and you can pick either depending whether you feel its more appropriate in the given situation.

Also: https://gist.github.com/Gozala/7242467

This isn't a terseness issue; it's an error issue. Favoring yield/return and equivalents over sequential code in CSP is exactly the same as favoring goto over while, or goto over exceptions. Necessary sometimes? Yes. Something to be celebrated and preferred? No.

The trouble is, of course, that in Javascript runtimes the "yield" or equivalent is how scheduling is achieved, because there is no capacity for preemption.

Thus, Node.js returns us to the bad old days of Windows 3.1 and System 6, where one faulty bit of code grinds the entire system to a halt.

Edit: Go goroutines of course also have a cooperative scheduler currently, but at least the result of having it isn't baked into the idioms and language constructs.

Still, scheduling would continue to be cooperative via yield (just split amongst multiple threads). Go is clearly much further ahead in that regard :D

[1]: https://groups.google.com/forum/#!topic/golang-nuts/hZjvk-EP...

note: I'm curious, doesn't shared state from those closures let you shoot yourself in the foot in Go? You still have to be careful not to use anything not thread-safe that can potentially change...

This isn't a new thihg anyway, there are currently a lot of implementations, I even wrote one myself[1].

By the way, most (sane) libraries that use yield/await perfom a lot better, than vanilla promises. Because when you do .then() on already resolved promise you have to wait for the next tick, or setImmediate or whatewer. Yield-based implementations can continue right away in this case.

[1]: https://github.com/omgtehlion/asjs

Actually I learned to embrace next-tickness of promises in Q because I don't have to think twice about different possible execution order depending on promise's current state.

I would honestly prefer immediate continuation to be opt-in. This worked well in .NET (its Task's ContinueWith has a flag called TaskContinuationOptions.ExecuteSynchronously that tells the scheduler “you can run me right away if you like”).

    var x;

    promise().then(function (result) {
      x = result;
    }).done();

    x.doStuff();

A more real-world example is synchronization code like this[1]. Can you say at a glance if this code works fine both with resolved and pending promises? You'd have to check every `then`. You don't get this kind of problem with always-asynchronous promises.

In other words, it's a tradeoff between performance and introducing possibility of several different code paths, and it gets messier with non-trivial code.

  [1]: https://gist.github.com/gaearon/7930162

The requirement is to always calls handlers with an empty stack and in a certain order. In practice only naivest implementations would call platform scheduler for every `.then()`. Implementations can in all cases call the handlers synchronously when it would matter.

http://promises-aplus.github.io/promises-spec/#notes (emphasis mine)

So my point is that even if the spec might say that "Do A, then B and then C", that's not what an implementation has to do EXACTLY as long as the outcome is exactly the same in both cases.

For example a property load is a hugely complex operation in the ECMAScript spec that would take thousands of instructions to implement naively. In practice e.g. V8 will in many cases get away literally with one machine instruction in best case. None of the specified property load steps are obviously happening but yet somehow V8 is spec compliant.

The hardest stuff in JS is that :

    function F(){throw "error"}

   try{setTimeout(F,1000)}catch(error){ console.log("error")}

You can catch async errors with generators and promises; see e.g. the linked post, or http://jlongster.com/A-Study-on-Solving-Callbacks-with-JavaS...

You can inject an exception into a generator via the throw method[0], and it'll be raised at the yield, as if `yield` had thrown[1].

JS exception handling facilities are still crap, though.

[0] http://wiki.ecmascript.org/doku.php?id=harmony:generators#me...

[1] http://wiki.ecmascript.org/doku.php?id=harmony:generators#in...

I think you can catch async errors if you call the throw method on the generator.

http://wiki.ecmascript.org/doku.php?id=harmony:generators#me...

  var just = property => object => {
    var o = {}; 
    o[property] = object[property]; 
    return o;
  }

  Credentials.get({token})
    .then(just('username'))
    .then(withThis(User, User.get));

    #Without generators
    Credentials.get({ token })
        .then(credentials => User.get({ username: credentials.username }))

    #With generators

    var credentials = 
        yield Credentials.get({ token })
            User.get({ username: credentials.username })

1. You write code almost like synchronous one. You can use any control-flow statements you are familiar with. Just dont forget to turn a promise into real value with `yield` keyword.

2. How much times have you wrote such statements?

    X.prototype.foo = function() {
        var self = this;
        // or
        var that = this;
        this.bar().then(function(x) {
            that.baz(x);
        });
    };

With yield you can just write your logic, not a boilerplate:

    X.prototype.foo = async(function*() {
        var x = yield this.bar();
        this.baz();
    });

    var a = yield A();
    var b = yield B();

    var a = A();
    var b = B();
    a = yield a;
    b = yield b;

2. Why did you stop using arrow functions?

    X.prototype.foo = function() {
        this.bar().then(x => this.baz(x));
    };

Even more, with yield you can easily achieve parallel execution just moving `yield` keyword to the place where you need actual value. Good luck doing this with promises.

2. Unfortunately, traceur-compiler does not support fat arrow yet;

3. If you use try-catch just as a silencer, man I have bad news for you. And if you provide real error-handling in `.fail()` then what’s the problem writing the same code inside catch clause?

There is just no way to use yield without it either being superfluous or sacrificing concurrency. Of course it is great when you have a sequence I guess, but promise code with arrows is not messy in comparison, maybe slightly more verbose at best.

Consider something like this which is far from optimal:

    let suspend = require('suspend'),
        request = require('request');

    let getParsed = suspend(function* (urls) {
        urls.forEach((url) => request(url, suspend.fork()));
        return (yield suspend.join()).map((r) => parseBody(r.body));
    });

Maximizing concurrency:

    let getParsed = Promise.coroutine(function* (urls) {
        return yield urls.map((url) => {
            request(url).spread((response, body) => parseBody(body));
        });
    });

    let getParsed = urls =>
        urls.map((url) => {
            request(url).spread((response, body) => parseBody(body));
        });
    });

Since promise `.catch()` is not limited by the language, you can do e.g. `.catch(NetworkError, e => ());` or whatever.

    try {
      var user = yield Users.get(1234);
      return user.name;
    } catch(ex) {
      // do whatever
    }

    return Users.get(1234).then(
      function (u) { return u.name; },
      function (ex) { /* do whatever */ }
    );

  Users.get(1234)
    .then(u => u.name)
    .catch(ex => 1/* do whatever */);