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. On Sunday, December 31, 2017 at 12:47:50 PM UTC-5, James Gatannah wrote: > > 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.
