Will go channel be supported?

[rueian]

Hi all, thank you for making this dream framework come true. I have been looking forward to this kind of tool in Go for a long time.

But sadly I noticed that, in the Serializable Types section of FAQ, chan t type is not supported.

I am wondering if there are any current plans or ongoing discussions around supporting it. As it is something that I need, I would be also interested in getting involved and contributing to its development.

[spetrovic77]

Thanks for your interest. Getting channels to work across the network does sound really interesting, albeit pretty intense to implement.

Could you please describe your use-case in a bit more detail?

[rueian]

Hi @spetrovic77,

The most obvious use case is what we can have originally with grpc bidirectional streaming. It allows applications to communicate on a long-lived stream and have their own states in memory. This nature has helped me simplify my code for state management many times.

I understand that making channels work across the network is actually far more complex than grpc bidirectional streaming. Maybe supporting something like grpc bidirectional streaming is enough.

[charles-chenzz]

I believe making channels work across network could be far more complex than we think, but I have an idea on it, don't know if it's workable. My idea is that we set up a channel registry center on weave framework, and you declare a make(chan int) on code, the framework scan it and register on the center, and we know in GO, channel can be two-way channel to one-way channel, we then use the channel on our code like <- chan and chan <- int

[spetrovic77]

Thanks for all of your suggestions. We'll discuss this support soon. It looks fairly involved, please reach out to us at serviceweaver@google.com if you think this will unblock some major production usage.

[charles-chenzz]

sure, will send an email to this address and try to contribute code if needed in this project. the idea of this project is great :)

[Qjawko]

Great idea, can not wait this feature with jsonRPC + WS support :).

Maybe it will be better to use something like io.Writer (or even more generic option) than go channel because io.Writer is safer option. With go channel you will need to check for closed state and if you will try to send data to closed channel runtime will be panic.

IMO.

[Joshswooft]

You could provide a wrapper around the channels similar to: https://github.com/matryer/vice but this involves maintaining your own queue specific transport implementation e.g. rabbitMQ, kafka, NATs etc.

[gedw99]

You could provide a wrapper around the channels similar to: https://github.com/matryer/vice but this involves maintaining your own queue specific transport implementation e.g. rabbitMQ, kafka, NATs etc.

I have used this with nats.

The nats jetstream broker provides load balancing across clusters if you want to.

the vice code could do with an update to the latest nats api though.

Also the vice system does not create the nats control plane AFAIK.

[Deleplace]

As everyone mentioned, making channels properly work over the network is complex.

There was a real attempt to have "netchan" in the stdlib but afaik this didn't land : video, discussion

My understanding on this is that, while wrapping the network to achieve message passing is doable, it is not currently possible to preserve the semantics of go channels. In a single machine we have good guarantees that a read and a write happen "at the same time" (wrt the memory model), but over the network we don't.