5 ms·

What you think is node's strength is its weakness. Having to write event-driven code is terrible. Just as the world is finally waking up and moving to actuall

by asdasf 13y ago

What you think is node's strength is its weakness. Having to write event-driven code is terrible. Just as the world is finally waking up and moving to actually caring about concurrency like erlang and haskell have forever, node is a throwback to the error prone and convoluted event loops of C. Go is far better for the very use case you think node excels at.

rdtsc 13y ago
I agree and I could probably stomach it better if community centered around Node.js wouldn't be so arrogant. Arrogance to be tolerated needs to be backed up by technical knowledge. Linus Torvalds is arrogant and abrasive. I don't mind it as much because of his experience, knowledge and his contribution. Some guy yelling about how asynchronous callback programming is the best way to handle concurrency and is the way of the future is doing a disservice to whatever community he belong s to (well node.js in this case), it just deepens the negative stereotypes. Technology in itself is fairly neutral, tools that work for some use cases and don't work for others, trade-offs and so on. It is the people that use the tools that give those tools a bad wrap usually.
rpedela 13y ago
Like I said, only time will tell if Node.js is THE non-blocking scripting language/framework. Still too early in hype mode to know for sure. At the moment it is and it has the momentum. Doesn't mean Go won't take its place at some point in the future assuming it really is better at the non-blocking use case. Or Go could just be another language in a long line of languages that go nowhere. We shall see. No matter the mechanism, event-driven programming is here to stay. All UIs must be event-driven unless you enjoy pissing users off. Games must be event-driven. Web servers should usually be event-driven for similar reasons. Callbacks are just the most basic way to achieve that when you have an event that won't finish processing for awhile like a DB call. I certainly understand the desire to not use callbacks since I also loathe them. But they are also much easier to understand than something that looks synchronous but actually isn't. But there are a lot of people who have tried and are still trying now to rid us of the need for callbacks but still allow for async. I certainly hope they prevail, but, historically speaking, I am not optimistic.
- TheHydroImpulse 13y ago
  I don't know if Node will win for THE non-blocking platform award, but it's coming close to THE non-blocking web platform. I think Go (and heck even Clojure with it's added core.async model) would be better at winning the first award. They are much more general and can be used freely. Node is basically limited to web and web servers (including tcp servers here). I think Node is turning onto generator mode. Now that generators hit V8 (and Node under a flag), it's much easier to write async code (even easier than callbacks) yet you write in a synchronous style. That'll definitely improve the concurrency model.
- asdasf 13y ago
  You have a very fundamental misunderstanding that is making you create a distinction that doesn't actually exist. There is no "non-blocking use case". The use case is web development. You absolutely do not need to use event loops to write UIs, or anything else. You should never have to write event driven callback spaghetti, just like you should never have to write direct jumps (goto). Reasonable languages provide actual concurrency constructs, allowing you to write simple, easy to understand code, while providing all the benefits of both threads and event loops. Traditionally you needed to use a good language like haskell or erlang to get this, and that caused problems for people who want to stick with primitive languages. Now go has come along and offers similar benefits in a primitive package, so there is no need for people to have to stick with low level, error prone event loops.
TheHydroImpulse 13y ago
Definitely. The callback style is horrible as a concurrency model. Truly awful. Compare callbacks to goroutines and it's insane how awesome goroutines are. But, Node made it easier to write purely asynchronous code and using a language people were familiar with, that's why it became so popular. While Go is has an insanely good concurrency model, Node has it's quick iteration going for it and a large number of packages. Now that generators (coroutines) have made it into V8, the concurrency model of Node is changing, for the better. Node is still very much limited in application (thanks to JavaScript and the event loop.). Whereas Go can be used for a lot of different things. But Node specializes in web applications, in web servers. Thus, it's going to be more productive than a general purpose solution.

by asdasf 13y ago

rdtsc 13y ago

I agree and I could probably stomach it better if community centered around Node.js wouldn't be so arrogant. Arrogance to be tolerated needs to be backed up by technical knowledge. Linus Torvalds is arrogant and abrasive. I don't mind it as much because of his experience, knowledge and his contribution. Some guy yelling about how asynchronous callback programming is the best way to handle concurrency and is the way of the future is doing a disservice to whatever community he belong s to (well node.js in this case), it just deepens the negative stereotypes. Technology in itself is fairly neutral, tools that work for some use cases and don't work for others, trade-offs and so on. It is the people that use the tools that give those tools a bad wrap usually.

rpedela 13y ago

Like I said, only time will tell if Node.js is THE non-blocking scripting language/framework. Still too early in hype mode to know for sure. At the moment it is and it has the momentum. Doesn't mean Go won't take its place at some point in the future assuming it really is better at the non-blocking use case. Or Go could just be another language in a long line of languages that go nowhere. We shall see. No matter the mechanism, event-driven programming is here to stay. All UIs must be event-driven unless you enjoy pissing users off. Games must be event-driven. Web servers should usually be event-driven for similar reasons. Callbacks are just the most basic way to achieve that when you have an event that won't finish processing for awhile like a DB call. I certainly understand the desire to not use callbacks since I also loathe them. But they are also much easier to understand than something that looks synchronous but actually isn't. But there are a lot of people who have tried and are still trying now to rid us of the need for callbacks but still allow for async. I certainly hope they prevail, but, historically speaking, I am not optimistic.

TheHydroImpulse 13y ago
I don't know if Node will win for THE non-blocking platform award, but it's coming close to THE non-blocking web platform. I think Go (and heck even Clojure with it's added core.async model) would be better at winning the first award. They are much more general and can be used freely. Node is basically limited to web and web servers (including tcp servers here). I think Node is turning onto generator mode. Now that generators hit V8 (and Node under a flag), it's much easier to write async code (even easier than callbacks) yet you write in a synchronous style. That'll definitely improve the concurrency model.
asdasf 13y ago
You have a very fundamental misunderstanding that is making you create a distinction that doesn't actually exist. There is no "non-blocking use case". The use case is web development. You absolutely do not need to use event loops to write UIs, or anything else. You should never have to write event driven callback spaghetti, just like you should never have to write direct jumps (goto). Reasonable languages provide actual concurrency constructs, allowing you to write simple, easy to understand code, while providing all the benefits of both threads and event loops. Traditionally you needed to use a good language like haskell or erlang to get this, and that caused problems for people who want to stick with primitive languages. Now go has come along and offers similar benefits in a primitive package, so there is no need for people to have to stick with low level, error prone event loops.

TheHydroImpulse 13y ago

Definitely. The callback style is horrible as a concurrency model. Truly awful. Compare callbacks to goroutines and it's insane how awesome goroutines are. But, Node made it easier to write purely asynchronous code and using a language people were familiar with, that's why it became so popular. While Go is has an insanely good concurrency model, Node has it's quick iteration going for it and a large number of packages. Now that generators (coroutines) have made it into V8, the concurrency model of Node is changing, for the better. Node is still very much limited in application (thanks to JavaScript and the event loop.). Whereas Go can be used for a lot of different things. But Node specializes in web applications, in web servers. Thus, it's going to be more productive than a general purpose solution.