
Vert.x: A tool-kit for building reactive applications on the JVM - cfontes
http://vertx.io/
======
mmastrac
I built a fairly complex app in vert.x a few years back. If you don't start
with a promises library off the bat, you end up in a callback hell not unlike
node.js.

You also realize very quickly how synchronous many of the Java libraries for
things like databases, redis, etc are. The ecosystem just isn't built to work
like that, but that's not the fault of the vert.x guys.

~~~
merb
[http://vertx.io/docs/](http://vertx.io/docs/)

Vert.x provides the things like databases, redis, too. And no I don't use
Vert.x However in Java it isn't that hard anymore to make a Sync Library
Async, especially JDBC. Thanks to CompletableFuture on Java8, the problem is,
is that not lot's of companies are on Java8, however if you are using vert.x
that shouldn't be the case.

Libraries in Java are mostly Synchronous cause people use Java4, Java5, Java6,
Java7 and not Lambda's and Futures. I mean there are really libraries out
there who providing Java4 support. They provided Java3 Support until the end
of 2014.. Especially Libraries who are generating content are having backwards
compability to the beginnings.

Edit: Oh and the Vert.x JDBC Client is a wrapper around JDBC with RxJava /
Future's. Which is basically the best thing you could do. Edit2: Oh and what I
dislike more than synchronous code is code that has getters and setters, since
that makes it hard to wrap a library into a thread pool since mutable data
isn't a nice thing to deal with inside a async fashion. However it was
traditional to have getter and setter classes . But more and more this isn't
the case for newer things.

~~~
mmastrac
> However in Java it isn't that hard anymore to make a Sync Library Async

Not necessarily true. Sure you can create a set of worker threads that take
requests, process them synchronously, and hand stuff back but that's going to
inflate your thread count and it's nowhere as optimal as writing a library
that is async-aware from the first line of code.

On top of that, lots of Java code assumes that you'll be making various
sequenced calls from the same thread. You'll find that libraries will randomly
corrupt data or return stale reads if they haven't been synchronized properly.
Many protocols (ie: Redis) have built-in pipelining that isn't used in sync
libraries.

~~~
merb
> You'll find that libraries will randomly corrupt data or return stale reads
> if they haven't been synchronized properly

Yeah that's what I meant with my second edit. it's really really aweful if
libraries use a too mutual style.

------
fredliu
Vert.x indeed looks pretty cool. But I found it a little bit weird that they
used the term "reactive" in the title, but I'm not sure what the "reactive" is
referring to: maybe Reactive Extensions, or at least RxJava? which should be
perfect with vert.x to solve the callback hell problem. Or they just use it as
a generic term for async technology used in vert.x/node.js/tornado etc?

~~~
rdtsc
> But I found it a little bit weird that they used the term "reactive" in the
> title

"Reactive" is the new cool term that replaced "async" and "non-blocking" from
a few years ago.

For maximum impact it is advised to combine it with microservices (or even
unikernels) in the same sentence.

~~~
nostrademons
FWIW, "async" was called the "Reactor Pattern" in the Design Patterns world
back in 2000:

[https://en.wikipedia.org/wiki/Reactor_pattern](https://en.wikipedia.org/wiki/Reactor_pattern)

~~~
ttflee
But "(a)ll reactor systems are single threaded by definition"...

~~~
nostrademons
So is what we know of as "async" and "non-blocking". The point is that instead
of spinning up many blocking threads, a single select/poll/epoll() call
triggers a set of callbacks.

------
vorg
> Polyglot. You can use Vert.x with multiple languages. Vert.x doesn't preach
> about what language is best

Gradle should learn this lesson and also offer multiple languages for its
build scripts, and more people might adopt it.

------
randomThoughts9
How is the ceylon integration going? I've been waiting for that before diving
into vert.x 3.

------
hhimanshu
I enjoy working with Akka to build reactive applications. Clean, Readable,
Testable

