As the creator of Nodyn, but being late on the draw, I'll just have to echo what everyone else has said here. Java provides a large and rich ecosystem that is either unavailable or prohibitively difficult to bundle into a native runtime.
Nodyn is not yet complete, though I'd like to have a release in the next month that is capable of running express.js apps. It is slower than Node.js, but of course I'd like that to change; and with the JVM underneath, beating Node.js on performance is possible.
Nodyn is built on top of Vert.x (http://vertx.io) an asynchronous polyglot platform which excels on the Techempower benchmarks. The javascript runtime is DynJS - a new JS runtime for the JVM which is independent of Oracle. Though it's admittedly slower than Nashorn at the moment, we hope for that to change.
Will it have the concurrency features of Vert.x? I was hoping that jxcore [1] (aka NodeJX) would bring these to node but this seems like a better alternative.
Given the asynchronous programming model that node encourages, how have you found integrating with the traditional Java programming model that most of the Java ecosystem uses?
Vert.x has something called a 'worker verticle' that can run blocking IO in a thread pool. You'd communicate with the worker by passing messages on the event bus asynchronously. It makes integrating those kind of services fairly straight forward, but obviously you'd switch to actual async APIs if available.
Question from a novice-ish developer: What is the purpose of porting things to the JVM? I had this idea before that porting things like Ruby or Rails to the JVM was meant to offer ruby the advantages of having a java core (better threading, garbage collection, faster). But, as I understand it, Node is faster than JVM languages? What are the other advantages gleaned from porting?
e: Thank you guys for the answers, definitely makes a lot more sense now.
The JVM gives you very good JIT, GC, threading, manageability (profiling, debugging, memory inspection etc), scalability to huge machines, a huge ecosystem of software and has basically solved every real-world deployment problem. (Maybe apart from memory utilization!) It is definitely possible to beat the JVM on any one of these facets, but to consistently beat it on all of them is a _lot_ of work. (I'm not sure which benchmark you're referring to where Node beats the JVM, but I suspect it's relatively 'focused'.)
To my mind, the idea of porting is that you face a choice: you can recreate the JVM functionality in your own runtime, or you can port to the JVM. Porting to the JVM is certainly non-trivial, but you then get thousands of man-years of work in return. It's certainly worth doing a project to see whether the porting effort pays off; especially if this done concurrently with working on the language's 'native' runtime.
Is there a C programmer on the planet that does production builds with a non-optimizing compiler? How is your comparison even remotely relevant to the GP?
That's mostly true, but just like managed languages can leverage JVM, native languages can leverage LLVM.
The advantage of going the native route is that it gives you improved observability and post-mortem. The JVM is a VM (Java's) inside a VM (the OS's), and that additional layer doesn't come for free.
Most commercial JVMs also have native compilers for Java, and there are a few projects to run JVMs directly on top of hypervisors without OS in the middle.
I'm referring to the open Hotspot which almost everyone uses, not some specialized JVM products which are closed-source. You do bring up an interesting point though.
As for the type of hypervisors you're referring to, those things are effectively half-baked operating systems. That's why something like KVM is better -- you're not pretending to be a non-OS while slowly reinventing a wheel that the *nixes have and always will do better.
I think we're beginning to wander massively afield though! :)
Naive (and mostly ignorant) programmers make a habit of sh*tting on the JVM and the Java platform in general.
My usual response regarding the merit of the JVM is this: there is a reason there's jvm on the server, desktop, on your phone, on the rovers on mars and god knows on how many mission critical systems.
And no it isn't because of great marketing, which is another common and lame response from JVM detractors.
The JVM is an impressive engineering effort and the eco-system spawned by it is currently unrivaled.
With the new trend of porting other languages (ruby,python,js..etc) to it, the I see the JVM as the middleware over which most future software would be built.
Node is actually much slower than Java. True, the JavaScript implementation on the JVM is slower than V8 (even Nashorn, the new JavaScript engine included in Java 8). Of course, the main motivation is, as others have said, integration with the huge Java ecosystem, but being able to drop down to Java for performance (when you need it) is a lot easier than writing native V8 modules.
Imagine that you just started a new job at a big company. It's a "Java shop". You're allowed to use any technology stack you want for your apps, and all the other apps have APIs, but there's hundreds of useful Java libraries that already exist for talking to these APIs.
This would allow you to use NodeJS but still leverage the existing Java libraries, not requiring you to rewrite them.
> Question from a novice-ish developer: What is the purpose of porting things to the JVM?
Interop with the things that already exist in the Java ecosystem.
> I had this idea before that porting things like Ruby or Rails to the JVM was meant to offer ruby the advantages of having a java core (better threading, garbage collection, faster).
To the extent that those were effects of porting Ruby to the JVM they were mostly secondary, Java interop was the key feature (Rails, BTW, wasn't ported to the JVM, it just runs anywhere you have a functional Ruby implementation -- heck, before Ruby had executable specs, the test for a functional implementation was pretty much "does it run Rails".)
It seems like a major motivation for this project is to be able to use Java libraries from Javascript (a la Jython). There are a non-negligible number of libraries that only exist for Java, and being able to harness those from JS sounds nice to me, even if it means taking a performance hit.
In my opinion (I'm a Java dev), the main benefits are being able to run RoR apps on TorqueBox[1] or some other JRuby server[2] and benefit the clustering, HA and other stuff that go with it; and 'the use of "true" native threads'[3].
Node is more adept at handling many concurrent requests due to its architecture but it's runtime is far slower than the JVM. The vert.x framework that is the basis for this project is based on a similar paradigm to node and is far faster.
to run it 'in the cloud'; most hosting places will allow you to run java only, this restriction is in place so that everything will seem secure and divided into neat compartments.
I personally have been wanting a way to compile ClojureScript to JavaScript without using the JVM. I'd rather just use the existing Node/v8 installation that I have, especially since I don't use the JVM for anything else. I know this project doesn't do that, I'm just throwing my wants and desires out into the wild and hoping they come alive.
Don't forget that ClojureScript macros are written in Clojure. Even if you rewrote the compiler in ClojureScript, it seems like you'd need the JVM to run your Clojure macros (unless you were OK with sacrificing some compatibility).
The focus of avatar-js seems to be to support the avatar project, which seems to be mainly about providing a node like server.
At present, there aren't nice binary downloads for anything that can just run node programs, I had to fiddle about a bit to get something I could play with, and even then, only some programs work - npm for example seems to go into a loop.
Isn't the idea of asm.js that if a program is written according to the spec you can generate simpler and so hopefully faster code? That applies whether you're generating bytecode or machine code.
Sure, but you'd have to generate asm.js in the first place. It's compiler target that also happens to map to a small subset of JavaScript, you're unlikely to find writing asm.js by hand useful.
DynJS could also support asm.js in addition to JavaScript, but that has almost nothing to do with JIT-ing JavaScript applications.
Right. I wasn't thinking of this as the _only_ JIT case, but one that could generate faster code by not having to do complex type tracing or inference. Seems like low hanging fruit to detect asm.js and read it directly into a typed AST.
Also for anyone interested in an easy way to use the JVM for other languages, check out crudzilla.com . It is primarily for web development but has basic editor for other development work.
Not in any way trying to troll here, but other than as an intellectual exercise, why on earth would one want to develop in Node on the JVM? Surely Java/Scala/Clojure etc would solve any problem easier and faster than Node on JVM?
I would venture to guess that interoperability with existing projects and services is important to some people. Also, there are Java libraries which are significantly better than their closest corresponding Node package.
Why would you code in Javascript on the JVM to begin with if you have existing projects and libraries written in java ? that's stupid. If the goal is async IO there is Vert.x and other non blocking servers already. Not even talking about cases when libs require C++ extensions... Can you code in Java on Nodyn? no
EDIT : seems to be built upon Vert.x ? you can already code in javascript with Vert.x
"that's stupid" is a pretty broad statement. There are many reasons why one may choose to write new software in JS while taking advantage of existing investment in Java. If it doesn't make sense for you, don't do it. But for many it may.
As for coding Java on Nodyn, well, yes you can. That's kind of the point in some ways. You can write Java, package it as a jar and access this from Nodyn. Nodyn itself does this for the Buffer implementation.
Yes, vert.x already supports JS (I maintain the mod-lang-js, mod-lang-rhino and mod-lang-dynjs language modules for vert.x). The idea behind Nodyn is to provide drop-in Node.js compatibility in the Vert.x environment.
Nodyn is not yet complete, though I'd like to have a release in the next month that is capable of running express.js apps. It is slower than Node.js, but of course I'd like that to change; and with the JVM underneath, beating Node.js on performance is possible.
Nodyn is built on top of Vert.x (http://vertx.io) an asynchronous polyglot platform which excels on the Techempower benchmarks. The javascript runtime is DynJS - a new JS runtime for the JVM which is independent of Oracle. Though it's admittedly slower than Nashorn at the moment, we hope for that to change.