[spion]

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

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

[empthought]

That reinforces zsombor's point nicely.

[spion]

I was hoping it shows that it really depends on your style (procedural or functional). Thanks to generators and arrow functions, ES6 lets you write code using either.

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)  
  });

ES6 is a lot more powerful than it looks :)

[empthought]

This isn't a question of "my style" -- zsombor's notation is objectively better. It achieves the same results with fewer tokens and less intellectual overhead.

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(){}`...

[spion]

Whoops, yes I mean "arrow function syntax", not arrows.

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

[empthought]

Those aren't go routines, there's a yield sitting right there. And there's yield/return in your second example, and there's the equivalent in the promises example.

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.

[spion]

True. Though I suppose that writing an async generator runner that utilizes multiple workers (e.g. via webworkers in browser, via isolates in node - if they ever happen) is also possibly doable at some time in the future. Those generators wont have any access to the current scope, but that might be better[1]

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...

[zsombor]

As of Go 1.2 (released a few weeks ago) goroutines are preempted. Sure currently this only happens in the presence of function calls, but it is hard to create a non preemptible infinite loop without function calls by accident.