GopherFest 2015

On Tuesday evening at the GopherFest 2015 meetup, I had the privilege of speaking alongside Andrew Gerrand, Rob Pike (the creator of Go!) and Steve Francia. If you missed the talks, check out the full recording above. The slides for my talk are on SlideShare. Also, Hakka Labs will be releasing an edited recording of the meetup, which I’ll post here when it’s ready.

First, I want to thank everyone who watched the talks. The Go community is amazing. The in-person turnout of over 300 was incredible, and more than 1,800 people around the world watched the live stream!

My talk was about concurrency in Go. I’d like to expand on what I talked about here.

Concurrency is one of Go’s most significant assets. It’s true that many languages have concurrency primitives, and many even have concurrency frameworks built on top of their primitives to make things more convenient. In fact, writing concurrent code without using a framework is practically impossible in some languages.

Go’s Approach and the Rise of Go

Instead of threads and frameworks, Go gives us only two concurrency primitives: goroutines and channels. The former is a clean abstract over lightweight units of concurrency (“green threads” in other nomenclature) and the latter is a clean abstraction over synchronization and communication between goroutines. Instead of building goroutines and channels into the language as a framework or library, Go builds them directly in the language.

Even better, Go doesn’t make you write callbacks, fork your process to take advantage of more cores or read a 500-page book about the latest concurrency paradigm. Instead, everything you need is simple, understandable and built into the language itself. A new Go programmer can understand concurrency and write good, concurrent Go code after reading a few thousand words in a section of Effective Go.

Most importantly, instead of focusing on the aforementioned low-level concurrency primitives, the experienced Go programmer focuses on the concurrent program itself. The effect of that shift in focus has allowed Go to rise fast as a systems programming language and emerge as a stellar tool for building distributed systems (or “microservices”). We chose it and use it at Iron.io to achieve both.

The Future of Concurrency

Now, for the exciting part. Go is being exposed to more problem domains these days. The language is being used in robotics, embedded programming and even genomics. This diversity is amazing, and it will give rise to solutions to new problems that Go has never seen.

On Tuesday, I discussed a few concurrency patterns to solve some common distributed systems problems, but what about the big robotics problems? How will the embedded systems used in IoT appliances stretch Go’s concurrency model? I suspect we’ll find a plethora of new concurrency patterns as we continue to answer these questions as a community. I can’t wait to see what happens next.