Officially support Vert.x

458 views
Skip to first unread message

Feuer Au

unread,
Dec 28, 2017, 11:04:59 PM12/28/17
to Clojure
Hi All,

Curious about Vert.x is officially supported?

We tried to use some new languages on JVM e.g. Scala, Kotlin etc.

and be interested in using some relatively purely functional programming languages and so far Clojure is our best bet

but unfortunately couldn't find native Clojure api on Vert.x but got official support for Kotlin

so just wonder is there any official support for Vert.x in Clojure?

Cheers!
-- 

Toby Crawley

unread,
Dec 29, 2017, 7:50:53 AM12/29/17
to clo...@googlegroups.com
The short answer is no, there is no Clojure support for Vert.x 3 that I know of.

The longer answer: I wrote the Clojure language module for Vert.x 2, which had a pretty low usage rate, partially because core.async was released around the same time. When Vert.x 3 was being written, the Vert.x team asked me if I wanted to build a Clojure module for it. I declined because I didn't think there was enough interest to warrant the effort, and because Vert.x 3 moved to a code generation system for language modules that was geared towards object-oriented languages, which would have been difficult to use for generating a Clojure api.

- Toby


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gary Verhaegen

unread,
Dec 29, 2017, 8:11:34 AM12/29/17
to clo...@googlegroups.com
Is vert.x an absolute (external) requirement, or is that a tool you want to use to achieve some goal? If the latter, maybe there are other tools in the Clojure ecosystem that you could use instead?

Alan Moore

unread,
Dec 29, 2017, 7:17:59 PM12/29/17
to Clojure
As Gary said there are options if you aren’t tied to Vert.x.

Of course there is core.async but you might also take a look at Manifold:

http://aleph.io/manifold/rationale.html

Good luck!

Alan

Feuer Au

unread,
Dec 30, 2017, 10:24:46 AM12/30/17
to Clojure
Thanks Toby for the answer

We are thinking of using purely functional programming languages with Vert.x since we have already tasted some benefits from functional programmings e.g. using Kotlin/Scala top level functions etc. 

and it might not be only Clojure we try to import but also Haskell/eta-lang.org another candidate
therefor the polyglot supporting system is required and Vert.x is almost the only candidate we got

and we agree with you that it could be difficult to use the current existing codegen to generate functional programming apis
so what if we create another project based on vert.x code BUT using another codegen system to wrap current Vert.x api and generate functional programming language only apis?

On Friday, December 29, 2017 at 8:50:53 PM UTC+8, Toby Crawley wrote:
The short answer is no, there is no Clojure support for Vert.x 3 that I know of.

The longer answer: I wrote the Clojure language module for Vert.x 2, which had a pretty low usage rate, partially because core.async was released around the same time. When Vert.x 3 was being written, the Vert.x team asked me if I wanted to build a Clojure module for it. I declined because I didn't think there was enough interest to warrant the effort, and because Vert.x 3 moved to a code generation system for language modules that was geared towards object-oriented languages, which would have been difficult to use for generating a Clojure api.

- Toby

On Thu, Dec 28, 2017 at 10:53 PM, Feuer Au <chenge...@gmail.com> wrote:
Hi All,

Curious about Vert.x is officially supported?

We tried to use some new languages on JVM e.g. Scala, Kotlin etc.

and be interested in using some relatively purely functional programming languages and so far Clojure is our best bet

but unfortunately couldn't find native Clojure api on Vert.x but got official support for Kotlin

so just wonder is there any official support for Vert.x in Clojure?

Cheers!
-- 

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

Feuer Au

unread,
Dec 30, 2017, 10:31:47 AM12/30/17
to Clojure
Hmm....
yes it is almost an absolute requirement since we have already invested a lot in Java, Kotlin, Javascript and other languages based on Vert.x
and for Clojure & Haskell are pretty new candidates for us, we need to find a way to persuade our programmers to use these languages
and Vert.x is almost the only way to persuade our lovely programmers to give it a try
If we dont use Vert.x, those guys may resist to try a new language since they need to get used to many new softwares e.g. maven -> leiningen
some times people may not like changes^_^ 

On Friday, December 29, 2017 at 9:11:34 PM UTC+8, Gary Verhaegen wrote:
Is vert.x an absolute (external) requirement, or is that a tool you want to use to achieve some goal? If the latter, maybe there are other tools in the Clojure ecosystem that you could use instead?
On 29 December 2017 at 13:49, Toby Crawley <to...@tcrawley.org> wrote:
The short answer is no, there is no Clojure support for Vert.x 3 that I know of.

The longer answer: I wrote the Clojure language module for Vert.x 2, which had a pretty low usage rate, partially because core.async was released around the same time. When Vert.x 3 was being written, the Vert.x team asked me if I wanted to build a Clojure module for it. I declined because I didn't think there was enough interest to warrant the effort, and because Vert.x 3 moved to a code generation system for language modules that was geared towards object-oriented languages, which would have been difficult to use for generating a Clojure api.

- Toby

On Thu, Dec 28, 2017 at 10:53 PM, Feuer Au <chenge...@gmail.com> wrote:
Hi All,

Curious about Vert.x is officially supported?

We tried to use some new languages on JVM e.g. Scala, Kotlin etc.

and be interested in using some relatively purely functional programming languages and so far Clojure is our best bet

but unfortunately couldn't find native Clojure api on Vert.x but got official support for Kotlin

so just wonder is there any official support for Vert.x in Clojure?

Cheers!
-- 

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

Timothy Baldridge

unread,
Dec 30, 2017, 12:17:27 PM12/30/17
to clo...@googlegroups.com
Multi-process polyglot systems I understand, they aren't common, but I've seen them. In most cases, immutable queues and HTTP APIs work great. But (and pardon my bluntness), why would I ever want a polyglot single process system? That sounds like a major design mis-step. The overhead of mental context switching would be rather oppressive, not to mention the problem of finding new hires that know all the languages you use on your service. Additionally, systems like Vert.x that try to provide a common IO layer for a bunch of languages end up catering to a lowest common denominator. When I last looked at Vert.x I was struck by how little of the platform I needed because Clojure properly handled things like concurrency and data-first programming. 

So I'd caution about making polyglot single-process systems a "requirement". I've been building systems for years and rarely encountered a problem that required more than one language, and those that did worked great via communicating via queues (even in-memory queues), DBs and HTTP. 

Timothy


For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

James Gatannah

unread,
Dec 31, 2017, 12:47:50 PM12/31/17
to Clojure
Disclaimer: I once spent 3-4 weeks studying Vert.x's design philosophy and architecture. So I'm hardly an expert.


On Saturday, December 30, 2017 at 9:31:47 AM UTC-6, Feuer Au wrote:
Hmm....
yes it is almost an absolute requirement since we have already invested a lot in Java, Kotlin, Javascript and other languages based on Vert.x

I think there's a very important open question here: *what* are you actually using Vert.x for?
 
and for Clojure & Haskell are pretty new candidates for us, we need to find a way to persuade our programmers to use these languages
and Vert.x is almost the only way to persuade our lovely programmers to give it a try
 
If we dont use Vert.x, those guys may resist to try a new language since they need to get used to many new softwares e.g. maven -> leiningen
some times people may not like changes^_^ 

It's been my experience that, if you have to persuade the programmers to use clojure, they probably aren't going to approach it correctly.

They'll try to write it the same way they'd write java. Then they'll decide that it's awful because the startup time is too slow, the syntax is too weird, and the immutable data structures add a lot of overhead for no real benefit.

Now, if you have someone on the team who's already realized that there are a ton of benefits (like stability in production, much faster development time, fewer bugs, less code to maintain, and general developer happiness all come to mind), then allowing them to show the others the benefits is a great option.

But someone on the team really needs to already  understand that this *is* a better way.
 
Now, building on what other people have already written:

If you have a bunch of separate stand-alone microservices that are using vert.x to communicate, there's no reason you couldn't write one in clojure. Just call the Vert.x pieces the way you would any other Java library. I don't know how much effort would be involved in getting it to play nicely with the actual Vert.x ecosystem. It's been a while since I looked at this, but I remember that one of the main selling points was the ability to spin verticles up and down on demand.

That sort of thing really isn't clojure's strength. It's really meant to be part of a process that runs for months or years. You don't have to use it that way, of course, and I bet plenty of others on this list are not. But, if you need something that automatically scales up pretty much instantly when demand increases, then clojure may not be your best bet.

And, if you don't, then why are you using Vert.x?

For me, trying to use Vert.x with clojure was incredibly frustrating. In a lot of ways, it felt like they're trying to solve the same basic problems in two totally different ways. 

One of clojure's main selling points is sane multi-threading. Using that involves fighting the Vert.x ecosystem, which is at least partially based on the premise that multi-threading is sheer evil and should really be avoided. I never really into this, because I barely scratched the surface, and it seemed like a really nasty can of worms to unleash.

As others have said, a huge chunk of what Vert.x provides is already baked into clojure. But the different approaches really aren't compatible. So you'll be fighting either the language or the library on some pretty fundamental decisions.

The one useful thing I could find that Vert.x provides out of the box that clojure doesn't is the pub/sub messaging. That turned our architecture into spaghetti, so I wouldn't call it a win.

Then, yeah, there's the codegen thing which is the part you're really asking about.

Why would anyone use an external codegen tool for a lisp? You already have [arguably] the best codegen tool the world has run across baked into the language, in the form of macros.

If I really had to use Vert.x (and I was working in a polyglot environment where this was an option), I'd just write stand-alone clojure microservices that used Vert.x as a communications library. Then I'd point out how much time/energy is being wasted on the java/kotlin portions.

BTW, your devs can still use maven instead of leiningen/boot. That's usually just an example of using old, comfortable approaches instead of embracing what's new and different. Depending on how your project(s) is/are set up, it might actually make sense (though I strongly suspect that boot would be a better option).

Regards,
James

Feuer Au

unread,
Jan 9, 2018, 9:47:32 AM1/9/18
to Clojure
Hi Toby:

We start working on Vert.x Clojure implementation
and for now we have made some progresses
now we could generate "Hello from Vert.x!" example and deploy ClojureVerticle and the clojure code wrapper is almost there
(ns examples.simple-http-server)

(require
'[io.vertx.clojure.core :as vertx.core]
'[io.vertx.clojure.vertx :as vertx.vertx]
'[io.vertx.clojure.http-server :as server]
'[io.vertx.clojure.http-server-request :as request]
'[io.vertx.clojure.http-server-response :as response])

(defn handle-request [req]
(response/end
(request/response req)
"Hello from Vert.x!"))

(defn start [vertx]
do
(def http-server (vertx.vertx/create-http-server vertx))
(server/request-handler http-server (vertx.core/handler handle-request))
(server/listen http-server 8080))

as you posted two or three years ago, https://groups.google.com/forum/?fromgroups=#!topic/vertx/0X5hSlAHw18
and for now, do you still have time to help us like give us a roadmap or checklist to complete the Vert.x language support?

Thanks

On Friday, December 29, 2017 at 8:50:53 PM UTC+8, Toby Crawley wrote:
The short answer is no, there is no Clojure support for Vert.x 3 that I know of.

The longer answer: I wrote the Clojure language module for Vert.x 2, which had a pretty low usage rate, partially because core.async was released around the same time. When Vert.x 3 was being written, the Vert.x team asked me if I wanted to build a Clojure module for it. I declined because I didn't think there was enough interest to warrant the effort, and because Vert.x 3 moved to a code generation system for language modules that was geared towards object-oriented languages, which would have been difficult to use for generating a Clojure api.

- Toby

On Thu, Dec 28, 2017 at 10:53 PM, Feuer Au <chenge...@gmail.com> wrote:
Hi All,

Curious about Vert.x is officially supported?

We tried to use some new languages on JVM e.g. Scala, Kotlin etc.

and be interested in using some relatively purely functional programming languages and so far Clojure is our best bet

but unfortunately couldn't find native Clojure api on Vert.x but got official support for Kotlin

so just wonder is there any official support for Vert.x in Clojure?

Cheers!
-- 

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

Feuer Au

unread,
Jan 10, 2018, 5:18:21 AM1/10/18
to Clojure
Hi Toby:

We just complete most parts of vertx-lang-clojure, here is the project address:
all reviews and suggestions and issues and PRs are welcomed

Cheers


On Friday, December 29, 2017 at 8:50:53 PM UTC+8, Toby Crawley wrote:
The short answer is no, there is no Clojure support for Vert.x 3 that I know of.

The longer answer: I wrote the Clojure language module for Vert.x 2, which had a pretty low usage rate, partially because core.async was released around the same time. When Vert.x 3 was being written, the Vert.x team asked me if I wanted to build a Clojure module for it. I declined because I didn't think there was enough interest to warrant the effort, and because Vert.x 3 moved to a code generation system for language modules that was geared towards object-oriented languages, which would have been difficult to use for generating a Clojure api.

- Toby

On Thu, Dec 28, 2017 at 10:53 PM, Feuer Au <chenge...@gmail.com> wrote:
Hi All,

Curious about Vert.x is officially supported?

We tried to use some new languages on JVM e.g. Scala, Kotlin etc.

and be interested in using some relatively purely functional programming languages and so far Clojure is our best bet

but unfortunately couldn't find native Clojure api on Vert.x but got official support for Kotlin

so just wonder is there any official support for Vert.x in Clojure?

Cheers!
-- 

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

Feuer Au

unread,
Jan 10, 2018, 5:25:08 AM1/10/18
to Clojure
And here is the simple example "Hello from Vert.x!" like other languages on the Vert.x official frontpage:
(ns examples.simple-http-server)

(require
'[io.vertx.clojure.core.core :as core]
'[io.vertx.lang.clojure.vertx :as vertx]
'[io.vertx.lang.clojure.http-server :as server]
'[io.vertx.lang.clojure.http-server-request :as request]
'[io.vertx.lang.clojure.http-server-response :as response])

(defn handle-request [req]
do
(def response (request/response req))
(response/put-header response "content-type" "text/plain")
(response/end response"Hello from Vert.x!"))

(defn start [vertx]
do
(def http-server (vertx/create-http-server vertx))
(server/request-handler http-server (core/handler handle-request))
(server/listen http-server 8080))
Pretty straight forward, but we could make it better
e.g. combine different namespaces into one single would be nice 
and we got pure functions in different namespaces 
hmmm...., it looks nice.

Gary Verhaegen

unread,
Jan 10, 2018, 5:52:53 AM1/10/18
to clo...@googlegroups.com
It’s not clear what the "do" is supposed to mean in those defns (unless there’s some deep dark magic going on, they are currently not doing anything and you can just remove them), and you very likely want "let" instead of "def" for the local variables.

def in Clojure does not follow lexical scoping rules; it’s always a global name.
--

Feuer Au

unread,
Jan 10, 2018, 8:47:36 AM1/10/18
to Clojure
Thanks a lot
we modify the hello code to following:
(ns examples.simple-http-server)

(require
'[io.vertx.clojure.core.core :as core]
'[io.vertx.lang.clojure.vertx :as vertx]
'[io.vertx.lang.clojure.http-server :as server]
'[io.vertx.lang.clojure.http-server-request :as request]
'[io.vertx.lang.clojure.http-server-response :as response])

(defn handle-request [req]
  (let [response (request/response req)]

(response/put-header response "content-type" "text/plain")
    (response/end response "Hello from Vert.x!")))

(defn start [vertx]
(let [http-server (vertx/create-http-server vertx)]
(server/request-handler http-server (core/handler handle-request))
(server/listen http-server 8080)))

and we also have one problem

Timothy Baldridge

unread,
Jan 10, 2018, 8:53:13 AM1/10/18
to clo...@googlegroups.com
A few other points of design:

1) Move the requires into the `ns` form:

(ns example.simple-http-server
  (:require [io.vertx.clojure.core.core :as core]
                [io.vertex.lang.clojure.vertx :as vertx]))

2) If you make sure that your functions always return the first argument passed to them you can leverage the `->` macro:

(-> req
     request/response
     (response/put-header "content-type" "text/plain")
     (response/end "Hello from Vert.x!"))


Just some things to think over.

Timothy


For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Matching Socks

unread,
Jan 10, 2018, 7:15:22 PM1/10/18
to Clojure
How do the aims of this undertaking compare with Pedestal?

http://pedestal.io/ says, "Pedestal supports Tomcat, Jetty, Immutant (with Undertow), Vert.x, ..."


lawrence...@gmail.com

unread,
Jan 16, 2018, 4:20:42 PM1/16/18
to Clojure
James Gatannah,

I apologize for hijacking this thread, but what did you mean here: 

> The one useful thing I could find that Vert.x provides out of the box 
> that clojure doesn't is the pub/sub messaging. That turned our 
> architecture into spaghetti, so I wouldn't call it a win.

Was there something specific about Vert.x that made pub/sub difficult, or did you find that pub/sub itself, as a pattern, undermined your architecture? I've used pub/sub among small sets of microservices (5 or 6 services) and it worked well, though I'd be curious to hear from someone who tried to use it with hundreds of services. 
Reply all
Reply to author
Forward
0 new messages