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

71–80 of 83 posts

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

#71

Post by moe »

ricardobeat wrote: post #70
batista wrote: post #41

Earlier quoted context omitted.

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 t…

Node is nearing 10k published libraries. Is there a comprehensive site listing Java libraries? It's trivial to offload blocking operations to other processes in node too, it's just not the preferred option.

Node is nearing 10k published libraries.

And ruby has 38237 gems. 99,9% of which are garbage.

Library-count is a terrible metric.

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

#72

Post by juiceandjuice »

ricardobeat wrote: post #70
batista wrote: post #41

Earlier quoted context omitted.

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 t…

Node is nearing 10k published libraries. Is there a comprehensive site listing Java libraries? It's trivial to offload blocking operations to other processes in node too, it's just not the preferred option.

Have you ever programmed in Java? That's a strange question to ask if you have.

http://mvnrepository.com/

Whatever libraries node has is a drop in the bucket compared to java.

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

#73

Post by ww520 »

sehugg wrote: post #13

Looks like a user-friendly interface to Netty and Hazelcast with some special sauce sprinkled in. I love Netty, and Hazelcast is, er, interesting and hopefully getting more reliable. Should be fun.

Netty and Hazelcast are amazing pieces of software. I've used them with good success. Hazelcast is another unique enabler that makes the impossible or difficult to do trivial.

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

#74

Post by scubaguy »

gcampbell wrote: post #50
scubaguy wrote: post #45

Earlier quoted context omitted.

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.

But take a look at the Finagle example from Heroku and compare it to the example from vert.x. There's a lot of boilerplate in the Finagle version because Finagle is a general purpose async service framework, which was my entire point.

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

#75

Post by Zak »

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

I'm not sure.

Async-by-default doesn't seem like a great model for programming the server-side part of most things that are done over HTTP. Three use cases jump out at me:

1. Javascript doesn't have threads, but you want to write a usable HTTP server in it.

2. Threads are scary.

3. You want to make certain actions asynchronous over HTTP (i.e. client says "start", then server maybe says "done" later).

Now consider Clojure:

1. Clojure has threads (on the JVM, at least) and one typically uses an existing Java web server when a web server is called for. Unlike Javascript when node.js came out, Clojure isn't lacking options for running or writing a web server.

2. Clojure makes a lot of threaded operations pretty non-scary. Its native data structures are all immutable and it has constructs for concurrent state. These are not any harder to work with than the async/callback model. I find it more natural, but I'm used to Clojure so that could be bias.

3. Async-when-desired is already easy in Clojure. Futures provide a very easy way to do stuff in a thread pool without blocking. Agents provide the same thing for state changes. It really is as easy as (future do-blocking-thing) and (send-off an-agent do-blocking-thing some-args).

I can imagine why I might want this sort of thing in certain languages in addition to Javascript, but why would I want it in Clojure?

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

#76

Post by Uchikoma »

purplefox wrote: post #54
tensor wrote: post #35

Earlier quoted context omitted.

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.

If the wire protocol for the driver is published, then you can write a 100% async driver for it. I.e. no threads blocking, ever. In fact, I already did this for redis and vert.x (I will dig out the code for this some time). If you are dealing with something where you don't know what the wire protocol is and you just have a blocking client library to play with (e.g. JDBC - JDBC is, by definition blocking - see the JDB…

A limited number of threads will not scale as real async wake-on-data connections will scale. If demand is higher than your thread pool, for the use case that you're web response builds on async backend requests, your site will be down.

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

#77

Post by Uchikoma »

spullara wrote: post #48
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...

This can't be voted high enough.

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

#79

Post by mbq »

purplefox wrote: post #55
bascule wrote: post #47

Earlier quoted context omitted.

"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 h…

Yes, I meant threads ;) E.g. A web server using node.js on a 32 core server. You would have to manually manage 32 instances of node, and use a load balancer or the cluster module in order to route requests to the instances. With vert.x you just start one instance and from the command line you tell it how many instances to start. It then scales over your cores, no glue code or cluster module to write. (There's an exam…

Having VM per core may be quite beneficial -- you get more fault tolerance, immunity to GC glitches and one tier less when scaling over several machines. And there are nice tools to manage multiple processes.
Post reply on HN