6 ms·
"While we all know and love JavaScript as a language ..." I know it but I don't love it. It's basically the only game in town when it comes to client side scri
by nas 15y ago
"While we all know and love JavaScript as a language ..."
I know it but I don't love it. It's basically the only game in town when it comes to client side scripting.
Also, the concurrency model of Node.js does not eliminate concurrency related bugs. It's entirely possible to have race conditions, for example, with single threaded code that uses asynchronous callbacks. I guess a lot of people don't realize that. A real solution is no shared state, like Erlang or Clojure.
My gut feeling is that the Node.js library model (no call is blocking) is eventually going to lead to a mess. As I understand it, any API that can potentially block has to take a callback function. What happens when you realize some API that used to not block now may block (due to some increased functionally, platform changes, etc)? Any code that uses that API, and worse, any non blocking API that uses that API, now has to grow a callback too.
It can be done. The Twisted library has done a similar thing for years already. I just don't think it's a very good model for a general purpose server side language.
All that said, Node.js will probably be successful. The fact that browsers are not entirely broken WRT DOM and Javascript means that there is going to be ever increasing amounts of Javascript code around. It makes sense to re-use that development effort on the server side.
- democracy 15y agoJava shops could use javascript via jdk6 for 7 years now, however no popular frameworks or libraries for the backend emerged. And it is a javascript which is embedded and basically could be promoted as a 'simpler and faster (development-wise) java' but never happened.
- randall 15y agoI think your assumption about no call blocking libs leading to a mess is under the assumption that people see a need for a blocking lib with Node. The assumption by default is that every call is async. Even calls which happen instantly sometimes offer a callback pattern because that's what people who use node often expect. I can't personally envision a situation where an NPM module would update to change a call to blocking spontaneously. This is the reason why we're using Node in the first place. Non-blocking is the default. The community assumes and expects non-blocking calls by default.
- peterhunt 15y agoI find it very easy to imagine myself writing some code that assumes a function doesn't need to do I/O, and then lo and behold the spec changes and we have to refactor the entire call stack of anything that assumes it's nonblocking.
- tlb 15y agoI haven't had much difficulty avoiding such cases. It can come up if you have a simple fixed function that returns its value, but later decide to make it customizable through the database. When that happens, it's not very hard to make the callers use a callback.
- artsrc 15y agoSome changes are breaking changes. If a call requires new parameters and there are no sensible defaults then clients have to change to supply those parameters. I am sure this will be misunderstood but anyway... The initial Java world made IO exceptions checked exceptions, this implied that the addition of IO was a breaking change in that model also.
- artsrc 15y agoVisible variables are not changed by other threads during serial execution in either node or Erlang. But races in node can arise in terms of values changing unpredictably while before a callback is executed in node. In Erlang values can change when a process responds to another message, before processing a particular message. This seems like a race too. In either case the races are better contained in either node or Erlang than they are in more liberal models like the java or .net ones.