Live data from Hacker News

What makes Node.js faster than Java? In a nutshell, it's all about concurrency

strongloop.com

51–59 of 59 posts

Re: What makes Node.js faster than Java? In a nutshell, it's all about concurrency

#51
post #6

Yea. This headline has to be troll bait. NodeJS is not faster than Java, and it's also not Concurrent. It is single threaded. It makes efficient use of that single thread with an event-oriented model. That said, I tend to prefer building in NodeJS because it's fast enough for most (unanticipated) use cases.

There's a difference between concurrency and parallelism. Concurrency is about a programming model for doing multiple independent tasks while parallelism refers to doing them at the same time. For example with node, you can handle requests while waiting for an asynchronous io task like reading a file. http://blog.golang.org/concurrency-is-not-parallelism

Parallelism is doing different parts of the same task at the same time. Concurrency is doing multiple, different tasks simultaneously. Single threaded, event oriented systems can appear to be concurrent. They can never be parallel.

Re: What makes Node.js faster than Java? In a nutshell, it's all about concurrency

#54
post #21

I have gotten to the point where I just can't take seriously anyone who equates "the async style" to "Node's event based system" as if Go, Erlang, Scala, Clojure, etc. don't exist. No, you do not have to choose between speed and sacrifice a sane coding style, and anyone still pushing that Node propaganda is just not worth listening to. Node is consistently beaten by multiple Go and Java frameworks across all benchmar…

Why is it a dangerous coding style? The new Node will have support for yield / generators that result in beautiful async code.

Try Go; get back to me on the beauty.

"Beautiful async code" is where the async is essentially invisible, because everything just is async.

Re: What makes Node.js faster than Java? In a nutshell, it's all about concurrency

#55

Yea. This headline has to be troll bait. NodeJS is not faster than Java, and it's also not Concurrent. It is single threaded. It makes efficient use of that single thread with an event-oriented model. That said, I tend to prefer building in NodeJS because it's fast enough for most (unanticipated) use cases.

node.js could be concurrent. You just run multiple node.js processes and leverage the tried and true concurrency of the UNIX process model, which Erlang architecture is based on.

Re: What makes Node.js faster than Java? In a nutshell, it's all about concurrency

#56

Node.js has linear speedup over multiple cores for web servers, no other language can claim that.

Excuse me, but you've mistyped the word "any" in "any other language" part.

Last time I checked, event loops and async IO wasn't anything Node had monopoly on. In fact, those are available on every non-toy general purpose platform I remember off my head.

Re: What makes Node.js faster than Java? In a nutshell, it's all about concurrency

#57
post #21

I have gotten to the point where I just can't take seriously anyone who equates "the async style" to "Node's event based system" as if Go, Erlang, Scala, Clojure, etc. don't exist. No, you do not have to choose between speed and sacrifice a sane coding style, and anyone still pushing that Node propaganda is just not worth listening to. Node is consistently beaten by multiple Go and Java frameworks across all benchmar…

It is indeed mind boggling when people list async (read: callback hell) as a feature. Complex systems rapidly get unmanageable, so people build nasty hacks to try to paper over the async core (it is still async single threaded at its core, run a dumb busy loop and watch your app stop responding).

Blocking is a feature. Blocking lets you reason easily, and as Go, Erlang, etc... have proven can be done at breathtaking speed and use all your cores... rather than wrapping your world view around async, use a system that allows you to keep your logic blocking and uses microprocesses to distribute work across a pool of threads. It is freeing to be able to just kick up 300k microprocesses if you need them.

Additionally, the node ecosystem tends to be quantity over quality... many of the available modules are simply more trouble than they are worth... while NPM makes getting them easy, it doesn't make deciding if something is worth using any easier.

Re: What makes Node.js faster than Java? In a nutshell, it's all about concurrency

#58
post #21

I have gotten to the point where I just can't take seriously anyone who equates "the async style" to "Node's event based system" as if Go, Erlang, Scala, Clojure, etc. don't exist. No, you do not have to choose between speed and sacrifice a sane coding style, and anyone still pushing that Node propaganda is just not worth listening to. Node is consistently beaten by multiple Go and Java frameworks across all benchmar…

I agree, they should at least compare to Go. However, it is fair to say that when using Java, you have to choose carefully since many API's block on I/O, including those that Java programmers use by default and are most likely to be familiar with.

It's really not that hard to make thing run async / paralell in java: You just create a ExecutorService and submit your runnables / callables. The java.util.concurrent-package makes this easy, and google guava has some useful extensions as well (e.g. ListenableFuture). This approach does of course spawn new threads, but threads are lightweight and using a ExecutorService allows for pooling of the threads (ThreadPoolExecutor). I do this all the time, when I find parts of the code that's worth optimizing - e.g. fetching multiple objects from a distant db-server (like aws).

Re: What makes Node.js faster than Java? In a nutshell, it's all about concurrency

#59
post #43
post #19

Earlier quoted context omitted.

> no server has the non-blocking ecosystem of Node.js today. Over 50k modules all written in the async style, ready to use. I read it as -- "Node.js doesn't properly support isolated units of concurrency and thus due to being forced to write callbacks inside callbacks that call errbacks for everything, we now have over 50k modules full of callback chains and we call this a GoodThing(tm)".

I don't think that's entirely fair. The standard callback model can easily be converted to a promise-based one with Q or a CSP channel-based one with ClojureScript's core.async or any number of other models.

It is but most of those module are not written like that.

For example Python's eventlet and gevent are based on greenlet. Greenlet is based underneath on large select/epoll/kqueue/poll loop. So there are callbacks for IO readiness there. However they manage to do some tricks to hide that away behind green threads at the user level. So a user can say: " authorize() ; check_database(); charge_credit_card(); update_database(); send_response()" logic properly for each request for example. Without having to split that logic into a chain of callbacks just because some of them might involve at some point making a socket call.

Post reply on HN