[karterk]

You may see some very nice libraries/tools coming out around node.js, like jade, coffeescript, and stylus. These are all nice and good, and they do increase your productivity, but, only on the client side.

I disagree. Firstly, CoffeScript is not confined to the client-side. Besides, there are some modules like socket.io for which you will hardly find any substitues in other eco-systems.

You're also discounting the effects of context shifts between two separate languages - one on the client side, and the other on the server side.

Lastly, I would like to know what you find productive about Go, that's not the case with either CS/JS on Node.

[Animus7]

> The decrease in productivity with node comes from having to write everything with callbacks. Programming asynchronously is crazy, it makes very simple algorithms very annoying to write.

I know exactly what you mean, because that's what I thought a year ago. I was going on and on about this to everyone. Mea culpa.

Then I actually tried node and learned the functional side of JavaScript (I don't mean the semantics, which are very simple; I mean powerful LISPish design patterns). Now I don't think about callbacks anymore, because I have a functional toolkit that mostly hides them.

You say asynchronous coding makes simple algorithms annoying to write. So let's have an example. Read two files -- in parallel -- trap I/O errors and warn about them, otherwise merge and sort the files by line, write the result to a third file, and warn about I/O errors there as well. Simple enough?

My solution is 8 lines, formatted. It was very pleasant to write.

  fork(
    ['lines.txt', 'lines2.txt'].map(function(name) {
      return fs.readFile.bind(fs, name);
    }),
    check(console.warn.bind(console), function(a) {
      fs.writeFile('linesOut.txt', a.sum().split('\n').sort().join('\n'), check(console.warn.bind(console)));
    })
  )

If you've seen enough JS to deduce what the lib definitions for fork() and check() might be, then this code will seem obvious -- almost trivial. Otherwise, you will probably claim shenanigans or 'spaghetti' because it doesn't look like insert favorite programming language/framework here.

So it saddens me to hear people whining about this aspect of node -- partly because it recalls my own naivety, and partly because I know from experience that they're missing out on something great.

[ericflo]

So your point is that it's hard until you spend a year working with callback-based JavaScript, and then it becomes easy and intuitive? A year of investment may as well be an eternity for most.

[karterk]

To be fair, the OP did not exactly say that it took 1 year to learn it. I personally took less than a few days. Every framework has a learning curve.

[downx3]

That's good to know though. As it's pretty easy to waste a year learning framework X.

[hasenj]

The decrease in productivity with node comes from having to write everything with callbacks. Programming asynchronously is crazy, it makes very simple algorithms very annoying to write.

I'd say it's almost like writing in assembly. You have to write your code in some pseudo code first, synchronously, then translate that into the asynchronous callback spaghetti than node requires.

> Lastly, I would like to know what you find productive about Go, that's not the case with either CS/JS on Node.

Not having to write everything asynchronously?

I haven't actually used go, but the way goroutines communicate (and synchronize) with channels suggests to me (from what I've read/seen) that this callback spaghetti problem is non-existent in Go.

[bobz]

> I'd say it's almost like writing in assembly. You have to write your code in some pseudo code first, synchronously, then translate that into the asynchronous callback spaghetti than node requires.

This is a sign of a not-fully-adopted paradigm shift. Like, when someone first learns a new (spoken) language, they translate it to their native language in their head.

Fluent speakers don't translate, they simply understand. Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural.

That said, it does take some getting used to, which is a real cost that needs to be considered when choosing Node.

[irtopiste]

> Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural.

A minor remark from my experience with functional programming, continuation-passing style is actually something I prefer to avoid.

[wickedchicken]

> Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural.

I don't understand this comment. Javascript, while having first-class functions, does not have call/cc. This is the source of complaints that Javascript encourages callback-spaghetti. As people have mentioned elsewhere, continuation-passing style is meant for compilers, not humans.

[hasenj]

Thanks! I couldn't have phrased it any better.

This is why I said it's like writing assembly.

[guelo]

It cracks me up that you haven't tried Go but you're still recommending it, is there a web framework?

Edit: Found web.go. Screw it it's a long weekend, I'll give learning Go a go.

[chrisbroadfoot]

You don't really need a web framework with go. net/http is just fine for most use cases.

[hasenj]

I haven't had a pressing need for using it, and I'm considering it as something I want to learn on the side for now.

As for frameworks, it seems the http package comes builtin with a server and a url router. Also, Google's AppEngine supports Go.

[Jare]

web.go is still not compliant with the recently released Go1. I'd recommend anyone interested in Go but not in a hurry to wait a month or two until the Go1 dust settles.