Live data from Hacker News

Vert.x – JVM Polyglot Alternative to Node.js

infoq.com

11–20 of 83 posts

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

#12
post #4

Trying to install this on Ubuntu. Is it me or is the "binary" download link [1] not really a binary download link? [1] https://github.com/purplefox/vert.x/downloads

Works fine here:

https://gist.github.com/2594983

Are you sure you're not looking at the github tags, rather than the downloads?

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

#14
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…

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

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

#15
post #14
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…

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

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

#16

I was hoping it provided an alternative ideology to node.js in the form of fibers.

Fibers (or equivalent constructs) aren't supported by all the languages that Vert.x supports (e.g. Java) so we can't really support something like that until we can do it in all the langs.

I know Fibers/Green threads are all the rage right now, and it is certainly something to keep an eye on, but I am not entirely convinced that roll your own threading is going to be any more performant than what the kernel can do.

If we can find a way of implementing fibers efficiently, that supports millions of fibers on a single JVM instance, I would be interested.

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

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

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

#19
I'm really excited about this. While node-js is a great project, it still doesn't have the awesome instrumentation and tooling around it the JVM does. Additionally, real threading is damn nice, and the JVM definitely has that.

Combining this with languages like ruby, clojure, and scala seems like a definite win.

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

#20

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 that threads will help assuage those issues.

Python, Ruby and Perl all have the same cultural tolerance for blocking code. The Node.js community has a complete lack of tolerance for blocking code.

I work with the JVM every day (Clojure) and wish it was different wrt the common use of non-blocking code, but it's going to be a long road to get there on the JVM.

Kyle

Post reply on HN