QCon10Years
Conference:March 7-9, 2016
Workshops:March 10-11, 2016
Sign up to be informed when registration opens for QCon London 2017 (3/6 - 3/10)

Presentation: Successful Go program design, 6 years on

Track: 
Modern Native Languages

Location:

  • Mountbatten, 6th flr.

Duration

Duration: 
1:40pm - 2:30pm

Day of week:

  • Wednesday

More talks on:

Key Takeaways

  • Hear recommendations on patterns and best practices for developing successful, scalable, and sustainable code using Go.
  • See a microservice built from the ground up with Go and understand what it capabilities are.
  • Learn what the capabilities of Go are and how it can be used for great effect.

Abstract

Go has emerged from its infancy, and is now one of the preëminent languages in the server, microservice, and infrastructure space. This talk collects lessons learned from 6 years of professional Go development, highlighting the idioms, design patterns, and practices that have proven themselves at scale — and many that haven't. Attendees will leave with a stronger understanding of what good Go code looks like, and with strategies to improve their own Go projects.

Interview

Question: 
QCon: What is your history with Go?
Answer: 
Peter: I’ve been using Go since literally day one: the day it was released, I started working with it.
I’ve been using Go professionally full-time since 2011 (that was pre-1.0), at SoundCloud and now at Weaveworks. Weaveworks is a core technology company in the Docker space. So far, I’ve developed several large open source projects in Go, including Roshi, which is a sort of time series event database, and Go kit, which is a toolkit for microservices.
I’ve also been a speaker at GopherCon for the past two years. I spoke at dotGo last year, and I have spoken about Go at QCon and other conferences for a number of years.
Question: 
QCon: What is the target audience for this talk?
Answer: 
Peter: My primary audience is people who are using Go, but maybe they don’t have Go experts on their team or in their organization. The developer might be still kind of feeling out the idioms, and they aren’t totally confident about program structure or best practices. I’d say that’s about 60% of the target for the talk.
Then there are the people who are interested in learning Go, but they want to get a better feel for what good Go code looks like. Or maybe they want to know what sort of things they can expect if they get into the language and ecosystem.
I’ll sketch out a microservice in Go, and I’ll show how to do a variety of things. This is how you manage dependencies. This is how you declare and wire up your components. This is what an idiomatic HTTP server looks like. I go step by step, so the audience can get a sense of building up a Go project from first principles, while avoiding mis-steps and dead-ends.
Question: 
QCon: Can you give some example of things you’ll discuss in your talk?
Answer: 
Peter: I think there’s a lot of confusion in Go about appropriate use of interfaces.
A lot of people tend to under-use interfaces, and I see a lot of interfaces in the wild that are too big, or express an awkward type of abstraction. It’s been my experience there is a correct way (or a set of correct ways) to think about the Interface. For example, I like to define interfaces with the consumer, rather than the producer, and treat them as a sort consumer contract.
Of course, you can define them with the producer, but only if you want to express that that interface is an API that you intend to support. Otherwise, defining it at the consumer side has all sorts of benefits with unit testing, code modularity, and that sort of thing. I will run through examples showcasing the bad and then the good ways of using interfaces.
The talk is really a cookbook of these types of things. I try to enumerate several ways of doing things, and describe which ones are good, which ones are bad, and the reasoning behind the classification. I’ll also try to tell stories about when going to bad way has burned me in the past.
Question: 
QCon: You talk about scale in your abstract. Can you put that in context for me?
Answer: 
Peter: Scale exists in two dimensions for me.
On the one hand, it’s operational scale. How many requests per second does your code serve? How many instances does it run? (That’s important, and I have some war stories.) How do you efficiently shard requests in a data system—that sort of thing. I’ll touch on designing for scale in this sense.
On the other hand, scale speaks to the size of the team that you’re working in. How many developers are touching this codebase? How do we write code that is humane, both to ourselves and to our peers? That’s what I’m going to be focusing on, more than just raw performance.

Peter Bourgon Elsewhere

GitHub

Similar Talks

Hot code is faster code - addressing JVM warm-up
Building a Modern Security Engineering Team
Real-Time Fraud Detection with Graphs
Effortless Eventual Consistency with Weave Mesh
GoshawkDB: Making time with Vector Clocks
Distributed Consensus: Making Impossible Possible
Lead the Revolution by Being Ordinary
Mens Sana in Corpore Sano: Optimising Mind & Body
The Microservices and DevOps Journey

Tracks

Covering innovative topics

Monday, 7 March

Tuesday, 8 March

Wednesday, 9 March

FULL SCHEDULE

Conference for Professional Software Developers

Follow QCon

Contact

Menu

QCons around the World

Qcon