Would be interested in any more concrete description of the problems? I'm considering using Vert.x in a project, mainly because of the polyglot features (ability to be extended by many different people some of who only know Python, others who only know Java and some who might only know Javascript, etc).
Classloader per verticle type makes dependency injection painful. "I don't know what a Spring "ApplicationContext" is" -- Tim Fox
Uses multiple classloaders so you can "run multiple versions of the same module at the same time". Not something I have ever done or would do.
Uses Hazelcast for clustering but uses tons of classloaders so using anything other than simple types in Hazelcast is hard and inefficient.
Message bus is tightly coupled to application cluster through Hazelcast.
Messaging is missing the most useful features of AMQP like wildcard topics and queues. Only possible to do very basic message routing. Many messages have to be sent multiple times to mimic advanced routing.
Dividing everything into 'verticles' encourages use of callbacks for everything. This increases code size and complexity which increases the need for testing. 'Callback hell'
Encourages polyglot programming.
Writing Vertx apps with Groovy makes me feel like I could add a whole chapter to 'How to Write Unmaintainable Code'.
Wow - thanks for taking the time to put those down.
Some of those I consider advantages - polyglot is the whole reason I looked into it, Groovy is the main language the app I'd be integrating it into is written in, callbacks are the mainstay of many other frameworks (try writing anything in Node.js without a callback!).
That the clustering is poorly designed is probably not an issue in itself since in my case it's a web server embedded in another app, but it's a concern that the framework isn't well thought out and I don't like that (it sounds like) the whole thing is heavily entangled with Hazelcast (which I have no need for, or interest in).
Hazelcast on it's own is pretty useful if you need a distributed data grid in Java although it's not without its quirks. Unfortunately it's much less useful in Vertx because of the classloaders.
Callbacks as an antipattern is one of the main points of this HN post.
Some of these "problems" aren't problems at all, e.g. what's wrong with polyglot programming?
> Writing Vertx apps with Groovy makes me feel like I could add a whole chapter to 'How to Write Unmaintainable Code'.
Vert.x enables many JVM languages to program it. Perhaps the real problem's with the language you've chosen. Groovy's business purpose is to ensure jobs (i.e. consulting contracts and conference seat sales) for life for its promoters at SpringSource. Choose a language with another mission and that could make all the difference.
> Vert.x enables many JVM languages to program it. Perhaps the real problem's with the language you've chosen. Groovy's business purpose is to ensure jobs (i.e. consulting contracts and conference seat sales) for life for its promoters at SpringSource. Choose a language with another mission and that could make all the difference.
The framework and the language are both problems in my opinion. If it was up to me I would have chosen a different framework, messaging system, language, and more. Wasn't my decision to make though.