Return to Answer

While that concept can indeed be implemented in many languages (and as dodgy_coder mentioned, it has been implemented in Ruby and Python at least), it's not quite as trivial as you state.

True, Java has non-blocking IO APIs. So you can do raw disk/network IO in a non-blocking way. However every API that somehow wraps or handles IO needs to be implemented in a non-blocking way as well. Every XML parser, every Database driver, every file-format converter needs to be written to support non-blocking IO. Because if a single library is blocking in this pattern, then that brings down your servers performance to stone-age values.

Node.js has that library infrastructure, because it was always designed that way: every library that strives to become popular has to provide an asynchronous API or it will not be used.

While that concept can indeed be implemented in many languages (and as dodgy_coder mentioned, it has been implemented in Ruby and Python at least), it's not quite as trivial as you state.

True, Java has non-blocking IO APIs. So you can do raw disk/network IO in a non-blocking way. However every API that somehow wraps or handles IO needs to be implemented in a non-blocking way as well. Every XML parser, every Database driver, every file-format converter needs to be written to support non-blocking IO. Because if a single library is blocking in this pattern, then that brings down your servers performance to stone-age values.

Node.js has that library infrastructure, because it was always designed that way: every library that strives to become popular has to provide an asynchronous API or it will not be used.

While that concept can indeed be implemented in many languages (and as dodgy_coder mentioned, it has been implemented in Ruby and Python at least), it's not quite as trivial as you state.

True, Java has non-blocking IO APIs. So you can do raw disk/network IO in a non-blocking way. However every API that somehow wraps or handles IO needs to be implemented in a non-blocking way as well. Every XML parser, every Database driver, every file-format converter needs to be written to support non-blocking IO. Because if a single library is blocking in this pattern, then that brings down your servers performance to stone-age values.

Node.js has that library infrastructure, because it was always designed that way: every library that strives to become popular has to provide an asnychronous API or it will not be used.

While that concept can indeed be implemented in many languages (and as dodgy_coder mentioned, it has been implemented in Ruby and Python at least), it's not quite as trivial as you state.

True, Java has non-blocking IO APIs. So you can do raw disk/network IO in a non-blocking way. However every API that somehow wraps or handles IO needs to be implemented in a non-blocking way as well. Every XML parser, every Database driver, every file-format converter needs to be written to support non-blocking IO. Because if a single library is blocking in this pattern, then that brings down your servers performance to stone-age values.

Node.js has that library infrastructure, because it was always designed that way: every library that strives to become popular has to provide an asynchronous API or it will not be used.

While that concept can indeed be implemented in many languages (and as dodgy_coder mentioned, it has been implemented in Ruby and Python at least), it's not quite as trivial as you state.

True, Java has non-blocking IO APIs. So you can do raw disk/network IO in a non-blocking way. However every API that somehow wraps or handles IO needs to be implemented in a non-blocking way as well. Every XML parser, every Database driver, every file-format converter needs to be written to support non-blocking IO. Because if a single library is blocking in this pattern, then that brings down your servers performance to stone-age values.

Node.js has that library infrastructure, because it was always designed that way: every library that strives to become popular has to provide an asnychronous API or it will not be used.

While that concept can indeed be implemented in many languages (and as dodgy_coder mentioned, it has been implemented in Ruby and Python at least), it's not quite as trivial as you state.

True, Java has non-blocking IO APIs. So you can do raw disk/network IO in a non-blocking way. However every API that somehow wraps or handles IO needs to be implemented in a non-blocking way as well. Every XML parser, every Database driver, every file-format converter needs to be written to support non-blocking IO. Because if a single library is blocking in this pattern, then that brings down your servers performance to stone-age values.

Node.js has that library infrastructure, because it was always designed that way: every library that strives to become popular has to provide an asnychronous API or it will not be used.