“Great talk by Rob Pike”
Entertaining goroutine demo with gophers passing messages.
Full comment
Great talk by Rob Pike: this video "Go Concurrency Patterns" with cute little gophers playing Chinese whispers with megaphones
Google I/O 2012 - Go Concurrency Patterns
894K views · Jul 2, 2012 · 51:27 · 9 HN recommenders · 19 mentions · discussed 2012–2025
Rob Pike's Google I/O 2012 talk shows how goroutines and channels solve tricky concurrency problems with simple Go code. It features a playful goroutine demo with gophers passing messages and a search engine example.
Why Hacker News points people here: The canonical recommendation for learning Go concurrency, praised as entertaining and clarifying when to use channels versus mutexes.
“Great talk by Rob Pike”HN comment, 2012
What Hacker News said 19
“Go Concurrency Patterns (One of my favorites)”
One of the commenter's favorite Go talks.
Full comment
For those who don't know who Rob Pike is, he's pretty awesome, helped create UTF-8 among other things, and now works on Go. link He has given some really great Go talks which are available on youtube, about an hour each: Origins of Go Concurrency Style - link Lexical Scanning in Go - link Go Concurrency Patterns (One of my favorites) - this video
“And Rob Pike's latest talk about concurrency patterns at Google IO last week”
Rob Pike on concurrency patterns in Go.
Full comment
In one word: channels. They might be theoretically equivalent to some degree, but in practice they are quite different, and I find reasoning about both concurrency and parallelism using goroutines and channels much more natural. Also see this talk by Rob Pike on the origins of Go's concurrency model here: link See also this article by Russ Cox about CSP: link And Rob Pike's latest talk about concurrency patterns at Google IO last week: this video
“So I prefer the original”
Preferred as the original source for the concurrency patterns.
Full comment
I'm a fan of Go, but this is not a very good talk. The first half is unnecessary trolling, and the second half is based on some code snippets taken from Rob Pike's "Go Concurrency Patterns", but in this case badly presented. So I prefer the original: this video
“Start with Rob Pike's”
Suggested as the starting point for learning Go's strengths.
Full comment
You're responding to: > Clojurescript is the browser language I always > wanted. JS seems like such a hack. You're getting downvoted for reading into someone's enthusiastic personal endorsement and then ending it with the tiring "Tell me something good about <thing I refuse to read or understand on my own time but I'll partake in discussion anyways>...". Start with Rob Pike's "Go Concurrency Patterns" ( this video )
“And for those that would rather watch a video presentation”
Video presentation of the same patterns for watchers.
Full comment
Great explanation in document form of these patterns. Also very succinct and easy to reference. For those that would rather read this in presentation form: link And for those that would rather watch a video presentation: this video
“the various talks by Rob Pike [2] [3] / Sameer Ajmani [4] are great resources”
Among great Go resources alongside the Go Tour.
Full comment
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
“Rob Pike did a number of interesting talks on concurrency in Go.”
One of Rob Pike's interesting talks on Go concurrency.
Full comment
Rob Pike did a number of interesting talks on concurrency in Go. If you search "Go concurrency" on YouTube there are more good talks. Go Concurrency Patterns this video Concurrency Is Not Parallelism link
“Here's a great video that talks about use cases and the patterns in using them”
Use cases and patterns for Go channels with goroutines.
Full comment
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
“There's also a nice talk Rob Pike gave that illustrated some very useful concurrency patterns”
Useful concurrency patterns built on the CSP model.
Full comment
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
“Go Concurrency Patterns Rob Pike, Google I/O 2012 Goroutines, Channels”
Listed among Go talks for goroutines and channels.
Full comment
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
“Rob Pike, in his search engine example at Google's I/O 2012 IIRC, made the explicit point that mutexes are there”
Pike's point that channels join large program parts, mutexes guard data.
Full comment
Agreed, Rob Pike, in his search engine example at Google's I/O 2012 IIRC, made the explicit point that mutexes are there and that channels are for joining large concurrent parts of the program together; guarding a data structure seems too small even though it's a common (toy?) example. this video
“Video of rob giving the talk”
Video of Pike giving the talk with executable slides.
Full comment
Video of rob giving the talk: this video this makes use of the excellent "Golang Present Tool", which makes most of the code on the slides executable.[1] [1]: link
“Rob Pike has a Q&A at the end of his video where he answers”
Q&A answers question about goroutine cleanup.
Full comment
Rob Pike has a Q&A at the end of his video where he answers (what sounds like) the exact same question you ask: this video Essentially, it gets garbage collected without you having to worry about it unless you're doing something fairly special.
Part of a set of materials to learn Go quickly.
Full comment
> "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
“Video for the slides”
Video accompanying the slides on select and channels.
Full comment
Observing other channels, or seeing when a channel does fire is what the select structure is for. It is one of the features that makes channels and goroutines very nice in go. link link link Video for the slides: this video
“Can any of those tools execute code from within the slides?”
Example of the present tool running code from slides.
Full comment
Reveal wasn't a thing when I wrote present. I probably would have used it as a front end, had it existed. Tools like Keynote and Google Slides were exactly the kind of thing we were trying to improve upon. They're great for making pretty slides, but a total PITA for authoring and editing technical content. Can any of those tools execute code from within the slides? this video link And do they let us store our code snippets in actual testable (or at least buildable) source files?
“No locks, no condition variables, no callbacks[2].”
Cited for Go's channel-based concurrency without locks or callbacks.
Full comment
Go was built as a language to make communicating sequential processes[1] first-class citizens. Thus the ubiquity of channels and goroutines. No locks, no condition variables, no callbacks[2]. Writing a bunch of code using locks and callbacks in Go goes against the grain of the language. [1] link [2] this video
“See this for more info on how this could lead to cleaner programs”
Shows how language-level multiplexing yields cleaner programs.
Full comment
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