
RxGo: Reactive Extensions for the Go Language - deepanchor
https://github.com/jochasinga/RxGo
======
dtech
I'm a fan of the Rx programming model, but is it really worth it to introduce
such a library and model into a language with such an opinionated and built-in
model for streaming/pipelining and concurrency?

~~~
mevile
If you don't want to use this nobody will force you. The overwhelming and
unfortunately predictable heap of negativity that comes bearing down on people
sharing something cool they made is really awful.

Well someone has made this, and now you can decide if it's worth it for you as
an individual to decide whether you like it or not and then if you don't, then
don't use it.

~~~
dtech
I find it incredibly ironic and hypocritical that you accuse me of creating a
negative environment... in a negative reply to a fairly neutral question.

I don't use Go, but am a contributor to a Rx project for a different language.
As such I am not interested in using this but genuinely curious about the
potential (non)benefits of Rx in Go, especially given that they both promise
to solve similar problems in very different ways. From experience HN is the
prime place for such discussions.

I think HN would be a much worse place if we would only be allowed to
cheerlead projects here.

------
omginternets
On the one hand this seems like a strange decision given that Go purposefully
avoids asynchronous code. On the other hand, I think this project is trying to
get at something that is (IMHO) a blind-spot for the Go community. Namely: I
find it difficult to design abstract data-flow patterns and encapsulate behind
a nice API.

Go is great for dealing with the nitty-gritty of concurrency, but I find it
hard to express a high-level vision of what's going on in my app/lib. This is
why this project _almost_ feels good. There's a clear view of what we're
manipulating and how we're positioned relative to the data.

Has anybody else struggled with this?

The closest thing I've found to a solution has been go-mangos[0], a native go
implementation of the scalable protocols. This is extremely useful for
designing the data-flow of an application when I'm shuffling bytes around, but
what I find myself wanting is an equivalent system for raw (i.e.:
unserialized) Go data-structures.

I want to be able to do something like this (assume a hypothetical library to
this effect called `portal`):

    
    
        p0, _ := portal.NewPortal(iface, portal.REP)  // iface is a types.Interface
        p0.Bind("foo")
        
        p1, _ := portal.NewPortal(iface, portal.REP)
        p1.Dial("foo")
    
        go func() {
            for {
                i, _ := p0.Recv()  // `i` guaranteed to satisfy the interface represented by `iface`
                i.DoSomething()
                p0.Send(i)
            }
        }()
    
        p1.Send(iRequest)
        iResult, _ := p1.Recv()
    

I'm very curious to get some feedback on this idea. It's been gnawing away at
my brain for a while now.

[0] [https://github.com/go-mangos/mangos](https://github.com/go-mangos/mangos)

------
chris_7
Rx not encoding side effects in the type system, as ReactiveSwift does, is
very unfortunate.

------
azinman2
Isn't this what channels are for? Doesn't Go have this already built in?

~~~
saturn_vk
Not really. Channels have a single function, to transport data to the first
available consumer.

With observables, there's a whole world on top of that. The simplest
observable, when subscribed to, will cause the producer of content to start
the production. If 3 consumers subscribe to an observable, then the producer
will do it's work three times, once per subscription. Compare that to a
channel, where a producer has no way of knowing if a consuer is available.
Generally, they start the work immediately and try to stuff the result in a
channel, regardless of whether there's a consumer on the other end. Moreover,
when another consumer uses the same channel, you have two consumers fighting
for the same result.

And since observables are transformable, there's a plethora of operators
available (at least in rxjava). If you take the previous example, you might
want to share the observable, replaying the last result, so that regardless of
how many consumers subscribe to it, the producer will only do the work once,
and the consumers will receive the same results. It will be quite a bit
harder, though not impossible, to implement the same thing with channels.

------
alpb
FWIW not exactly related, but check out Go-LINQ as well.
[https://github.com/ahmetalpbalkan/go-
linq](https://github.com/ahmetalpbalkan/go-linq) (disclaimer: my project). I
will take a look at combining RxGo and Go-LINQ and probably will write a blog
post soon.

------
xer
The examples lack the elegance of RxJS. I'm gonna stick with the Channels for
a further while.

------
omegaworks
Why is Rx so huge? What does it give you that Promises dont?

~~~
dtech
Promises are to Streams what single values are to arrays/collections.

Promises are all fine and dandy for "do this, wait for that, do that", but
they are not powerful enough to express "every time this happens, do that".

I guess you're coming from a JS background as you are using the word
"Promises". Imagine instead of registering a callback for mouse click events,
you have a stream of mouse events where you can listen to. This is exactly how
it works in Angular 2 [1].

[1] [http://blog.rangle.io/observables-and-reactive-
programming-i...](http://blog.rangle.io/observables-and-reactive-programming-
in-angular-2/)

