Live data from Hacker News

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

strongloop.com

21–30 of 59 posts

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

#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 benchmarks [1], consistently beaten by Scalatra, somewhat inconsistently beaten by the Haskell wai implementation (missing some benchmarks, I suspect wai would continue winning though if they were implemented; also I think those benchmarks are on an older Haskell IO manager). Not only are you choosing a dangerous coding style, you're not even winning the performance you think you are. Node is not faster. And certainly every library for Go, Haskell and Erlang, and probably everything for Scala and Clojure (not 100% sure of their runtime models) is already "async ready", and Java itself probably isn't exactly running short of libraries at this point.

[1]: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...

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

#22
Systems such as Go's goroutines, or clojure's core.async, or objective-c's GCD all solve the same concurrency problem while still allowing you to saturate all of your cores from a single process.

This allows you to get around some nasty architectural problems you can hit with node, where you must either find a way to manually schedule all of your computation into tiny chunks to avoid latency issues, or face potentially severe costs serializing your data to communicate it between processes. No trolling here, it's really a thing that happens!

People do solve these problems in node, it's just that the "ease" suddenly turns against you, as you must now solve tricky systems problems - such as manually scheduling all of your computation properly - or face potentially unacceptable performance degradation. In these cases the limitations of the platform become your overriding architectural driver - better drivers like logical separation start to take a back seat. It's not pretty - and not necessary in other environments.

Given that you won't encounter these types of problems until later - once you've already built up a large codebase and switching platforms is difficult - I think it's better to start in an environment where you know you have these tools available to you when you need them. Even though I really enjoy programming in node (and I've done a lot of it!), I'm wary of starting anything new there unless I have a good reason. There are a lot of great modules written in node, I just try to keep those components isolated and not let them grow too large.

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

#23
post #8

Earlier quoted context omitted.

Your operating system is concurrent even if it's single threaded. Concurrency is about doing things in the same time period not necessarily at the exact same time.

It's really not.

Thanks for your descriptive rebuttal.

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

#24
> At high levels of concurrency (thousands of connections) your server needs to go to asynchronous non-blocking.

It does. But it doesn't have to expose that as callback chains or promises to the whole over-arching infrastructure that sits on top. Concurrency units should be isolated from each other and internally execute whatever their logic is without having to worry about being polluted with callbacks. Then there could be multiple of such concurrency units executing in parallel but that is a the job of a decent VM/runtime/library to handle.

> And at these levels of concurrency, you can’t go creating threads for every connection.

Even something as simple as python gevent can create tens of thousands of green threads without a problem without exposing callback chains for everyone to see.

Erlang VM and something like https://github.com/puniverse/quasar can run with millions of concurrency units so do goroutines and Rust's concurrency units (sorry forgot the name).

> So the whole codepath needs to be non-blocking and async, not just the IO layer.

Quite the opposite. If your whole codepath riddled with callback chains and your project is large now you have a huge headache to deal with.

> This is where Node excels.

If it forces one to use promises/deferreds/futures or nested callbacks, I say it fails.

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

#25
post #5

At first, I was ready to dismiss this article completely. However, this paragraph: "While Java or Node or something else may win a benchmark, no server has the non-blocking ecosystem of Node.js today. Over 50k modules all written in the async style, ready to use. Countless code examples strewn about the web. Lessons and tutorials all using the async style. Debuggers, monitors, loggers, cluster managers, test framewor…

This is slightly off topic, but if we're talking about language capabilities for async:

Something I only figured out fairly recently but that shocked me is that Haskell, with its lazy evaluation, you can essentially get asynchronous programs for free, and still write in a synchronous style.

While by default the IO monad is strict (basically makes IO stuff synchronous), there are some non-strict actions that are really easy to use.

Imagine the following program:

Open two ports, and print the first couple of bytes recieved from each port.

In node (at least from the callback-based stuff), at one point you're going to have an inevitable :

  while(!done){} //waiting
in Haskell, this program looks roughly like:

  main = do
   socket    
Lazy IO in Haskell is what I call blocking on data-dependencies: because of how lazy evaluation works, Haskell is able to keep on going until the very moment you need the result from some async call.

It's even crazier that Haskell has the holy grail of async programming : the function that transforms a synchronous function to an asynchronous one.

Instead of having

  main = do
     x 
you simply do

  main = do
     x 
a becomes asynchronous , and nothing else in your code has to change.

(from what I understand unsafeInterleaveIO is called like that because it makes the order of your IO actions a bit uncertain, which is a problem for print statements, but when you're doing async programming this is already the case!)

Laziness makes Haskell crazy neat, and I would really love for lazy features to enter other languages. There are some issues (error handling mainly) but it gives you the best of both worlds, I find.

( I am by no means a Haskell expert, so all this might be wrong, but in my experience things work this way-ish)

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

#26
"But there’s one thing we can all agree on: At high levels of concurrency (thousands of connections) your server needs to go to asynchronous non-blocking."

No, we can't all agree on that. Asynchronous non-blocking might be better in limited scenarios where threads are expensive (memory or cpu or other constraints).

"While Java or Node or something else may win a benchmark, no server has the non-blocking ecosystem of Node.js today. Over 50k modules all written in the async style, ready to use."

Sad to see so much work go into a faulty design. Take a look at this presentation http://www.slideshare.net/e456/tyma-paulmultithreaded1.

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

#27
post #11
post #8

Earlier quoted context omitted.

Your operating system is concurrent even if it's single threaded. Concurrency is about doing things in the same time period not necessarily at the exact same time.

That said, saying (concurrent) Node is faster than (nonconcurrent) Language X is several distinct levels of stupid. If you introduce blocking into an application then to the user it slower, but in terms of computation it could still be faster by some magnitude. It's like having C block on a network call while having in-browser Javascript concurrently move past it and declaring Javascript faster.

> Language X

Actually, comparing runtime/platform (Node) to language is completely pointless. Language is, well, only a language, it can't be "faster" or "slower" unless we're talking about coding speed. We have to compare implementations.

And even if we treat Java as a platform, contrary to Node it has ton of highly-varying implementations, so it's still pointless without careful clarifying what one compares. Or they may accidentally find out there's a Java variation with green threads somewhere that may break the whole "look, their ugly threads are slow and our event loops are fast" charm.

The article is just a pure load of non-sense. Highly flammable, though.

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

#28
post #16
post #7

I'm always wondering why gevent never gets the same attention other concurrency frameworks do. From my point of view it looks like a very sweet library with useful tools and should work just fine in combination with gunicorn or uwsgi. I never had a chance to test it with some real work load though.

Problem is the lack of third party libraries that does IO the way gevent works, if your lib does blocking IO, there is no point using gevent. NodeJS does async IO by default,so all nodejs libs do async IO. My point is , it's not so much about wether ruby or python can have the same capabilities as nodejs they can,it's about wether async libs have an ecosystem to support them or not.

"Problem is the lack of third party libraries that does IO the way gevent works, if your lib does blocking IO, there is no point using gevent."

Here we probably see some of the problem. Gevent works in a way that most people don't expect, which is to hack the IO layer itself. You don't need a library to "support" gevent for it to still work within gevent. If the library's "synchronousness" is that it opens sockets and uses them, that Just Works in gevent; every time the library does a "blocking" operation in gevent, gevent replaces it with an entry in some sort of polling loop, and moves to the next eventlet that can do work. I used it to write a highly concurrent program that made a ton of simultaneous XML-RPC calls, and I used gevent + the default "blocking" XML-RPC library from Python's core library. It makes the ecosystem support async, at least for network, timers (sleep), and a few other things.

Gevent has other issues; I don't think it can do the same for disk IO. But especially if you've got a network heavy program, you can just drop gevent in and get perfectly cromulent async.

I think a lot of people don't quite understand this. The Node community's persistent and vocal false belief that "async == visibly event-based structure code" probably isn't helping. But it is also true that gevent is a legitimately weird hack on a language. Cool, but very unusual.

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

#29
post #5

At first, I was ready to dismiss this article completely. However, this paragraph: "While Java or Node or something else may win a benchmark, no server has the non-blocking ecosystem of Node.js today. Over 50k modules all written in the async style, ready to use. Countless code examples strewn about the web. Lessons and tutorials all using the async style. Debuggers, monitors, loggers, cluster managers, test framewor…

Look at Akka, it brings a very rich concurrency toolkit to the JVM, building on the already-excellent primitives provided by the standard library.

Futures and actors are quite elegant and simplify reasoning about concurrency.

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

#30
post #19
post #5

At first, I was ready to dismiss this article completely. However, this paragraph: "While Java or Node or something else may win a benchmark, no server has the non-blocking ecosystem of Node.js today. Over 50k modules all written in the async style, ready to use. Countless code examples strewn about the web. Lessons and tutorials all using the async style. Debuggers, monitors, loggers, cluster managers, test framewor…

> 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'll call you when you need me.
Post reply on HN