Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[Zach Tellman]

This is incidental to the topic of the thread, but to address why Manifold 
exists when there's already core.async, there's a write-up of the rationale 
linked in the readme: http://aleph.io/manifold/rationale.html.

On Saturday, January 23, 2016 at 6:50:34 AM UTC-5, qsys wrote:
>
> Depends on what you want... what I really like is the easy modularity: 
> deploy new 'verticles' somewhere in your network, and they're just all 
> connected through a the eventbus. I make a 'new' module, I put it somewhere 
> and it's automatically picked up by the appication and I can communicate 
> with it using that event bus. Is there something similar in clojure, or can 
> I achieve something similar in clojure? I checked 
> - catacumba: web toolkit, not what I'm after
> - sente: is about the web
> - aleph: comes closer: does have tcp-servers, but no autodiscovery, and 
> well, no 'event bus' (a kind of wrapper around netty etc).
> - manifold: I don't really see the added value, having core.async - but I 
> may fail to see something important here
> - pomegranate: is possibly very interesting in adding new modules... not 
> for removing 'old versions' of a module.
> - pedestal: have to have a deeper look into it, but so far, I have a 
> feeling it's more about web than 'intra-program' communication
>
> So, so far, I don't see how to implement something like the vert.x event 
> bus, with autodiscovery, in clojure (although I would love to see something 
> like it), expanding to the browser. I don't mind (and prefer) composing it 
> using different libraries, but I feel to see how to have this functionality 
> in clojure (now, I wrap the vertx eventbus in my clojure programs), and 
> since I already load vertx for the eventbus, I use it as web server as 
> well, if I need one... So well, if someone has an idea, it might be a nice 
> project I'd love to work on :).
>
> thx, qsys
>
> Op zondag 3 januari 2016 22:25:04 UTC+1 schreef tbc++:
>>
>> I've done some evaluations of Vert.x in the past and was rather 
>> underwhelmed. What is it that you are trying to accomplish? Stuff like 
>> Pedestal offers async web services, but without the complexity of an 
>> traditional evented server. So perhaps if we had a better idea of your 
>> requirements we could be a bit more helpful.
>>
>> So I'd say, look into Pedestal and then define what you need that it 
>> cannot do. Same for other toolkits like ring and httpkit. 
>>
>> Timothy
>>
>> On Sun, Jan 3, 2016 at 12:59 PM, adrians  wrote:
>>
>>>
>>> It used to be that Vert.x 2.x had integration for Clojure, but version 
>>> 3.x hasn't added it yet. Has anyone used this version through the Java API 
>>> and if so, how painful was it? Is Reactor any 
>>> better in that respect? What are people using when they want this kind of 
>>> back end?
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> “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) 
>>
>

-- 
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.

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[Fabio T.]

My pleasure!

Please consider that the Galaxy memory grid project, which provides 
integration out-of-the-box with Quasar/Pulsar actors for networking, 
distribution and even migration (but is not by any means the only possible 
one), is not considered production-ready yet at this stage even though a 
lot of work is going into it at present for it to become so. On the other 
hand Quasar/Pulsar are production-ready instead and are used by e.g. 
Pinterest  and BrainTree 
.

Notice: I'm part of the Parallel Universe team.

-- Fabio

On Tuesday, January 26, 2016 at 4:29:09 PM UTC+2, qsys wrote:
>
> Now, Pulsar looks something more like it: messaging, clustering between 
> machines. It even feels a bit like what vertx is doing, at first glance. 
> Having a kind of 'inter-machine core.async channels' is awesome. This can 
> easily replace the 'vertx eventbus'. Really cool!
>
> Thanks a lot, Fabio!
> qsys
>
> Op maandag 25 januari 2016 14:12:42 UTC+1 schreef Fabio T.:
>>
>> Hi,
>>
>> I agree it really depends what you're looking for. If you're especially 
>> looking for async performance then I think you can't go wrong with Pulsar 
>>  which is a Clojure language 
>> integration module + a thin, idiomatic wrapper around Quasar 
>>  (which supports Java and Kotlin 
>>  for now, in future any JVM language). 
>> Quasar/Pulsar give you fibers 
>>  (so no need for async 
>> APIs and related complications), Go-like channels 
>> , Erlang-like actors 
>>  and 
>> dataflow 
>> . 
>> You can also mix threads and fibers freely (there's an integration of 
>> java.util.concurrent 
>> 
>>  
>> as well, should you be interested).
>>
>> With Pulsar you can have automatic instrumentation 
>>  and 
>> there are some useful Clojure/Pulsar-specific integrations in Comsat 
>>  already, like a jetty-fiber 
>> ring adapter  and 
>> a fiber HTTP client based on httpkit 
>> . There's also a 
>> full-blown core.async  
>> implentation based on fibers, so you don't need to use "go" block to have 
>> async-like performance.
>>
>> vert.x  itself now has an integration with Quasar 
>> called vertx-sync  but for the 
>> moment is Java-only.
>>
>> -- Fabio
>>
>> On Sunday, January 3, 2016 at 9:59:39 PM UTC+2, adrians wrote:
>>>
>>>
>>> It used to be that Vert.x 2.x had integration for Clojure, but version 
>>> 3.x hasn't added it yet. Has anyone used this version through the Java API 
>>> and if so, how painful was it? Is Reactor any 
>>> better in that respect? What are people using when they want this kind of 
>>> back end?
>>>
>>

-- 
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.

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[qsys]

Now, Pulsar looks something more like it: messaging, clustering between 
machines. It even feels a bit like what vertx is doing, at first glance. 
Having a kind of 'inter-machine core.async channels' is awesome. This can 
easily replace the 'vertx eventbus'. Really cool!

Thanks a lot, Fabio!
qsys

Op maandag 25 januari 2016 14:12:42 UTC+1 schreef Fabio T.:
>
> Hi,
>
> I agree it really depends what you're looking for. If you're especially 
> looking for async performance then I think you can't go wrong with Pulsar 
>  which is a Clojure language 
> integration module + a thin, idiomatic wrapper around Quasar 
>  (which supports Java and Kotlin 
>  for now, in future any JVM language). 
> Quasar/Pulsar give you fibers 
>  (so no need for async 
> APIs and related complications), Go-like channels 
> , Erlang-like actors 
>  and 
> dataflow 
> . 
> You can also mix threads and fibers freely (there's an integration of 
> java.util.concurrent 
> 
>  
> as well, should you be interested).
>
> With Pulsar you can have automatic instrumentation 
>  and 
> there are some useful Clojure/Pulsar-specific integrations in Comsat 
>  already, like a jetty-fiber 
> ring adapter  and a 
> fiber HTTP 
> client based on httpkit 
> . There's also a 
> full-blown core.async  
> implentation based on fibers, so you don't need to use "go" block to have 
> async-like performance.
>
> vert.x  itself now has an integration with Quasar 
> called vertx-sync  but for the 
> moment is Java-only.
>
> -- Fabio
>
> On Sunday, January 3, 2016 at 9:59:39 PM UTC+2, adrians wrote:
>>
>>
>> It used to be that Vert.x 2.x had integration for Clojure, but version 
>> 3.x hasn't added it yet. Has anyone used this version through the Java API 
>> and if so, how painful was it? Is Reactor any 
>> better in that respect? What are people using when they want this kind of 
>> back end?
>>
>

-- 
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.

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[Fabio T.]

Hi,

I agree it really depends what you're looking for. If you're especially 
looking for async performance then I think you can't go wrong with Pulsar 
 which is a Clojure language 
integration module + a thin, idiomatic wrapper around Quasar 
 (which supports Java and Kotlin 
 for now, in future any JVM language). 
Quasar/Pulsar give you fibers 
 (so no need for async APIs 
and related complications), Go-like channels 
, Erlang-like actors 
 and dataflow 
. 
You can also mix threads and fibers freely (there's an integration of 
java.util.concurrent 

 
as well, should you be interested).

With Pulsar you can have automatic instrumentation 
 and 
there are some useful Clojure/Pulsar-specific integrations in Comsat 
 already, like a jetty-fiber ring 
adapter  and a fiber HTTP 
client based on httpkit 
. There's also a 
full-blown core.async  
implentation based on fibers, so you don't need to use "go" block to have 
async-like performance.

vert.x  itself now has an integration with Quasar called 
vertx-sync  but for the moment is 
Java-only.

-- Fabio

On Sunday, January 3, 2016 at 9:59:39 PM UTC+2, adrians wrote:
>
>
> It used to be that Vert.x 2.x had integration for Clojure, but version 3.x 
> hasn't added it yet. Has anyone used this version through the Java API and 
> if so, how painful was it? Is Reactor any 
> better in that respect? What are people using when they want this kind of 
> back end?
>

-- 
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.

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[Timur]

Yes +1 to qsys, such a library would be quite useful and enable using 
Clojure in additional enterprise settings. 

Regards,

Timur

On Saturday, January 23, 2016 at 9:50:45 PM UTC+1, qsys wrote:
>
> True, hazelcast, or JGroups, in vertx 3 for clustering/autodiscovery. It 
> may be 'easy' to implement, but it has been quite nicely wrapped, together 
> with netty messaging (not only pub-sub) in vert.x, having connectors to 
> 'pure TCP', websockets etc. I have been thinking of doing something similar 
> in clojure, but never got to it...
> Anyway, I'd love to see some kind of 'runtime modularity', on one machine 
> or even one JVM would do as a start (no autodiscovery/clustering 
> necessary).  That's the thing that makes vertx, to me, useful. I'm pretty 
> sure it's possible with the existing clojure libraries etc, but I don't see 
> it yet. That's another thread, though.
>
> thx, qsys
>
>
> Op zaterdag 23 januari 2016 17:21:03 UTC+1 schreef Andrey Antukh:
>>
>> The eventbus of vert.x as far as I know is implemented on top of 
>> hazelcast[1] that you already can use from clojure. 
>>
>> Make a eventbus like concept on top of hazelcast is pretty easy and it 
>> already gives you the autodiscovery and all the "clustering" stuff for free.
>>
>> [1]; http://hazelcast.org/use-cases/messaging/
>>
>> Andrey
>>
>> On Sat, Jan 23, 2016 at 1:50 PM, qsys  wrote:
>>
>>> Depends on what you want... what I really like is the easy modularity: 
>>> deploy new 'verticles' somewhere in your network, and they're just all 
>>> connected through a the eventbus. I make a 'new' module, I put it somewhere 
>>> and it's automatically picked up by the appication and I can communicate 
>>> with it using that event bus. Is there something similar in clojure, or can 
>>> I achieve something similar in clojure? I checked 
>>> - catacumba: web toolkit, not what I'm after
>>> - sente: is about the web
>>> - aleph: comes closer: does have tcp-servers, but no autodiscovery, and 
>>> well, no 'event bus' (a kind of wrapper around netty etc).
>>> - manifold: I don't really see the added value, having core.async - but 
>>> I may fail to see something important here
>>> - pomegranate: is possibly very interesting in adding new modules... not 
>>> for removing 'old versions' of a module.
>>> - pedestal: have to have a deeper look into it, but so far, I have a 
>>> feeling it's more about web than 'intra-program' communication
>>>
>>> So, so far, I don't see how to implement something like the vert.x event 
>>> bus, with autodiscovery, in clojure (although I would love to see something 
>>> like it), expanding to the browser. I don't mind (and prefer) composing it 
>>> using different libraries, but I feel to see how to have this functionality 
>>> in clojure (now, I wrap the vertx eventbus in my clojure programs), and 
>>> since I already load vertx for the eventbus, I use it as web server as 
>>> well, if I need one... So well, if someone has an idea, it might be a nice 
>>> project I'd love to work on :).
>>>
>>> thx, qsys
>>>
>>> Op zondag 3 januari 2016 22:25:04 UTC+1 schreef tbc++:

 I've done some evaluations of Vert.x in the past and was rather 
 underwhelmed. What is it that you are trying to accomplish? Stuff like 
 Pedestal offers async web services, but without the complexity of an 
 traditional evented server. So perhaps if we had a better idea of your 
 requirements we could be a bit more helpful.

 So I'd say, look into Pedestal and then define what you need that it 
 cannot do. Same for other toolkits like ring and httpkit. 

 Timothy

 On Sun, Jan 3, 2016 at 12:59 PM, adrians  wrote:

>
> It used to be that Vert.x 2.x had integration for Clojure, but version 
> 3.x hasn't added it yet. Has anyone used this version through the Java 
> API 
> and if so, how painful was it? Is Reactor any 
> better in that respect? What are people using when they want this kind of 
> back end?
>
> -- 
> 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.
>



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

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[qsys]

True, hazelcast, or JGroups, in vertx 3 for clustering/autodiscovery. It 
may be 'easy' to implement, but it has been quite nicely wrapped, together 
with netty messaging (not only pub-sub) in vert.x, having connectors to 
'pure TCP', websockets etc. I have been thinking of doing something similar 
in clojure, but never got to it...
Anyway, I'd love to see some kind of 'runtime modularity', on one machine 
or even one JVM would do as a start (no autodiscovery/clustering 
necessary).  That's the thing that makes vertx, to me, useful. I'm pretty 
sure it's possible with the existing clojure libraries etc, but I don't see 
it yet. That's another thread, though.

thx, qsys


Op zaterdag 23 januari 2016 17:21:03 UTC+1 schreef Andrey Antukh:
>
> The eventbus of vert.x as far as I know is implemented on top of 
> hazelcast[1] that you already can use from clojure. 
>
> Make a eventbus like concept on top of hazelcast is pretty easy and it 
> already gives you the autodiscovery and all the "clustering" stuff for free.
>
> [1]; http://hazelcast.org/use-cases/messaging/
>
> Andrey
>
> On Sat, Jan 23, 2016 at 1:50 PM, qsys > 
> wrote:
>
>> Depends on what you want... what I really like is the easy modularity: 
>> deploy new 'verticles' somewhere in your network, and they're just all 
>> connected through a the eventbus. I make a 'new' module, I put it somewhere 
>> and it's automatically picked up by the appication and I can communicate 
>> with it using that event bus. Is there something similar in clojure, or can 
>> I achieve something similar in clojure? I checked 
>> - catacumba: web toolkit, not what I'm after
>> - sente: is about the web
>> - aleph: comes closer: does have tcp-servers, but no autodiscovery, and 
>> well, no 'event bus' (a kind of wrapper around netty etc).
>> - manifold: I don't really see the added value, having core.async - but I 
>> may fail to see something important here
>> - pomegranate: is possibly very interesting in adding new modules... not 
>> for removing 'old versions' of a module.
>> - pedestal: have to have a deeper look into it, but so far, I have a 
>> feeling it's more about web than 'intra-program' communication
>>
>> So, so far, I don't see how to implement something like the vert.x event 
>> bus, with autodiscovery, in clojure (although I would love to see something 
>> like it), expanding to the browser. I don't mind (and prefer) composing it 
>> using different libraries, but I feel to see how to have this functionality 
>> in clojure (now, I wrap the vertx eventbus in my clojure programs), and 
>> since I already load vertx for the eventbus, I use it as web server as 
>> well, if I need one... So well, if someone has an idea, it might be a nice 
>> project I'd love to work on :).
>>
>> thx, qsys
>>
>> Op zondag 3 januari 2016 22:25:04 UTC+1 schreef tbc++:
>>>
>>> I've done some evaluations of Vert.x in the past and was rather 
>>> underwhelmed. What is it that you are trying to accomplish? Stuff like 
>>> Pedestal offers async web services, but without the complexity of an 
>>> traditional evented server. So perhaps if we had a better idea of your 
>>> requirements we could be a bit more helpful.
>>>
>>> So I'd say, look into Pedestal and then define what you need that it 
>>> cannot do. Same for other toolkits like ring and httpkit. 
>>>
>>> Timothy
>>>
>>> On Sun, Jan 3, 2016 at 12:59 PM, adrians  wrote:
>>>

 It used to be that Vert.x 2.x had integration for Clojure, but version 
 3.x hasn't added it yet. Has anyone used this version through the Java API 
 and if so, how painful was it? Is Reactor any 
 better in that respect? What are people using when they want this kind of 
 back end?

 -- 
 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.

>>>
>>>
>>>
>>> -- 
>>> “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) 
>>>
>> -- 
>> 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 un

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[Mark Mandel]

+1 to what Andrey said.

You could also run Redis as a backend and use it's pubsub service [1], if
being more language agnostic is more your thing.

Depending on where you are hosting, you could also use a hosted pubsub
mechanism, such as Google Cloud PubSub[2] or AWS SNS[3].

There are definitely lots of ways to solve this particular problem outside
of vert.x

[1]: http://redis.io/topics/pubsub
[2]: https://cloud.google.com/pubsub/docs
[3]: https://aws.amazon.com/sns/faqs/

On 23 January 2016 at 08:20, Andrey Antukh  wrote:

> The eventbus of vert.x as far as I know is implemented on top of
> hazelcast[1] that you already can use from clojure.
>
> Make a eventbus like concept on top of hazelcast is pretty easy and it
> already gives you the autodiscovery and all the "clustering" stuff for free.
>
> [1]; http://hazelcast.org/use-cases/messaging/
>
> Andrey
>
> On Sat, Jan 23, 2016 at 1:50 PM, qsys  wrote:
>
>> Depends on what you want... what I really like is the easy modularity:
>> deploy new 'verticles' somewhere in your network, and they're just all
>> connected through a the eventbus. I make a 'new' module, I put it somewhere
>> and it's automatically picked up by the appication and I can communicate
>> with it using that event bus. Is there something similar in clojure, or can
>> I achieve something similar in clojure? I checked
>> - catacumba: web toolkit, not what I'm after
>> - sente: is about the web
>> - aleph: comes closer: does have tcp-servers, but no autodiscovery, and
>> well, no 'event bus' (a kind of wrapper around netty etc).
>> - manifold: I don't really see the added value, having core.async - but I
>> may fail to see something important here
>> - pomegranate: is possibly very interesting in adding new modules... not
>> for removing 'old versions' of a module.
>> - pedestal: have to have a deeper look into it, but so far, I have a
>> feeling it's more about web than 'intra-program' communication
>>
>> So, so far, I don't see how to implement something like the vert.x event
>> bus, with autodiscovery, in clojure (although I would love to see something
>> like it), expanding to the browser. I don't mind (and prefer) composing it
>> using different libraries, but I feel to see how to have this functionality
>> in clojure (now, I wrap the vertx eventbus in my clojure programs), and
>> since I already load vertx for the eventbus, I use it as web server as
>> well, if I need one... So well, if someone has an idea, it might be a nice
>> project I'd love to work on :).
>>
>> thx, qsys
>>
>> Op zondag 3 januari 2016 22:25:04 UTC+1 schreef tbc++:
>>>
>>> I've done some evaluations of Vert.x in the past and was rather
>>> underwhelmed. What is it that you are trying to accomplish? Stuff like
>>> Pedestal offers async web services, but without the complexity of an
>>> traditional evented server. So perhaps if we had a better idea of your
>>> requirements we could be a bit more helpful.
>>>
>>> So I'd say, look into Pedestal and then define what you need that it
>>> cannot do. Same for other toolkits like ring and httpkit.
>>>
>>> Timothy
>>>
>>> On Sun, Jan 3, 2016 at 12:59 PM, adrians  wrote:
>>>

 It used to be that Vert.x 2.x had integration for Clojure, but version
 3.x hasn't added it yet. Has anyone used this version through the Java API
 and if so, how painful was it? Is Reactor any
 better in that respect? What are people using when they want this kind of
 back end?

 --
 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.

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

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[Andrey Antukh]

The eventbus of vert.x as far as I know is implemented on top of
hazelcast[1] that you already can use from clojure.

Make a eventbus like concept on top of hazelcast is pretty easy and it
already gives you the autodiscovery and all the "clustering" stuff for free.

[1]; http://hazelcast.org/use-cases/messaging/

Andrey

On Sat, Jan 23, 2016 at 1:50 PM, qsys  wrote:

> Depends on what you want... what I really like is the easy modularity:
> deploy new 'verticles' somewhere in your network, and they're just all
> connected through a the eventbus. I make a 'new' module, I put it somewhere
> and it's automatically picked up by the appication and I can communicate
> with it using that event bus. Is there something similar in clojure, or can
> I achieve something similar in clojure? I checked
> - catacumba: web toolkit, not what I'm after
> - sente: is about the web
> - aleph: comes closer: does have tcp-servers, but no autodiscovery, and
> well, no 'event bus' (a kind of wrapper around netty etc).
> - manifold: I don't really see the added value, having core.async - but I
> may fail to see something important here
> - pomegranate: is possibly very interesting in adding new modules... not
> for removing 'old versions' of a module.
> - pedestal: have to have a deeper look into it, but so far, I have a
> feeling it's more about web than 'intra-program' communication
>
> So, so far, I don't see how to implement something like the vert.x event
> bus, with autodiscovery, in clojure (although I would love to see something
> like it), expanding to the browser. I don't mind (and prefer) composing it
> using different libraries, but I feel to see how to have this functionality
> in clojure (now, I wrap the vertx eventbus in my clojure programs), and
> since I already load vertx for the eventbus, I use it as web server as
> well, if I need one... So well, if someone has an idea, it might be a nice
> project I'd love to work on :).
>
> thx, qsys
>
> Op zondag 3 januari 2016 22:25:04 UTC+1 schreef tbc++:
>>
>> I've done some evaluations of Vert.x in the past and was rather
>> underwhelmed. What is it that you are trying to accomplish? Stuff like
>> Pedestal offers async web services, but without the complexity of an
>> traditional evented server. So perhaps if we had a better idea of your
>> requirements we could be a bit more helpful.
>>
>> So I'd say, look into Pedestal and then define what you need that it
>> cannot do. Same for other toolkits like ring and httpkit.
>>
>> Timothy
>>
>> On Sun, Jan 3, 2016 at 12:59 PM, adrians  wrote:
>>
>>>
>>> It used to be that Vert.x 2.x had integration for Clojure, but version
>>> 3.x hasn't added it yet. Has anyone used this version through the Java API
>>> and if so, how painful was it? Is Reactor any
>>> better in that respect? What are people using when they want this kind of
>>> back end?
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> “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)
>>
> --
> 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.
>



-- 
Andrey Antukh - Андрей Антух - 
http://www.niwi.nz
https://github.com/niwinz

-- 
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 thi

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[qsys]

Depends on what you want... what I really like is the easy modularity: 
deploy new 'verticles' somewhere in your network, and they're just all 
connected through a the eventbus. I make a 'new' module, I put it somewhere 
and it's automatically picked up by the appication and I can communicate 
with it using that event bus. Is there something similar in clojure, or can 
I achieve something similar in clojure? I checked 
- catacumba: web toolkit, not what I'm after
- sente: is about the web
- aleph: comes closer: does have tcp-servers, but no autodiscovery, and 
well, no 'event bus' (a kind of wrapper around netty etc).
- manifold: I don't really see the added value, having core.async - but I 
may fail to see something important here
- pomegranate: is possibly very interesting in adding new modules... not 
for removing 'old versions' of a module.
- pedestal: have to have a deeper look into it, but so far, I have a 
feeling it's more about web than 'intra-program' communication

So, so far, I don't see how to implement something like the vert.x event 
bus, with autodiscovery, in clojure (although I would love to see something 
like it), expanding to the browser. I don't mind (and prefer) composing it 
using different libraries, but I feel to see how to have this functionality 
in clojure (now, I wrap the vertx eventbus in my clojure programs), and 
since I already load vertx for the eventbus, I use it as web server as 
well, if I need one... So well, if someone has an idea, it might be a nice 
project I'd love to work on :).

thx, qsys

Op zondag 3 januari 2016 22:25:04 UTC+1 schreef tbc++:
>
> I've done some evaluations of Vert.x in the past and was rather 
> underwhelmed. What is it that you are trying to accomplish? Stuff like 
> Pedestal offers async web services, but without the complexity of an 
> traditional evented server. So perhaps if we had a better idea of your 
> requirements we could be a bit more helpful.
>
> So I'd say, look into Pedestal and then define what you need that it 
> cannot do. Same for other toolkits like ring and httpkit. 
>
> Timothy
>
> On Sun, Jan 3, 2016 at 12:59 PM, adrians > 
> wrote:
>
>>
>> It used to be that Vert.x 2.x had integration for Clojure, but version 
>> 3.x hasn't added it yet. Has anyone used this version through the Java API 
>> and if so, how painful was it? Is Reactor any 
>> better in that respect? What are people using when they want this kind of 
>> back end?
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> “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) 
>

-- 
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.

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[René Groß]

Maybe https://github.com/ptaoussanis/sente could be of interest for you.

Client library is included, which runs on websockets (if available), 
otherwise it will fallback to ajax.

>
>

-- 
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.

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[Andrey Antukh]

Also, you can take a look to https://github.com/funcool/catacumba

On Mon, Jan 4, 2016 at 12:35 AM, kovas boguta 
wrote:

> I would also look at https://github.com/ztellman/aleph and
> https://github.com/ztellman/manifold, but like Timothy says its hard to
> judge without more details.
>
>
>
>
> On Sun, Jan 3, 2016 at 4:24 PM, Timothy Baldridge 
> wrote:
>
>> I've done some evaluations of Vert.x in the past and was rather
>> underwhelmed. What is it that you are trying to accomplish? Stuff like
>> Pedestal offers async web services, but without the complexity of an
>> traditional evented server. So perhaps if we had a better idea of your
>> requirements we could be a bit more helpful.
>>
>> So I'd say, look into Pedestal and then define what you need that it
>> cannot do. Same for other toolkits like ring and httpkit.
>>
>> Timothy
>>
>> On Sun, Jan 3, 2016 at 12:59 PM, adrians  wrote:
>>
>>>
>>> It used to be that Vert.x 2.x had integration for Clojure, but version
>>> 3.x hasn't added it yet. Has anyone used this version through the Java API
>>> and if so, how painful was it? Is Reactor any
>>> better in that respect? What are people using when they want this kind of
>>> back end?
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> “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)
>>
>> --
>> 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.
>>
>
> --
> 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.
>



-- 
Andrey Antukh - Андрей Антух - 
http://www.niwi.nz
https://github.com/niwinz

-- 
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.

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[kovas boguta]

I would also look at https://github.com/ztellman/aleph and
https://github.com/ztellman/manifold, but like Timothy says its hard to
judge without more details.




On Sun, Jan 3, 2016 at 4:24 PM, Timothy Baldridge 
wrote:

> I've done some evaluations of Vert.x in the past and was rather
> underwhelmed. What is it that you are trying to accomplish? Stuff like
> Pedestal offers async web services, but without the complexity of an
> traditional evented server. So perhaps if we had a better idea of your
> requirements we could be a bit more helpful.
>
> So I'd say, look into Pedestal and then define what you need that it
> cannot do. Same for other toolkits like ring and httpkit.
>
> Timothy
>
> On Sun, Jan 3, 2016 at 12:59 PM, adrians  wrote:
>
>>
>> It used to be that Vert.x 2.x had integration for Clojure, but version
>> 3.x hasn't added it yet. Has anyone used this version through the Java API
>> and if so, how painful was it? Is Reactor any
>> better in that respect? What are people using when they want this kind of
>> back end?
>>
>> --
>> 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.
>>
>
>
>
> --
> “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)
>
> --
> 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.
>

-- 
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.

Re: What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[Timothy Baldridge]

I've done some evaluations of Vert.x in the past and was rather
underwhelmed. What is it that you are trying to accomplish? Stuff like
Pedestal offers async web services, but without the complexity of an
traditional evented server. So perhaps if we had a better idea of your
requirements we could be a bit more helpful.

So I'd say, look into Pedestal and then define what you need that it cannot
do. Same for other toolkits like ring and httpkit.

Timothy

On Sun, Jan 3, 2016 at 12:59 PM, adrians  wrote:

>
> It used to be that Vert.x 2.x had integration for Clojure, but version 3.x
> hasn't added it yet. Has anyone used this version through the Java API and
> if so, how painful was it? Is Reactor any
> better in that respect? What are people using when they want this kind of
> back end?
>
> --
> 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.
>



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

-- 
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.

What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[adrians]

It used to be that Vert.x 2.x had integration for Clojure, but version 3.x 
hasn't added it yet. Has anyone used this version through the Java API and 
if so, how painful was it? Is Reactor any better 
in that respect? What are people using when they want this kind of back end?

-- 
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.