That's the main trick, but the other pattern there I really liked was the idea of pulling all mutable state into the function which was running as the goroutine

That's the main trick, but the other pattern there I really liked was the idea of pulling all mutable state into the function which was running as the goroutine (and manipulated by the for-select). It's a lot like an object instance, responding to messages, changing internal state and emitting messages. In fact, here is the same approach in SICP, where they start to model objects as messages passed to a closure with internal mutable state: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-21.html#%_sec_3.2.3 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-21.html... [scroll down a bit for exercise 3.11, the "cond dispatch" is analagous to the "for-select" case dispatch, except of course that golang select handles concurrency.] It's the old "objects are a poor man's closures"/"closures are a poor man's object" duality.