← Home

Notes on the Golang UK Conference 2016

Last week, I went to the Golang UK conference with some other Go aficionados from Infinity Works Consulting.

Here’s a few highlights from my favourite conference talks and workshops.

Advanced Go Workshop with William Kennedy

I’d signed up for the day-long Advanced Go Workshop with William Kennedy. It was a funny and opinionated session, covering a range of topics. Too much to cover, especially on the profiling side, but here’s a few things I took away:

To take more care around memory allocations in API design, in particular to consider not returning a new array or struct, but instead allowing a reference to be passed in, allowing the reuse of an existing memory allocation. This is typified by the json.Unmarshal function [0]

Not adding to interface bloat in Go. Since interfaces are implemented implicitly in Go, a user of my code can simply create their own interface with the signatures of my methods on it, or even better, just the methods they’re using.

To take a look at the [1] package and consider using it to make sure that my servers don’t just drop connections when I shut them down.

Make sure I’m logging message throughput between Go routines.

Idiomatic Go Tricks - Mat Ryer

This was a great talk, and definitely one I’m going to share with teams that I’m working with when it reaches YouTube, to make sure that people understand and follow the idioms and style of Go. The Go Programming Language book talks about this, and Mat’s talk expanded on that with a raft of interesting tidbits.

Dropping down: Go functions in assembly - Michael Munday

I enjoyed this one, not least because it gave me a bit of insight into a part of the development world I don’t normally see. Michael is one of the development team porting Go to the IBM LinuxOne mainframe.

You can see what one looks like at [2]

Michael’s put together some example functions at [3]

Static Deadlock Detection - Nicholas Ng

It’s possible to have a situation in Go where all of the Go routines in a program are waiting for another Go routine to send a message into a channel, but this is only found at runtime, causing a panic. This panic also only happens when all of the routines are waiting, when it could be that one unrelated Go routine is happily carrying on, with the program not executing as intended. This is not a good thing.

The research that Nicholas has been doing was about how the patterns of Go routine usage can be extracted from Go code and the resultant graph analysed to determine whether a deadlock could occur given that usage pattern (whether the communication types are “compatible”) without having to run the app to find out (i.e. static analysis).

The research builds on process calculi and some of the work presented by Francesc Campoy at the Golang UK conferece talk he did last year. I haven’t had chance to watch it yet, but it’s here: [4]

Nick’s deadlock detector is available online at [5]

Advanced Patterns with io.ReadWriter - Paul Bellamy

The main point I took away here is that I need to spend a bit more time to fully explore the io and bufio packages to make sure I know about all the useful stuff that’s in there, e.g. that the TeeReader can read and copy a stream at the same time.

Building Mobile SDKs for iOS and Android - Nic Jackson

I hadn’t really looked at Go’s mobile features, and was surprised by how useful it appeared. Nic created a protocol buffers server and client in Go, built the client for Android using Go Mobile and imported it straight into Android studio, producing a live demo of an instant messaging app running on Android. Even more bravely, he let the audience write messages on the screen behind him while he talked.

Go Mobile is still labelled as experimental, but I’m definitely going to keep watching where it goes, see [6]

Seven ways to profile Go applications - Dave Cheney

Great talk from Dave on the features that Go has for profiling. The tools that you get for free with Go are absolutely fantastic. Another one to catch on YouTube ASAP.

What is a container, really? Let’s write one in Go from scratch - Liz Rice

This was a really well-attended talk, the room was totally packed. Liz said that she got permission to base her talk on Julien Friedman’s article at [7]

I think that a lot of people left the room with a completely different picture of what a container is after watching this talk, i.e. it definitely isn’t a VM!

Real-Time Go - Andreas Krennmair

I always like to hear about real-world problems and how teams solve them, so this talk was right up my alley, talking about how his team managed to participate in sub 100ms auctions for ad impressions.

The talk started with an overview of types of real-time constraints which put things into perspective:

  • Hard - Where failure to act can result in extremely negative consequences, like death if your ABS braking system fails.
  • Firm - Where overall service quality is important, but some deadlines could be missed.
  • Soft - Where the usefulness of the service degrades.

Some good advice around being careful to benchmark 3rd party code, and not just assume that just because lots of people use it, that its performance will actually be any good. Having been bitten by this in the past, I’m definitely on board with this.

It was interesting that Andreas said his team couldn’t discern any drop in performance after enabling a [8] pprof server into their system to monitor their system in production.

With a garbage-collected language, there’s always the potential for a stop-the-world garbage collection event, but Andreas noted that GC events for their system were typically sub millisecond.

Andreas has a page on github with some references from the talk around auction game theory and stuff: [9]

Real-time machine learning in Go for smart energy applications - Michael Bironneau

From what Michael said in the talk, it appears that his company (Open Energi) work with large-scale electrical power consumers (e.g. factories and large buildings) to coordinate their power consumption in a cost effective way by participating in the national energy market. For example, if the grid is under-producing power, to be able to cancel that out by switching off flexible power consumption in the Open Energi network. This would be cheaper than actually producing the power using coal or gas, etc. Similarly, network members could signal their intention to use power and defer buying it until the wholesale cost is cheap. A bit like buying spot instances on AWS I suppose.

The meat of the talk was an overview of classification and prediction problems, and a quick round-up of Go machine learning toolsets.

One tip that Michael gave which I’d definitely echo is to make sure that whatever tool you use allows you to persist the trained model. Training can take a long time, so you want to be able to save the results for reuse. When I first started playing about with machine learning toolkits, I spent some time learning a tool that couldn’t do that, but of course, I only noticed when I had some good results.

Michael said that the [10] library was a good one which could save the model, but ultimately, the data scientists were sticking with the Python scikit-learn system. He also said that the data scientists use the [11] tool on a day-to-day basis.