[zsombor]

Whilst thanks to lack of choice JavaScript is so important on the browser side, I would hope the Node infatuation would eventually pass where you do have a choice. Async calls in Node are done via explicit passing of closures. Callbacks, Promises etc all look bad compared to simple sequential instructions like:

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

The above is in Go, and it is just as fast if not more. Whilst all requests are on their own goroutines, the runtime will schedule them using the same efficient async io that does not need to be made visible as in JavaScript.

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