Officially support Vert.x

[Feuer Au]

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]

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]

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]

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]

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

clojure+u...@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+u...@googlegroups.com.

[Feuer Au]

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

clojure+u...@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+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

clojure+u...@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+u...@googlegroups.com.

[Timothy Baldridge]

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

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.

--

“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]

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]

Hi Toby:

We start working on Vert.x Clojure implementation

https://github.com/chengenzhao/vertx-lang-clojure

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

clojure+u...@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+u...@googlegroups.com.

[Feuer Au]

Hi Toby:

We just complete most parts of vertx-lang-clojure, here is the project address:

https://github.com/chengenzhao/vertx-lang-clojure

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

clojure+u...@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+u...@googlegroups.com.

[Feuer Au]

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]

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]

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]

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

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.

[Matching Socks]

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]

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.