[go-nuts] Re: distributed runtime

2020-08-06 Thread dolanor
I completely forgot about this thread. I wanted to thank you all for your insights. I've learned quite a few things, and can add many things to my "to dig" list! Le vendredi 3 janvier 2020 23:31:52 UTC+1, Dolanor Maergal a écrit : > > Hi all and Happy New Year, > > I was daydreaming the other da

Re: [go-nuts] Re: distributed runtime

2020-01-06 Thread Robert Engels
I think you want to use “nats streaming”. It does throttling via ACKs. > On Jan 6, 2020, at 7:35 AM, Jason E. Aten wrote: > >  >>> On Mon, Jan 6, 2020 at 6:24 AM Robert Engels wrote: >>> I’m pretty sure Nats.io has all of the same delivery guarantees as >>> rabbitmq. What design is not accom

Re: [go-nuts] Re: distributed runtime

2020-01-06 Thread Jason E. Aten
On Mon, Jan 6, 2020 at 6:24 AM Robert Engels wrote: > I’m pretty sure Nats.io has all of the same delivery guarantees as > rabbitmq. What design is not accommodated by mats? > Any design that needs flow control is not accommodated by Nats.io. I've used Nats extensively and consider it fundamenta

Re: [go-nuts] Re: distributed runtime

2020-01-06 Thread Robert Engels
I’m pretty sure Nats.io has all of the same delivery guarantees as rabbitmq. What design is not accommodated by mats? > On Jan 6, 2020, at 4:56 AM, ffm2...@web.de wrote: > >  > >> >> However, if you want to apply supervision for distributed Go channels you >> have to change from channels to

[go-nuts] Re: distributed runtime

2020-01-06 Thread ffm2002
> > However, if you want to apply supervision for distributed Go channels you > have to change from channels to actors - at least behind the scenes of the > distributed channels. AFAIK, no one has done something like that for > anything writen in Go. Nats is very reliable, but does not provide

[go-nuts] Re: distributed runtime

2020-01-06 Thread ffm2002
Am Montag, 6. Januar 2020 09:54:49 UTC+1 schrieb Brian Candler: > > On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote: >> >> in Amoeba a thread can be suspended, thereafter be sent to some other >> machine where it is resumed. >> > > Thread migration doesn't solve the OP's issue, becau

[go-nuts] Re: distributed runtime

2020-01-06 Thread Brian Candler
On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote: > > in Amoeba a thread can be suspended, thereafter be sent to some other > machine where it is resumed. > Thread migration doesn't solve the OP's issue, because threads share memory with other threads: passing a copy of something is n

[go-nuts] Re: distributed runtime

2020-01-06 Thread Brian Candler
On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote: > > in Amoeba a thread can be suspended, thereafter be sent to some other > machine where it is resumed. > Thread migration doesn't solve the OP's issue, because threads share memory with other threads: passing a copy of something is n

[go-nuts] Re: distributed runtime

2020-01-06 Thread ffm2002
Have you heard of the Amoeba distributed OS? See https://en.wikipedia.org/wiki/Amoeba_(operating_system). Well, in Amoeba a thread can be suspended, thereafter be sent to some other machine where it is resumed. That you can't do with goroutines of course (and goroutines pursue a different appro

[go-nuts] Re: distributed runtime

2020-01-04 Thread Jason E. Aten
https://github.com/glycerine/goq Network communication costs much more than in-proc, so its better to parallelize with whole independent processes. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receivin