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

31–40 of 83 posts

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

#31

Post by kyleburton »

Locke1689 wrote: post #21
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…

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.

I am talking about the cultures surrounding these languages and frameworks. Node's community rejects blocking libraries. Java's does not. I've used the non-blocking frameworks in Perl (POE and my own), C (select, and some of the poll variants), Ruby (event machine) and they are fine if you can avoid blocking libraries -- in these communities it is generally acceptable to write blocking libraries. I don't see it as a technical hurdle, I see it as a cultural one.

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

#32

Post by dap »

From the article:

> InfoQ: What about running a real-time app on the JVM vs. on Node.js, with respect to debugging, monitoring and operations?

> Answer: I'd say monitoring and operations are really the concern of the environment in which you deploy vert.x than vert.x itself. e.g. if you deployed vert.x in a cloud, the cloud provider would probably provide monitoring for you.

This makes it sound like a toy. How can I deploy something to production when I have no way of seeing what it's doing? How is a cloud provider supposed to provide debugging/introspection for JavaScript running on the JVM (by means of a brand new facility)?

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

#33

Post by pron »

Uchikoma wrote: post #28
pron wrote: post #23

Earlier quoted context omitted.

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.

Is that supposed to be bad? The programming style will be the same. If threads are done right, and the JVM can manage their affinity well (especially on NUMA architectures), it's best to use them and pass a relatively small amount of data between them, then they can provide much better performance than accessing the same large piece of RAM from many threads (that's what happens if you simply replicate a single event-loop thread with asynchronous IO).

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

#34

Post by tsewlliw »

ExpiredLink wrote: post #10
hanswesterbeek wrote: post #9

Earlier quoted context omitted.

it ignores those, for good reason

which is?

Every concurrent request gets its own thread, whereas this seems to be one thread per core.

Also, the servlet API is crazy, partly because of all its baggage. There seems to be a lot of exploration around what the right API is right now, but its pretty clear the world wants something new.

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

#35

Post by tensor »

Uchikoma wrote: post #28
pron wrote: post #23

Earlier quoted context omitted.

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.

Maybe I am missing something, but how can you possibly have an async SQL driver without threads like this? This sounds like a case of your Node.js database driver hiding the exact same behaviour described here within C code.

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

#36

Post by batista »

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.

>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.

Would you call Node.js's MySQL drivers "production quality"?

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

#37

Post by jbooth »

dap wrote: post #30
purplefox wrote: post #15

Earlier quoted context omitted.

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).

Not really, typically you'd have one thread handling all sendFiles through a single selector over the destination sockets. As a matter of fact, it's actually really painful to do sendFile in Java from a single thread, because when the channel isn't ready for sending, rather than returning EAGAIN and letting you busy-loop or wait/retry or whatever, it throws an exception. So you have to use a selector to do sendfile, and in that case, why not use multiple tasks with the same selector?

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

#38

Post by pron »

tsewlliw wrote: post #34
ExpiredLink wrote: post #10

Earlier quoted context omitted.

which is?

Every concurrent request gets its own thread, whereas this seems to be one thread per core. Also, the servlet API is crazy, partly because of all its baggage. There seems to be a lot of exploration around what the right API is right now, but its pretty clear the world wants something new.

> Every concurrent request gets its own thread, whereas this seems to be one thread per core.

No. Servlet containers use a thread pool (that grows and shrinks dynamically).

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

#39

Post by batista »

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…

>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

Really? So they reject any kind of library that does anything except call a callback? Because everything else, from calculating 2+2 to creating a template blocks. And it doesn't matter when it happens, when it happens it blocks.

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

#40

Post by batista »

Uchikoma wrote: post #28
pron wrote: post #23

Earlier quoted context omitted.

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.

Yes, but the lib can do it for you, and you won't have to know a thing.
Post reply on HN