Hacker News new | past | comments | ask | show | jobs | submit login

> The JVM is a treasure just sitting there waiting to be rediscovered.

So true, long long back when people were going NodeJS ape-sh*t I did some benchmarks proving JVM can blow V8 out of water any given day (URL if someone is intrested http://blog.creapptives.com/post/9924551244/the-node-redumpt...) and got trolled by NodeJS fanboys alot.




> I did some benchmarks proving JVM can blow V8 out of water any given day (URL if someone is intrested http://blog.creapptives.com/post/9924551244/the-node-redumpt...) and got trolled by NodeJS fanboys alot.

Anyone who's worked with the JVM code knows what an amazing feat of engineering it is, really far more sophisticated than anything comparable. I've also experienced a similar reaction from NodeJS fanboys in the past.

That said, V8 is undergoing heavy development by a group of good people, and I'm sure it will catch up, eventually. The GC is improving all the time, for example.


But nodejs was never really about JVM vs. V8 in the first place.

It was about async io, handling everything in a process and a handful of threads, instead of spawning a new thread for every request (and paying for OS context switch).

Of course in your article you mention Netty. But Nodejs is (still) the only ecosystem where everything is async (event-loop style), vs. Java Netty or Python Twisted, in which you only have a subset of libraries.

Or am I mistaken?


Akka, Play and Lagom are part of the Lightbend Reactive Platform -- everything's async from the ground up, built on the JVM and Scala.

The authors put together the Reactive Manifesto: https://www.lightbend.com/blog/reactive-manifesto-20


That manifesto site drives me completely nuts. It reads like somebody is trying really, really, really hard to describe Erlang without actually saying, "Erlang".


> It was about async io, handling everything in a process and a handful of threads, instead of spawning a new thread for every request (and paying for OS context switch)

Given that the data, and the events about the movement of data, come from the kernel, there are still just as many context switches with lightweight threads.

The only real advantage of lightweight threads, as pcwalton pointed on recently in another discussion, is that they can have much smaller stacks, so you can have many more of them before you run out of address space.

The biggest advantage of Node.js, though, is that it let people who know JavaScript write server-side code with reasonable performance and scalability. If you already know Java, there's no reason to use Node.js. If you only know JavaScript, or JavaScript plus some 'slow' server-side language like Ruby, the Node.js is an easy way to get more performance and scalability.

Go is filling a similar niche. If you know Java or C# or C++, Go is pointless, but if you only know JavaScript, Ruby, Python, etc, then the ease of learning Go makes it a viable option on the server side.


Lightweight threads? Nodejs doesnt use them. There is only a process and a handful of threads which are basically workers.

And I don't buy that the only point of nodejs is that _that it let people who know JavaScript write server-side code with reasonable performance and scalability_.

Writing nodejs code is a complete different beast from frontend javascript. I actually think writing nodejs is much harder to understand and code than eg Golang or Java.

For me, personally, the point of Nodejs is neither performance nor the fact that its _async_.

Nodejs has a really good balance of performance, tooling, ecosystem and scalability.

Of course I could be wrong.


Cool article, Would be interesting to see these benchmarks updated :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: