4 ms·

This purist evented I/O fundamentalism has to stop. While evented I/O is great for a certain class of problems: building network servers that move bits around

This purist evented I/O fundamentalism has to stop. While evented I/O is great for a certain class of problems: building network servers that move bits around in memory and across network pipes at both ends of a logic sandwich, it is a totally asinine way to write most logic. I'd rather deal with threading's POTENTIAL shared mutable state bullshit than have to write every single piece of code that interacts with anything outside of my process in async form. In node, you're only really saved from this if you don't have to talk to any other processes and you can keep all of your state in memory and never have to write it to disk. Further, threads are still needed to scale out across cores. What the hell do these people plan on doing when CPUs are 32 or 64 core? Don't say fork(), because until there are cross-process heaps for V8 (aka never), that only works for problems that fit well into the message-passing model.

benatkin 15y ago
redis is pretty badass for talking to other processes without really talking to other processes, and it's the #10 most depended-upon library on npm right now. http://search.npmjs.org/ http://search.npmjs.org/ It won't work for every problem, of course. dnode is a good way to easily talk to other node.js processes without the HTTP overhead. It can talk over HTTP too, with socket.io. node-http-proxy is useful as a load balancer, and a load balancer can distribute work between cores. Finally, most of the node.js people I've met, online and offline, are polyglots, and are happy to pick a good tool for a job. But right now node.js has great libraries for realtime apps, the ability to share code on the client and server in a simple way, and good UI DSLs like jade, less, and stylus.
- rbranson 15y ago
  Huh? how does any of this keep me from having to write callback spaghetti? If I send a call using redis or dnode or whatever, I have to wait for it, so that means a callback. I feel you about the polyglot and tend to agree, but I think some people are really trying to force awkward things into node, like people attempting to write big full-stack webapps using it.
  - benatkin 15y ago
    I didn't mention any of those libraries in my reply to your original comment. To help alleviate callback noise, there's https://github.com/caolan/kanso https://github.com/caolan/kanso , which Fenn mentions in his blog post's comments, and there are EventEmitters, and there is Function.bind() and Backbone.js-style async, where you have methods that describe what each callback does. (Backbone is usable in Node.js but perhaps not as practical on the server as it is on the client.) Also callbacks to me are kind of like parenthesis in Lisp. They're annoying but they're for the greater good. :)
    - UncleOxidant 15y ago
      "deal with it" is a good response. personally, I'd rather write callbacks than deal with threads any day. And there are plenty of approaches to make dealing with callbacks easier (async.js is one of many).
      - rbranson 15y ago
        Actually, "deal with it" is fucking lame, isn't a response at all, and is a good example of why I use the term "fundamentalism." Is your problem with threads or shared mutable state? Web applications should be stateless and can be written as long request-response pipelines on-top of a pool of actor threads, with the only shared state existing at either ends of the pipeline, probably hidden by a framework anyways.
        UncleOxidant 15y ago
        The "deal with it" is the same for threads - if you're using a system with threads you have to deal with them and it's generally not too fun. Node is what it is. It's callback based. I didn't mean the "deal with it" in a hostile way, more like that's the kind of system node is so deal with it. Is node great for every kind of problem? No. Definitely not. Actors are great too (and they've usually got threads in them, but they are well contained). But for certain kinds of apps node and the careful use of callbacks work out great. I guess I was trying to counter all of the hating on callbacks - they're not so awful when you get used to them.

benatkin 15y ago

redis is pretty badass for talking to other processes without really talking to other processes, and it's the #10 most depended-upon library on npm right now. http://search.npmjs.org/ http://search.npmjs.org/ It won't work for every problem, of course. dnode is a good way to easily talk to other node.js processes without the HTTP overhead. It can talk over HTTP too, with socket.io. node-http-proxy is useful as a load balancer, and a load balancer can distribute work between cores. Finally, most of the node.js people I've met, online and offline, are polyglots, and are happy to pick a good tool for a job. But right now node.js has great libraries for realtime apps, the ability to share code on the client and server in a simple way, and good UI DSLs like jade, less, and stylus.

rbranson 15y ago
Huh? how does any of this keep me from having to write callback spaghetti? If I send a call using redis or dnode or whatever, I have to wait for it, so that means a callback. I feel you about the polyglot and tend to agree, but I think some people are really trying to force awkward things into node, like people attempting to write big full-stack webapps using it.
- benatkin 15y ago
  I didn't mention any of those libraries in my reply to your original comment. To help alleviate callback noise, there's https://github.com/caolan/kanso https://github.com/caolan/kanso , which Fenn mentions in his blog post's comments, and there are EventEmitters, and there is Function.bind() and Backbone.js-style async, where you have methods that describe what each callback does. (Backbone is usable in Node.js but perhaps not as practical on the server as it is on the client.) Also callbacks to me are kind of like parenthesis in Lisp. They're annoying but they're for the greater good. :)
  - UncleOxidant 15y ago
    "deal with it" is a good response. personally, I'd rather write callbacks than deal with threads any day. And there are plenty of approaches to make dealing with callbacks easier (async.js is one of many).
    - rbranson 15y ago
      Actually, "deal with it" is fucking lame, isn't a response at all, and is a good example of why I use the term "fundamentalism." Is your problem with threads or shared mutable state? Web applications should be stateless and can be written as long request-response pipelines on-top of a pool of actor threads, with the only shared state existing at either ends of the pipeline, probably hidden by a framework anyways.
      - UncleOxidant 15y ago
        The "deal with it" is the same for threads - if you're using a system with threads you have to deal with them and it's generally not too fun. Node is what it is. It's callback based. I didn't mean the "deal with it" in a hostile way, more like that's the kind of system node is so deal with it. Is node great for every kind of problem? No. Definitely not. Actors are great too (and they've usually got threads in them, but they are well contained). But for certain kinds of apps node and the careful use of callbacks work out great. I guess I was trying to counter all of the hating on callbacks - they're not so awful when you get used to them.