FAQ
The concurrency model of Go is wonderful, but restricted to a
single program. What if I wanted something similar across
multiple programs, possibly running on different machines?

Redis seems an option, with its publish/subscribe model.

Other (better?) options that are platform independent?


(Yes I know, you can write your own servers.)


--
Peter Kleiweg
my Go programming cookbook: http://www.let.rug.nl/~kleiweg/go/

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Job van der Zwan at Feb 22, 2013 at 10:44 am
    I feel this is relevant to this question:
    https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/Er3TetntSmg

    TL;DR: Rob has been experimenting with a "netchan" version of channels, but
    it seems to have been on hold for a while because it is a Hard Problem. And
    that makes exploring alternatives a good idea in the meantime, I suppose.

    (This topic is way over my head otherwise, so I'll demote myself to
    interested bystander.)
    On Friday, 22 February 2013 11:34:20 UTC+1, Peter Kleiweg wrote:


    The concurrency model of Go is wonderful, but restricted to a
    single program. What if I wanted something similar across
    multiple programs, possibly running on different machines?

    Redis seems an option, with its publish/subscribe model.

    Other (better?) options that are platform independent?


    (Yes I know, you can write your own servers.)


    --
    Peter Kleiweg
    my Go programming cookbook: http://www.let.rug.nl/~kleiweg/go/
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robotic Artichoke at Feb 22, 2013 at 1:52 pm
    Redis is a fantastic piece of software and its pub/sub model would be fine.
    There's also Rabbit and ZeroMQ. All 3 of these are solid options depending
    on your needs.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Peter Kleiweg at Feb 22, 2013 at 8:02 pm
    Op vrijdag 22 februari 2013 14:52:39 UTC+1 schreef Robotic Artichoke het
    volgende:
    Redis is a fantastic piece of software and its pub/sub model would be
    fine. There's also Rabbit and ZeroMQ. All 3 of these are solid options
    depending on your needs.

    RabbitMQ (could'n find it at first, just looking for Rabbit) and ZeroMQ are
    quite different from Redis. They offer more patterns then just pub/sub.
    Redis seems to be a shared, in-memory data store first, with pub/sub
    messaging second.

    Go support seems much better for ZeroMQ than for RabbitMQ.

    I don't quite get the why of Redis.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jeff Mitchell at Feb 22, 2013 at 8:32 pm

    Peter Kleiweg wrote:
    RabbitMQ (could'n find it at first, just looking for Rabbit) and
    ZeroMQ are quite different from Redis. They offer more patterns then
    just pub/sub. Redis seems to be a shared, in-memory data store first,
    with pub/sub messaging second.

    Go support seems much better for ZeroMQ than for RabbitMQ.

    I don't quite get the why of Redis.
    That's because you're comparing oranges, tangerines, and tangelos. RabbitMQ is a general-purpose message queue; ZeroMQ is a smart socket library; Redis is a high performance memory-based cache (which had pub/sub support bolted on much later).

    Any of the three can support pub/sub these days, but the pros and cons of implementing pub/sub on each are very different in large part because they were originally designed to solve different problems. The "why" of any of them therefore depends in large part on your exact needs.

    --Jeff

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Stephen McDonald at Feb 23, 2013 at 1:18 am
    I've been working for a while on benchmarking Redis and ZeroMQ from Go
    and just now publish a blog post on what I've found so far, very
    timely!

    http://blog.jupo.org/2013/02/23/a-tale-of-two-queues/

    Would love any general go-related feedback on the results and
    implementation.

    Cheers,
    Steve
    On Feb 23, 7:26 am, Jeff Mitchell wrote:
    Peter Kleiweg wrote:
    RabbitMQ (could'n find it at first, just looking for Rabbit) and
    ZeroMQ are quite different from Redis. They offer more patterns then
    just pub/sub. Redis seems to be a shared, in-memory data store first,
    with pub/sub messaging second.
    Go support seems much better for ZeroMQ than for RabbitMQ.
    I don't quite get the why of Redis.
    That's because you're comparing oranges, tangerines, and tangelos. RabbitMQ is a general-purpose message queue; ZeroMQ is a smart socket library; Redis is a high performance memory-based cache (which had pub/sub support bolted on much later).

    Any of the three can support pub/sub these days, but the pros and cons of implementing pub/sub on each are very different in large part because they were originally designed to solve different problems. The "why" of any of them therefore depends in large part on your exact needs.

    --Jeff
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Peter Kleiweg at Feb 23, 2013 at 12:22 pm
    Op zaterdag 23 februari 2013 00:40:05 UTC+1 schreef Stephen McDonald het
    volgende:
    I've been working for a while on benchmarking Redis and ZeroMQ from Go
    and just now publish a blog post on what I've found so far, very
    timely!

    http://blog.jupo.org/2013/02/23/a-tale-of-two-queues/

    Would love any general go-related feedback on the results and
    implementation.
    I wonder how much the choice of Go package would effect this.

    github.com/garyburd/redigo/redis is pure Go.

    github.com/gosexy/redis is a wrapper around a C library. Would it be faster?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • George Shammas at Feb 23, 2013 at 1:28 pm
    If MQ's are for consideration, I would highly recommend nsq. Its
    written entirely in go, is light weight, and scales very well.

    https://github.com/bitly/nsq

    and a pubsub example:
    https://github.com/bitly/nsq/tree/master/examples/nsq_pubsub

    On Sat, Feb 23, 2013 at 7:21 AM, Peter Kleiweg wrote:

    Op zaterdag 23 februari 2013 00:40:05 UTC+1 schreef Stephen McDonald het
    volgende:

    I've been working for a while on benchmarking Redis and ZeroMQ from Go
    and just now publish a blog post on what I've found so far, very
    timely!

    http://blog.jupo.org/2013/02/**23/a-tale-of-two-queues/<http://blog.jupo.org/2013/02/23/a-tale-of-two-queues/>

    Would love any general go-related feedback on the results and
    implementation.
    I wonder how much the choice of Go package would effect this.

    github.com/garyburd/redigo/redis is pure Go.

    github.com/gosexy/redis is a wrapper around a C library. Would it be
    faster?

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • José Carlos Nieto at Feb 26, 2013 at 12:36 pm
    I added benchmarks for all the Go redis libs (that work) here:
    https://github.com/gosexy/redis/tree/master/_benchmarks

    In terms of speed one of the clients clearly falls behind the others (Tcgl)
    while the remaining have similar speeds.

    Being a C wrapper does not provide any particular advantage in this case,
    you must take in account that those clients have very different features
    too.

    José Carlos
    On Saturday, February 23, 2013 6:21:59 AM UTC-6, Peter Kleiweg wrote:


    I wonder how much the choice of Go package would effect this.

    github.com/garyburd/redigo/redis is pure Go.

    github.com/gosexy/redis is a wrapper around a C library. Would it be
    faster?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Asmuth at Feb 22, 2013 at 6:41 pm
    You could try something like https://github.com/skynetservices/skynet
    On Friday, February 22, 2013 5:34:20 AM UTC-5, Peter Kleiweg wrote:


    The concurrency model of Go is wonderful, but restricted to a
    single program. What if I wanted something similar across
    multiple programs, possibly running on different machines?

    Redis seems an option, with its publish/subscribe model.

    Other (better?) options that are platform independent?


    (Yes I know, you can write your own servers.)


    --
    Peter Kleiweg
    my Go programming cookbook: http://www.let.rug.nl/~kleiweg/go/
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 22, '13 at 10:34a
activeFeb 26, '13 at 12:36p
posts10
users8
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase