I've cleanly used that in a lil' game I'm working on.
Players send their move to the game on a channel they expose through Move(). They
receive regular updates of the game state on a channel they expose through Update().
type Player interface {
Name() string
Move() <-chan Move
Update() chan<- State
}
> In Go, we can do this by closing a channel, because a receive operation on a closed channel can always proceed immediately, yielding the element type's zero value.
for n := range c {
select {
case out <- n:
case <-done:
}
}
I wasn't quite getting that code when I first read it.
Now I can see it allows you do "discard" all the pending reads from the input channel (and avoid writing to a possibly-closed 'out' channel), but wouldn't it be better to break the loop in this case for an immediate exit?
i.e. go for 'interrupt' semantics, rather than 'drain'?
Yes, interrupt is better, and the article explains how to do that a few paragraphs later:
for n := range in {
select {
case out <- n * n:
case <-done:
return
}
}
If you allow pipeline stages to interrupt their receive loop instead of draining the inbound channel, then _all_ send operations need to be governed by done. Otherwise the interrupted receive loop may block the upstream sender.
The loop (particularly `range c`) keeps getting element out of `c` and assigning it to `n`. If it's "done", then `n` wouldn't be sent into `out`, but still gets read from the channel `c` constantly. In other words, it's the loop itself that makes sure everything sent into channel `c` is consumed.
If `break` is used, for loop is terminated once it's "done", hence nothing would be reading from channel `c`. The previous station in the pipeline would then block at sending operation.
I use channels to single-file data to a SQLite db. Data gets pushed into channels from multiple users / locations of the web app. A single goroutine (concurrently running function) reads from the channels one channel at a time and, for each channel, writes everything in the channel to the db in a single transaction. SQLite isn't the best at concurrency. Go's channels help resolve that issue nicely.
There is no "Go Concurrency Pattern" (singular). The article demonstrates some ways to use Go's concurrency primitives.
Obviously there is a massive syntactic difference between your Java example and the equivalent Go code, but the other major difference that jumps out at me is that cancellation is baked into the Java library, whereas in Go the programmer determines how each of their pipeline stages should be shut down.
To me, the major difference is that the Java solution gives you one solution. The Go solutions gives you the building blocks.
The latter has the advantage you get to recompose the system in new ways, yielding greater flexibility.
In Java, a better compositional framework is probably Erik Meijer's et.al's RxJava. Haskell also provides better compositionality due to it's functional structure and lazy evaluation semantics.
I guess an obvious difference is that Go has these stuff built into runtime and syntax, which makes those light-weight threads / tasks a first class thing.
Furthermore, is there a way in "Java SingleThreadExecutor" and its related components that allow automatic scheduling tasks on different threads? For example, you are on a quad-core and you want to have 4 threads running together, with millions of tasks mapped to 4 threads and dynamically balanced.
I think one huge difference is that a channel in Go is a stream of data, in which each element can cause the consuming code to wait for new responses. In your example, the future can only return one bit of data.
> I think one huge difference is that a channel in Go is a stream of data, in which each element can cause the consuming code to wait for new responses. In your example, the future can only return one bit of data.
In java you also can do something like:
List<Future<Long>> futures = new ArrayList<>();
for(int i = 0; i < n; i ++) futures.add(some parallel execution logic);
I think the main difference is the way the language and runtime collaborate to schedule multiple events. Note the use of the 'select...case' in the example code.
You end up with a really nice "actor model", where you have a goro which owns some state responding to incoming messages over channels and sending replies.
Slide 24 gives the general structure, but it's a good read.
I'm a C++ developer by day, and I haven't tried Go yet. This looks really intresting. There is a massive gap for some Dataflow Programming based languages; not sure Go is quite there yet, but we're moving in the right direction.
The future of programming is somewhere in the field of dataflow and (functional) reactive programming. It brings easy state to the declarative programming world.
That appears to compare Go channels to "simple" lazy Haskell. A more apt Haskel comparison would be to something like "pipes" or "conduit", which will be quite different.
