Chans & goroutines vs Reactive Extensions

Technical Discussion
1

The only place I have seen this discussed is at https://news.ycombinator.com/item?id=9114064

Any comments? ReactiveX/RxSwift seems to be getting popular.

What can the two paradigms typically do & not do? Where are they most suitable and designed for?

1 Like
2

Have you seen GoFlow? It’s probably the closest Go analogue to Akka.

I have recently deployed production software built upon it and anticipate doing so for a larger scale project soon.

2 Likes
3

Looks fine for monoliths. And for micro-services there’s https://github.com/nsqio/nsq even if it’s not the primary goal.

1 Like
4

Thank you for that reference! I will study it. However, being used to communicating sequential processes (occam, local schedulers in small embedded systems, and the bare bone channels and goroutines of go etc) that would be my cognitive starting point (for good or worse), what’s the basic idea for building all the wrappings around something that may(?) be built simpler?

I an trying to sketch up about this at http://www.teigfam.net/oyvind/home/technology/113-go-forum-matters/#chans_goroutines_vs_reactive_extension (disclaimer: no money or gifts etc.). This makes it easier to learn.

The reason for the frameworks, is it really only to avoid hardcoding every instance of this and getting all the documented features in addition?

5

We’re using GoFlow, which is really just a specific way of exploiting the Goroutine/Channel power, to recruit all the available hardware resources.

By default, every net component (think actor) is run on a new Goroutine when it receives an item on its input channel. So no item being processed in the network is ever semantically blocked by another. If the infrastructure has headroom, it will be exploited to push volume through the network.

It also comes into its own when you have different load profiles for different components - some can be doing computation while others are doing I/O etc.

1 Like
6

Of course I understand the difference between a programming language and a pattern, between bricks and a house. It still puzzles me to see all these frameworks evolving from use with a non-concurrent languages (like Swift) that don’t have any notion of process (like gorotines) and communication (like channels) and synchronisation (like zero-buffered or full channels) ported and embraced on concurrent platforms (like go). Whether it’s push or pull with channels is kind of orthogonal to the problem, isn’t it? There can’t be any reception before production anyhow.

And it puzzles me to read things like the below (quote from ycombinator in my initial question):

“(reubenbond at ycombinator) Channels in Go don’t compose: I can’t easily take one channel, mutate the values as they arrive, and create another channel from the mutated values. With Rx, that’s just var uppers = keyPresses.Select(key => key.ToUpper()) and now I’ve got a new stream of data. If keyPresses completes, so does uppers. If it fails, that failure is propagated through uppers. This isn’t easy in Go.
goroutines don’t have any reasonable kind of monitoring. I can’t say “this routine has completed/failed”, I have to implement that notion every single time using a WaitGroup or something, and that only handles completion, not failure.”

How correct are the answers? It’s not excactly the syntax “var uppers = keyPresses.Select(key => key.ToUpper())” on go, but it’s not much different, is it? Once channels have been connected between goroutines. "Composition: A Way to Make Proofs Harder"
by Leslie Lamport certainly rules CSP to be compositional, and any goroutine (or PROC in occam) can spawn a new process. And with mobile channels (and go channels) you can spawn any channel you like at any time, except you’d have a way to connect that new channel (like sending it over an existing channel). Isn’t this enough?

Would a web server framework written in go for go from the onset look different than the others? It looks like GoFlow is one such? How does it differ from how a Reactive Extension for Go would have been?

(As you understand, I see this from an embedded programmer’s bench, but being curious about this)

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.