Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vert.x – JVM Polyglot Alternative to Node.js

infoq.com

Post reply on HN
Print view View original

21–30 of 83 posts

Re: Vert.x – JVM Polyglot Alternative to Node.js

#21

Post by Locke1689 »

kyleburton wrote: post #20
Uchikoma wrote: post #18

Finagle works fine. Thank you. Love it. But it does not take off. Why? What all the JVM Node.js clones are missing and what Node.js sets apart are async libraries. There is no async (MySQL) JDBC driver for starters. If your IO drivers are not async, your async container is not very useful in real life.

This. The biggest difference is in the two cultures: blocking is anathema to the Node.js community - they will literally reject libraries or code that blocks because it destroys the entire model; the JVM community does not value non-blocking code - most of the core (JDBC, Networking in general, File system operations) is all written in a blocking style - the JVM community accepts this with the implicit assumption tha…

What are you talking about? libevent invented everything Node.js uses and Python's Twisted had and has everything Node.js could dream of.

Node.js is just a reinvention of old technologies in Javascript.

Edit: Removed flame about Javascript because I don't want to have this debate again.

Re: Vert.x – JVM Polyglot Alternative to Node.js

#22

Post by andrewvc »

Uchikoma wrote: post #18

Finagle works fine. Thank you. Love it. But it does not take off. Why? What all the JVM Node.js clones are missing and what Node.js sets apart are async libraries. There is no async (MySQL) JDBC driver for starters. If your IO drivers are not async, your async container is not very useful in real life.

So, I googled 'finagle java' and all the results were terrible. There was no concise description with a short example. Nothing led me to believe 'node.js' clone in anything I saw in the first few results. In fact, the first result was this: http://engineering.twitter.com/2011/08/finagle-protocol-agno...

"Protocol-agnostic RPC System" does not sound like a node clone at all.

Re: Vert.x – JVM Polyglot Alternative to Node.js

#23

Post by pron »

kyleburton wrote: post #20
Uchikoma wrote: post #18

Finagle works fine. Thank you. Love it. But it does not take off. Why? What all the JVM Node.js clones are missing and what Node.js sets apart are async libraries. There is no async (MySQL) JDBC driver for starters. If your IO drivers are not async, your async container is not very useful in real life.

This. The biggest difference is in the two cultures: blocking is anathema to the Node.js community - they will literally reject libraries or code that blocks because it destroys the entire model; the JVM community does not value non-blocking code - most of the core (JDBC, Networking in general, File system operations) is all written in a blocking style - the JVM community accepts this with the implicit assumption tha…

Java Executors combined with Guava's ListenableFutures easily turn any blocking operation to an asynchronous one.

Netty's entire model is asynchronous, and Java 7 now has AsynchronousChannels for IO which, I assume, Netty will make use of.

All in all, the JVM has a much more solid and performant foundation than anything Node can provide. The whole difference will come down to a programming style preference. I am not entirely sure why Vert.x adopted the Node style rather than the proven servlet container, as I'm sure both styles provide comparable performance. I guess each may shine under different loads/usage patterns (my guess is that Vert.x/Node can squeeze more performance from a single thread, but servlets are more scalable).

Re: Vert.x – JVM Polyglot Alternative to Node.js

#24

Post by Uchikoma »

kyleburton wrote: post #20
Uchikoma wrote: post #18

Finagle works fine. Thank you. Love it. But it does not take off. Why? What all the JVM Node.js clones are missing and what Node.js sets apart are async libraries. There is no async (MySQL) JDBC driver for starters. If your IO drivers are not async, your async container is not very useful in real life.

This. The biggest difference is in the two cultures: blocking is anathema to the Node.js community - they will literally reject libraries or code that blocks because it destroys the entire model; the JVM community does not value non-blocking code - most of the core (JDBC, Networking in general, File system operations) is all written in a blocking style - the JVM community accepts this with the implicit assumption tha…

We run a major site on Java, had some thread trouble years ago in the very beginning, works very well now when tuned. Threads work.

BUT: I assume people will move to backend services with REST and combining REST backend results to a page. This increases IO a lot and will kill your latency and default thread models when you do sync code. You'd need to use async IO, composeable futures to manage latency and thread count. And if you do async backend REST, why not do async JDBC etc. But there are no libraries.

Re: Vert.x – JVM Polyglot Alternative to Node.js

#27

Post by Uchikoma »

andrewvc wrote: post #22
Uchikoma wrote: post #18

Finagle works fine. Thank you. Love it. But it does not take off. Why? What all the JVM Node.js clones are missing and what Node.js sets apart are async libraries. There is no async (MySQL) JDBC driver for starters. If your IO drivers are not async, your async container is not very useful in real life.

So, I googled 'finagle java' and all the results were terrible. There was no concise description with a short example. Nothing led me to believe 'node.js' clone in anything I saw in the first few results. In fact, the first result was this: http://engineering.twitter.com/2011/08/finagle-protocol-agno... "Protocol-agnostic RPC System" does not sound like a node clone at all.

(as a side note, what do you think REST PUT calls over HTTP on Node are?)

Finagle is about composing async IO calls, e.g. here

http://twitter.github.com/scala_school/finagle.html

This works much better in Scala, as Java is not very good at composing Futures. It needs a lot of boiler plate code as it lacks noise free closures.

Re: Vert.x – JVM Polyglot Alternative to Node.js

#28

Post by Uchikoma »

pron wrote: post #23
kyleburton wrote: post #20

Earlier quoted context omitted.

This. The biggest difference is in the two cultures: blocking is anathema to the Node.js community - they will literally reject libraries or code that blocks because it destroys the entire model; the JVM community does not value non-blocking code - most of the core (JDBC, Networking in general, File system operations) is all written in a blocking style - the JVM community accepts this with the implicit assumption tha…

Java Executor s combined with Guava's ListenableFuture s easily turn any blocking operation to an asynchronous one. Netty's entire model is asynchronous, and Java 7 now has AsynchronousChannel s for IO which, I assume, Netty will make use of. All in all, the JVM has a much more solid and performant foundation than anything Node can provide. The whole difference will come down to a programming style preference. I am n…

There is no async MySDQL JDBC driver. If you encapsulate it in an async layer, you need to keep a thread for the connection.

Re: Vert.x – JVM Polyglot Alternative to Node.js

#29

Post by jhspaybar »

Maybe I'm one of the weird ones, but I absolutely love types and would probably write everything in JS if it had typing similar to Java or C++. As it is, I'm using Java on Jetty instead for my current web application but would love to see a really solid event Node.js style typed framework. With that said, at this point I'm not sure I'd give up my Servlets, frameworks(like CometD) for doing WebSockets, and the other niceties that a true servlet container gives me. I can't wait to see where this goes though!

Re: Vert.x – JVM Polyglot Alternative to Node.js

#30

Post by dap »

purplefox wrote: post #15
stephen wrote: post #14

Earlier quoted context omitted.

> -file system access is convoluted with HTTP handling: req.response.sendFile() I haven't looked in to it, but just guessing this is probably so that it can do 0-copy sending of files (e.g. doesn't have to buffer/stream the contents through the JVM).

That's right. If you use the sendFile() method and you're on an OS that supports it, then the kernel will do the copying directly from file to socket for you. You can also serve files in the more conventional "node.js-style" way (i.e. pump the buffers manually from file to socket) if you like. It's just slower than getting the kernel to do the work for you.

But you have to dedicate a thread to sendFile() (by nature).
Post reply on HN