What do gophers, Google, and a conference have to do with each other? That’s GopherCon, the Go programming language conference, in a nutshell. Google created Go in 2009 for those (and Google itself) who want to make fast, readable, and efficient programs with batteries included, meaning that the language comes with powerful libraries (toolboxes) built in. The gopher (anamorphic, bright teal) is Go’s mascot, and GopherCon quickly sprung up in 2014 to help gophers (Go users) stay at the forefront of the language.
I’ve been using Go for 5 years, and this is my third GopherCon, but that doesn’t mean I didn’t learn a ton. In fact, it has made it easier to understand the technical complexity in many of the talks, which happen to be my favorites. Going into GopherCon this year, my goals were to learn more about the way humans interact with code– sources disagree on the exact percentage, but developers generally spend about 60% of the time reading, rather than writing, code–, to learn more of the technical details behind Go’s garbage collector, which is how it manages memory (RAM) as it runs programs, and to come back writing better and faster Go code.
On the human-code interaction side, Kaylyn Gibilterra spoke about how code tells a story– and how Go, specifically, is great at telling it. You’ve probably heard about the hero’s journey, which is a common story framework where a character goes on an adventure, wins a big battle, then comes back transformed or dramatically changed. Go code often works this way, too. When you call a function from a package (a sort-of toolbox that either you, the language authors, or a third-party contributor wrote), it’s like your code is a character going on an adventure to the toolbox. It either wins its battle and comes back transformed (the output) or it encounters an error and comes back with information on how to do it better. This also shapes how we should document our code to tell this story. Rather than talking plainly about what a function accepts as its inputs and provides back as its outputs, let’s talk about it like a story. Maybe developers will be able to spend a majority of their time writing code. They want to.
My favorite talk last year was about Go’s garbage collector, of mark-sweep fashion. Every “cycle” (a few milliseconds, decided by a PID controller, something I’m familiar with from ESA!), it (sequentially) marks all the memory that is no longer in use, then it sweeps (in parallel) over the marked memory and frees it up. Last year, I learned how it works. This year, I built my knowledge. Bytedance (the parent company of TikTok) is such a large digital services company and has such a large amount of Go in their codebase, even small performance improvements go a long way. Their Go toolchain team found that Bytedance code often used small variables (250 characters or less) for very short amounts of time, something that Go’s garbage collector doesn’t do efficiently. Yifei Zhang spoke about how they modified the garbage collection process to chunk these small variables together. They’d then tell the garbage collector they have just one larger variable, which is much more efficient. This is a giant undertaking, and I learned not just the fanatical complexity behind these systems that programmers take for granted, but also that sometimes–especially for small and medium companies– it’s better to work within Go’s parameters than to try to make it more efficient. Yifei’s team’s gains? 4-10% at best.
I don’t have time to write about other fantastic talks, like Bryan Boreham’s talk about “loser trees,” a novel and ultra-fast-in-Go merge algorithm, Konrad Reiche’s talk about highly-concurrent caches, and more. But I know that I’m coming back to write more idiomatic, efficient, and story-driven Go. I can’t wait to use it in class and at work.
