3 ms·

You've missed my point. I'm not advocating that you don't do it at all. I'm saying... Why do it this way?

stcredzero 16y ago
Node is an evented, web-and-net-savvy I/O stack Python has issues dealing with I/O due to the GIL. (Here come the downvotes) Node.js also has the benefit of cutting-edge VM development, an area where Python is catching up. Combine this with the prospect of having the same language on the client and server, and the whole package sounds quite attractive.
- FooBarWidget 16y ago
  Python has issues dealing with multiple cores due to the GIL, not I/O. Global Interpreter Locked threading like Python's and Ruby's can deal with I/O concurrency just fine: they context switch upon encountering a blocking I/O operation. In the end Python and Ruby can only handle I/O on a single core but the same is true for Node.js whose evented model makes it inherent single-threaded. This is easily solved by setting up multiple processes, one process per CPU core, with each process possibly handling many I/O operations concurrently. I'm still baffled by the amount of misinformation about I/O concurrency.
  - stcredzero 16y ago
    You can write a program in Python that does I/O, and leaving it unmodified benchmark it running 10's of thousands of times slower on a dual core machine than on a comparably equipped single core machine. Can you do this with Ruby, Smalltalk, Lisp, or Lua? Specifically, it's the GIL that's involved.
    - FooBarWidget 16y ago
      Yes you can. But that's not an I/O problem, that's a problem in their GIL locking/unlocking/context switching implementation. Even when doing pure CPU computation in Python you run into the same problem. There was a presentation about this a while ago which explains the problem in detail. However the problem is not inherent to all GIL systems. Ruby 1.9 also has a GIL but does not suffer from the problem of running slower on dual core than single core.

Node is an evented, web-and-net-savvy I/O stack Python has issues dealing with I/O due to the GIL. (Here come the downvotes) Node.js also has the benefit of cutting-edge VM development, an area where Python is catching up. Combine this with the prospect of having the same language on the client and server, and the whole package sounds quite attractive.

FooBarWidget 16y ago
Python has issues dealing with multiple cores due to the GIL, not I/O. Global Interpreter Locked threading like Python's and Ruby's can deal with I/O concurrency just fine: they context switch upon encountering a blocking I/O operation. In the end Python and Ruby can only handle I/O on a single core but the same is true for Node.js whose evented model makes it inherent single-threaded. This is easily solved by setting up multiple processes, one process per CPU core, with each process possibly handling many I/O operations concurrently. I'm still baffled by the amount of misinformation about I/O concurrency.
- stcredzero 16y ago
  You can write a program in Python that does I/O, and leaving it unmodified benchmark it running 10's of thousands of times slower on a dual core machine than on a comparably equipped single core machine. Can you do this with Ruby, Smalltalk, Lisp, or Lua? Specifically, it's the GIL that's involved.
  - FooBarWidget 16y ago
    Yes you can. But that's not an I/O problem, that's a problem in their GIL locking/unlocking/context switching implementation. Even when doing pure CPU computation in Python you run into the same problem. There was a presentation about this a while ago which explains the problem in detail. However the problem is not inherent to all GIL systems. Ruby 1.9 also has a GIL but does not suffer from the problem of running slower on dual core than single core.