Thoughts from GopherCon 2017
Published on 2017-07-17
Just got back from GopherCon 2017, my first Go conference. It was great to meet a lot of prominent people in the community and hear some new ideas. I'm writing down some thoughts and ideas while they're still fresh.
Obviously, I have to start with this. Russ Cox announced that we're beginning to think about Go 2. He asked the community to contribute experience reports about what's not working in Go 1. We need to understand the problems we have and how they affect large projects before deciding on solutions.
Generics are a feature that almost everyone wants, but I don't think anyone knows how to implement these in Go in a way that makes sense. Check out the Java generics FAQ if you don't believe generics are complicated. I spent a lot of time building generics in Gypsum, and what I came up with still doesn't make sense to me and isn't quite what I want.
Personally, I'd love to see immutable references make it into the language. I think some of the safety could be "borrowed" from Rust without the full complexity of ownership and lifetimes. I hope to experiment with this in Gypsum soon.
Compatibility is crucial for the transition to Go 2. Libraries written in Go 2 must be compatible with Go 1 and vice versa. We don't want a Python 3 situation.
One last thing: please no articles titled "Go 2 considered harmful". I will be sad.
Go Reliability and Durability at Dropbox
Tammy Butow gave an overview of how Go is used at Dropbox. I was thrilled to hear her mention Bazel. They are early adopters, so they wrote their own Go support. I hope once the Go rules are more mature, they can use those.
Generating Better Machine Code with SSA
Keith Randall gave a talk on migrating the compiler to use a static single assignment representation. I love the "how things work" style of talk. Some non-compiler folks I spoke to at lunch said they found this really interesting.
A Go Programmer's Guide to Syscalls
Liz Rice gave a demo where she wrote strace in about 60 lines of Go in 45 minutes. Very nice. The ptrace system call is incredibly powerful, but you need a lot of information about the program being traced to use it effectively.
Self Deploying Kubernetes Applications
Kelsey Hightower gave a talk on Kubernetes programs with integrated configuration and deployment. I'm a Kubernetes noob, so this one went over my head a bit. I would expect that separating configuration/deployment from the programs being deployed would be a good idea, but maybe it's a painful enough experience that an integrated approach is better. It was definitely a cool demo. Kelsey is a great speaker.
Edward Muller spoke about some patterns to avoid in Go. It was an interesting talk, and a very popular one. I'm guilty of a few of these. Although this talk was full of good advice, it reminded me of overly prescriptive best practices in Java. I hope the Go language and community don't evolve along the same path.
Kavya Joshi gave what was probably my favorite talk. Again, I love the "how things work" style of talk. I think I understand what sudog is now (a goroutine on a wait list). Ian Lance Taylor brought it up in a discussion the previous night as a definition with a terrible name, but I didn't ask what it was.
Advanced Testing with Go
Mitchell Hashimoto gave a lot of really useful testing tips. A couple of my favorites:
Golden files: If your tests involve comparing large chunks of data with expected values, it's a good practice to store the expected data in golden files, especially with images (screenshots). You can define a flag that makes the test write the golden files before comparing them. Updating tests is a lot easier with this.
Functional Programming in Go
Aaron Schlesinger gave a demo with some functional primitives in Go, including Map, Optional, and Either. It was interesting, but I don't see this being useful without generics. It requires a lot of manual interface implementation for each type.
The New Era of Go Package Management
Sam Boyer closed out the conference with some discussion on dep, which is the "official experiment" for dependency management. It's still experimental, but I like the design. Dependency management is important enough that it really should be part of the toolchain, and this is a step in the right direction. Bazel does some dependency management on its own, so we'll need to figure out a way to be compatible with this.
I was a mentor at the Go Contributors Workshop on community day. We helped people walk through the process of setting up code review tools and using PolyGerrit, the review tool used in Go repositories. After submitting a change to a scratch repository, people were encourages to start by adding examples or improving documentation.
I think this process was useful for getting people involved. It was also good to find some difficulties in the onboarding process.
The contribution guide has more detailed information if you weren't able to go to the workshop and want to contribute.