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

41–50 of 83 posts

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

#41

Post by batista »

kyleburton wrote: post #31
Locke1689 wrote: post #21

Earlier quoted context omitted.

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…

I am talking about the cultures surrounding these languages and frameworks. Node's community rejects blocking libraries. Java's does not.

So what?

You get tons of Java libs to use, a majority of blocking ones and lots of non blocking on one hand, or you restrict yourself to the fewer non-blocking libs of varying quality available for Node.

With Java you can also turn blocking libs to non blocking with a wrapper and threads, whereas with Node.js if it's blocking you're screwing, because the js engine is single-threaded.

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

#42

Post by soc88 »

kyleburton wrote: post #31
Locke1689 wrote: post #21

Earlier quoted context omitted.

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…

You make it sound like "rejecting blocking libraries" was some noble principle. Due to the severe limitations of JavaScript, there is no other choice.

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

#43

Post by dap »

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

(Response to jbooth, but for some reason I can't reply to that directly.)

The whole point of sendfile is to make one system call to send all the data in one stream to another, which in general may block. If you're polling and sending only small chunks at a time (whatever you can write without blocking), is it really that much of an advantage over read/write on the same poll? (If you're not doing that, then you have to block, and you have to dedicate a thread to it.)

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

#44

Post by sehugg »

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.

Your async container still can be useful, since you can have worker threads executing blocking operations. This works fine as long as your JDBC queries are fast enough to feed the event loop without creating tons of threads.

What async containers like Netty (and by proxy, Vert.x) solve is high-latency cases like long polling and file upload/download. Netty for one does have support for zero-copy file transfers: http://docs.jboss.org/netty/3.2/xref/org/jboss/netty/example...

In my experience, these are a small percentage of cases so the majority of the app can use blocking I/O -- even long-polling code, as long as you are using the async framework for the client connection.

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

#45

Post by scubaguy »

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.

Finagle looks like it is a bit lower level framework compared to vert.x. While Finagle aims to be a framework that supports services using multiple protocols, vert.x appears to be much more tailored for HTTP web services.

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

#47

Post by bascule »

Animus7 wrote: post #8

Impressive. It's basically a kinda-sorta-rewrite of Node.js APIs on the JVM. Looking through the docs, the main difference I see is that this is opting for a comparatively heavy-core approach which contrasts with Node's ruthless minimalism + third-party modules. For example: -file system access is convoluted with HTTP handling: req.response.sendFile() -pieces of web framework functionality by default, but no full sol…

"real concurrency" is a silly term, but I assume he means threads and therefore a multicore concurrency model vis-a-vis thread-level parallelism, allowing a single VM to utilize all cores in the system.

This is opposed to Node, which must run at least one VM for each CPU in order to utilize all of the cores in a system, unless your only use of threads is ThreadPoolExecutor-style pools, then you can use the horrible hack that is threads-a-gogo

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

#48

Post by spullara »

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.

Twitter is sponsoring a Summer of Code developer to create an async library for MySQL: http://engineering.twitter.com/2012/05/summer-of-code-at-twi...

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

#49

Post by tantalor »

lucian1900 wrote: post #2

So it's more like Twisted (a library) than Node (a runtime + a library).

Node is more like a library than a runtime. Its runtime is V8. The node libs could be ported to another JavaScript engine such as jsc, narwhal, or ringo.

> Node.js consists of Google's V8 JavaScript engine plus several built-in libraries.

http://en.wikipedia.org/wiki/Nodejs

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

#50

Post by gcampbell »

scubaguy wrote: post #45
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.

Finagle looks like it is a bit lower level framework compared to vert.x. While Finagle aims to be a framework that supports services using multiple protocols, vert.x appears to be much more tailored for HTTP web services.

finagle-http (https://github.com/twitter/finagle/tree/master/finagle-http) provides pretty much everything you need to build an HTTP web service.
Post reply on HN