Gophercon 2014

Gophercon 2014

A week after @GopherCon. The lingering feeling of having attended a Woodstock of programming. I'll say to my kids, "I was there" - @ivargaitan

I had the privlege of attending the first Gophercon in Denver. It was a fantastic conference, full of smart interesting people, truly one of the best technical conferences I have been to.

I consider myself a baby gopher, so I was there to learn as much as I could, and the conference did not disapoint. Here are my thoughts and notes about the conference. You can find more in depth posts on the conference on Sourcegraph's live blog.

Day 1

Opening Keynote

The day kicked off with a fantastic keynote by Go creator Rob Pike (@rob_pike). Rob spent the first part of the keynote breaking down Go's Hello World. He used it as a way to discuss the design and simplicity of the language.

People notice all the things Go lacks, but miss the things that it has - Rob Pike

Rob then moved into the factors for Go's success. He attributed most of Go's success to having a small team of people doing "consensus driven development". Nothing went into the language unless everyone on the core team agreed. He also gave credit to some of it's features like concurrency, garbage collection, and being statically typed but feeling dynamic. He mentioned that he was surprised at the adoption of the dynamic language communities (Ruby, Python, etc.), and the slower adoption of the static language communities (C, C++, Java, etc.).

He then spent some time discussing the future of the language, which he basically left up to the community.

You can read my full notes of the keynote here.


After the keynote Derek Collison (@derekcollison) spoke on building high performance systems. He talked about a messaging system Apcera ported from Ruby to Go. By porting to Go they were able to increase the message rates from 150k messages per second to 5-6M messages per second. They made heavy use of the profiling tool pprof to determine where they could make improvements in speed. The main takeaways were to prefer long lived objects, and to not use channels in performance critical sections.

Later, John Graham-Cumming (@jgrahamc) gave a talk on channels in Go. His talk had lots of great examples of when and how to use channels. I would recommend taking a look at his slides, as they were very dense with examples. For me, the main take away was that channels are awesome, and I need to learn how to use them better.

Channels, the truffle oil of golang - @meatballhat

Kelsey Hightower (@kelseyhightower) gave the final talk before the lunch break. His talk on Go for sysadmins (slides) might have been the first talk to ever boot a VM from a slide. He gave an overview of how to setup a CoreOS iPXE boot server using Go's net/http library.

I show everyone the fire and they want to go burn everything down - Kelsey Hightower

David Symonds gave a very interesting talk on the Google App Engine Go runtime, and some of the things Google had to do to make it work. He talked about three things they needed to change to make Go work.

  1. Explicit context passed to and from all API calls. In the other languages on App Engine (Java, Python) they could use globals or thread-local storage to pass and maintain the context. Due to Go's concurrency model that would not work, so they have to pass the context around.

  2. The language primitives in Go, like structs, make it simpler to reuse things. Go APIs encourage re-use of data types, you don't have to make different struct to handle json, xml, etc.

  3. “All the world’s not a VAX”

The Go runtime on App Engine runs in a single thread so maintain security.

From one shiny object to the other - Kelsey Falter (@kfalter)

Kelsey Falter (@kfalter) spoke about Poptip's transition from Node.js to Go. She had the following slides comparing Node.js and Go (thanks Sourcegraph for the images)

Why Node

Why Go

She talked about why they chose Node to start, and what spurred their decision to migrate to Go. They began the transition to Go slowly, moving over one system at a time. A DDoS attack on Thanksgiving validated their choice to go Go. The Go app was able to handle the load, it was their database server that couldn't.

Embrace the interface, which I'm not used to in Ruby. I'm used to just metaprogramming the crap out of everything - Mike Gehard

Later Mike Gehard (@mikegehard) gave a talk on writing CLI tools with Go. One of the main reasons to use Go for CLIs is that there is no runtime dependency like with Ruby or Java. He shared some details and examples of using cli to build Pivotal's tool, as well as some examples of using Ginkgo for testing it.

The day ended with an interesting talk from Go core team member Brad Fitzpatrick (@bradfitz). He told the story of developing Camlistore and how many of the features in Go's STL are due to him needing a feature for Camlistore. He added code to mime/multipart, os/exec, database/sql, etc. all because he needed them for his side project. He also started up godoc circa 2010, it was interesting to see some of the changes since then.

Day 2


Day two began with a talk from core team member Russ Cox (@_rsc) on porting the Go compiler from C to Go. They are attempting to build a C to Go trans-piler to do the bulk of the work. The main issues they have seen are:

  • Unions
  • #define
  • comments
  • goto
  • types

The goal is to have to compiler ported over in time for Go 1.4.

A few sessions latter, Peter Bourgon (@peterbourgon) shared best practices for production environments. This talk was one of my favorite talks of the entire conference. Peter gave very concrete and simple advice for creating production ready Go applications. The main theme of his recommendations was to keep it simple, and use the tools that are built in. Sourcegraph has a fantastic post for this talk on their live blog that I would highly recommend reading.

Victor Vieux (@vieux) gave a talk on the motivations behind building Docker, and the pluses and minuses behind their choice to write it in Go. They built Docker to solve the matrix from hell, with the goal of making universal "shipping containers" for software. They chose Go because it gave them a single binary, was a choice few hated, and was easy to contribute to. The main drawbacks are dependency management, the flag package not being mature, and the language in general still being a bit young.

Concurrency is hard in games, how hard is concurrency in Go? - Fraser Graham

Next Stephen McQuay (@smcquay) and Fraser Graham (@twisted_weasel) gave a talk on building games in Go. They talked about timing and event management, which are they built using go routines and channels. Then they talked about bandwidth management before giving a demo of their game. They showed some ways they were able to reduce the size of the JSON they were sending to and from the server.

After lunch Ron Evans (@deadprogram) and Adrian Zankich (@adzankich) of the Hybrid Group gave a demonstration of Gobot. They gave a very similar talk at Golden Gate Ruby Conference using Artoo, a Ruby robotics library. They showed the Gobot code to control an Arduino, a Beagle Bone Black, a Spero, and a few different way of controlling an Ardrone.

One of the great things about Gophercon was how many Go core team members were in attendance and giving talks. This allowed Blake Mizerany (@bmizerany) to change his originally planned talk into a panel discussion with the Go team members. Once again, I am going to defer to the Soucregraph live blog of the panel for detailed notes.

Baron Schwartz (@xaprb) talked about building applications with database/sql. He gave a lot of practical advice on how to best use Go's database/sql module. He talked about the db object being "global", do not open and close from function to function, how connection pooling is being managed for you under the hood, and he compared db.Query, db.QueryRow, and db.Exec and when you should use each. He recommended as a resource for further learning best practices for using database/sql.

Closing Keynote

The conference ended with a keynote from Go team member Andrew Gerrand (@enneff). He gave the story about how he came to Go, and some fantastic insights on writing simple clean Go code. Some of the topics covered were interfaces, concurrency, syntax, error handling, packages and documentation. He talked about how interfaces, when done well, can make your code elegant. He talked about some of the design choices that went into Go's concurrency model, and did a walk through of the Equivalent Binary Tree problem from Go Tour.

Let’s build small, simple, and beautiful things together - Andrew Gerrand


Gophercon 2014: Keynote

Speaker: Rob Pike @rob_pike

Breaking down hello world

  • package
    • visibility is package-level, not type-level
    • inspired by Modula-2, etc.
  • main (package)
    • was originally called "Main"
    • special because root of initialization tree
  • import
    • implemented by the compiler, not a text processor
    • import a package, not a set of identifiers
    • export used to be a keyword
  • "fmt"
    • package path is just a string, not a list of identifiers, allows for additional behavior
  • func
    • used to be the function keyword
    • Larry Page asked "why isn't function spelled func"
  • main
    • where the program starts... except it isn't
    • separation of initialization from normal execution
  • ()
    • no return value from main
    • no arguments, the run time handles it
  • {
    • braces not spaces
    • "I think it’s a profound mistake in language design to have your program functionality depend on invisible characters"
    • why is the newline after the brace?
    • consequence of semicolon injection
  • fmt
    • all imported identifiers are qualified by their import
    • profound effect on readability
  • .
    • lots of uses for a period token
    • the meaning of a.B requires using the type system
  • Println
    • capitals for export
    • always knew it would be reflection-driven. (Safety, format-less printing)
  • ( not much to say
  • "Hello, Gophers..."
    • UTF-8 input source, so strings as literals are UTF-8 automatically
  • )
    • no semicolon
    • used to have them, but eventually accepted the BCPL approach
  • }


  • factors
    • what matters in a language, what doesn't
    • nothing went in unless all three agreed
    • concentrated effort by a small dedicated team
    • GC
    • concurrency
    • gofmt
    • static types but dynamic feel
    • built for programming in the large
  • less obvious
    • concentrated development followed by freeze
    • consensus of a small core team
    • rich ecosystem

Prime sieve

  • concurrency
  • select
    • if you don't have select you don't have concurrency
  • Sieve program unchanged since 2009 - stable!
  • "Key to Go's success, stopping the change at some point"

The future

  • this is where the community comes in


  • "When builds take 45 minutes, you have time to think about what might be better..."
  • would like to see better ways to write concurrency libraries
  • no dependency management in the core language, should be done by the open source community
  • no breaking changes
  • "errors are not special, thats the defining point of them"