4 ms·
Great article, but there are some issues with the comparison, specifically with the "Pros" listed for Rails: 1. Multi threaded -- This is not a "Pro" as node c
by johnhenry 10y ago
Great article, but there are some issues with the comparison, specifically with the "Pros" listed for Rails:
1. Multi threaded -- This is not a "Pro" as node can take advantage of multiple cores using the built in cluster module: https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html. Node is multi-threaded too.
2. No callbacks -- I wouldn't consider this a "Pro" as even though it makes programming more complicated, asynchronous code can simulate synchronous code, but not the other way around.
Further, thanks to additions like promises and async/await, asynchronous programming in JavaScript will soon be about as easy to wrap one's head around as synchronous programming without the use of callbacks.
3. Code Maintenance -- It's hard to call this a "Pro" -- it's like comparing apples to oranges. As mentioned in the article "NodeJS is a Runtime Environment for running JavaScript as a server." and "Rails is a Framework for Ruby Language." You'd find less of a difference in comparing Rails to something like Sails (http://sailsjs.org/ http://sailsjs.org/), a Framework for JavaScript.
- pmontra 10y agoRails can be multithreaded but most often than not it isn't. If you run on MRI you have the GIL so only one thread can run at the same time. Parallelism is achieved by running multiple Ruby processes. However, if you compile with JRuby and run on the JVM you have real multithreading. Not a very popular option in the setups I saw, probably because using JRuby in development is still quite painful and slow compared to MRI.