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 > > 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. >>> 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 clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
