Out of all the Golang conferences around the world, there isn’t one that is as awesome (and rainy) as GolangUK. Its third edition just took place in London, and it was as British as ever.
Some conferences have unconferences, also known as “Uncons”. These are similar to the main tracks with proper talks, but they are completely improvised. This is a great environment for hidden talent to be pushed to share their ideas and speak for a few minutes, especially if applying to speak in front of hundreds is too daunting.
So one would expect GolangUK to have something like it. And it did – but with a nice local touch. They called it Pubcon, and you were invited to share your awesome thoughts with your second pint of beer in hand.
And this is how GolangUK got its unofficial kickstart – with a few dozen engineers drinking beer and having energic battles over dependency management and the evils of GOPATH.
However, whilst drinking and ranting are some of the things to love about conferences, learning is perhaps the most important part. And there were some very interesting lessons to learn from this one.
Here are my top three.
Go has come a long way
Steve showed the major milestones of Go. Created in 2007, open-sourced in 2009, 1.0 in 2012. Since then, many things have happened. But perhaps the biggest change as of late has been a change of mindset; the community has been summoned to start thinking about what should Go 2 be.
But not all milestones are technical. To me, what stuck out the most is the way that the Go team is involving community members to lead parts of the Go project.
They call them Working Groups, and they tackle issues ranging from important new features like dependency management to making sure that new users and contributors feel welcome.
It’s important to note that many of the biggest challenges that the project has identified have to do with people, not computers. After all, Go is a language that’s aimed at developers, not at machines.
CPU profiling is likely not what you want
Go is the language of the cloud. And by cloud, I mean servers. The language has been designed to make it easy to work with concurrency and asynchronous work. Yet when developers encounter a bottleneck, they tend to look at the CPU alone.
I am not a good example here – I’ve used pprof many times without even questioning if the source of a slow-down was CPU usage. The worst part is that, as Filippo shows, CPU profiling data can point us at the wrong solution.
The right way to tackle bottlenecks in most cases is the Go tracer. It keeps track of all execution events, from goroutine activity to network and GC work. So, for the love of god, stop giving your CPU suspicious looks.
Contributing to Go can be daunting
Audrey taught herself programming in Go. Like many of us, she’s long looked up to long-time Go contributors and team members. So when she started looking at making her first contribution to Go, she was confused and a bit scared.
Her story read like a rollercoaster. She encountered many barriers, like learning how to use Gerrit or having the patience to take in reviews and redo most of her code. But she got patient guidance and help throughout, which is why she stuck around and succeeded.
What stuck out to me from this talk is the perspective. As a developer, sometimes it’s hard to remember how hard it was to get things done when you were getting started. Imagine having to learn how to use git, on top of getting your solution working.
It will be interesting to see how the Go project will continue to improve this experience as more and more contributors show up at their doors. Given the level of community seen in action at GoLangUK 2017, I think this will play a big part.