3 ms·

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

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

by rpedela 13y ago

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.