Google I/O 2012 - Go Concurrency Patterns

In my experience with Android apps, I've almost never had to use the NDK. When I did have to use the NDK, it wasn't because I wanted to code in C/C++---it was because there were strong, open-source libraries written in C/C++ that I wanted to use in an app (Though, I have no experience making games on Android). If you want to check out Go, then the Go Tour [1] and the various talks by Rob Pike [2] [3] / Sameer Ajmani [4] are great resources. The Go Tour stands on its own as an interest-building resource; the several programming exercises it has you do are fun and challenging. [1]: [link] [2]: [this video] [3]: [link] [4]: [link]

This is true, that's exactly what exceptions are. One could argue (I would) that this is a very powerful part of Python, but the indeterminate nature of the exception (where is it coming from, how is it defined, what should I provide to my client) makes it easier to catch exceptions as they percolate upward, but more difficult to correctly know how to handle them (especially as the permutations approach infinity as underlying libraries get upgraded). Golang actually has a back-channel communication path that is somewhat similar as a second channel of communications. (Actually they're called channels!) They're a first-class and extremely powerful feature of the language. You can even run a for loop over them, block or not block while waiting for an incoming message, etc. Here's a great video that talks about use cases and the patterns in using them, and they pair great with goroutines (and you don't have to sprinkle async before every function, either): [this video]

Not quite. Erlang uses the Actor model which delivers messages asynchronously to named processes. In Go, messages are passed between goroutines via channels, which provide a synchronization mechanism (when un-buffered). The ability to synchronize allow one to setup a "rhythm" to computation that the Actor model is explicitly not designed to do. Also, note that a process must know its consumer in the Actor model, but goroutines do not need to know their consumer in the CSP model. Channels can even be passed around to other goroutines! Each have their own pros and cons. You can see some of the legends who invented different methods of concurrency here: [link] There's also a nice talk Rob Pike gave that illustrated some very useful concurrency patterns that can be built using the CSP model: [this video]

The "Talks and Videos" page ( [link] ) is outdated as well. Here's my personal list: Why Learn Go? [link] Short interview with Rob Pike, OSCON 2012 Get Started with Go [link] Andrew Gerrand A Tour of Go [link] Russ Cox Go Concurrency Patterns [this video] Rob Pike, Google I/O 2012 Goroutines, Channels Meet the Go Team [link] Panel (Pike, Thompson, Griesemer, Gerrand, Fitzpatrick, Simons), Google I/O 2012 Computing Map Tiles with Go on App Engine [link] Chris Broadfoot, Andrew Gerrand, Google I/O 2012 Go in Production [link] Gustavo Niemeyer, Google I/O 2012 Go: Code that grows with grace [link] (Contains some audio glitches) Andrew Gerrand Interview with Rob Pike [link] Rob Pike, GOTO Conference Lexical Scanning in Go [link] Rob Pike Cuddle, A Go AppEngine Demo [link] Andrew Gerrand Building Integrated Apps on Google's Cloud Platform [link] Andrew Gerrand, Google Developer Day Japan 2011 Real World Go [link] Andrew Gerrand, I/O BootCamp 2011 Go: it's that simple?! [link] Andrew Gerrand, OSDC 2011 Practical Go Programming [link] Andrew Gerrand, FOSDEM 2011 Writing Web Apps in Go [link] Andrew Gerrand, Rob Pike, Google I/O 2011 Go Programming [link] Rob Pike, Google I/O 2010 Another Go at Language Design [link] Rob Pike, Stanford University Public Static Void [link] Rob Pike, OSCON 2010 The Go Programming Language [link] Rob Pike, Google Tech Talk

> "We also weren't sure if we would be able hire top talent if we chose Go, but we soon found out that we could get top talent because we chose Go." I feel[1] that a smart/talented C/C++/anything developer can go from someone who has never seen or heard of golang to a proficient and productive Go developer in a matter of a few weeks, maybe even _days_, if not less. That's how long it takes to go through the following materials (and fav some for later reference) and play with the language a bit. [link] [link] [link] [link] [link] [link] [link] [link] [link] - use as reference [this video] [link] [link] [link] And a some more similar things that you can mostly get to from golang.org site. The beauty of how concise the language and even its website are, is that you can literally just go through everything there one thing after another. [1] This is my personal opinion based on playing with go the last few weeks/months. I'd love to verify this theory. It's not yet the primary language in which I do things in (I use C++11 atm), but for all my side tasks[2] it proved to be indispensable. And I found it very easy to pick up. I can't wait until I start doing all my work in Go, that will be a true test of its productivity efficiency. [2] [link]

All implementations of in-process thread multiplexing is sort of like a garbage collector. You have a resource, you manage the allocation of a resource to something that consume it, etc. A lot of house keeping and some overhead code that needs to execute before any work is done (each time). In my mind, it makes sense to have a single, well tested, and abstracted implementation that all other systems can use. You can see a need for this at least in the Android space: RxJava, Kotlin coroutines, etc. Also, in a user-managed thread multiplexing system you can't guarantee "fair" scheduling. If you have some DOS bugs in your server you can lock up an entire serving thread. A language-level multiplexing system will not have these same kinds of edge cases. There are many places this sort of thing becomes helpful. We could also see concurrent processing utilities that could be very helpful. See this for more info on how this could lead to cleaner programs: [this video]