Recommending GoLang at Target
Early last month, as a part of the quarterly Enterprise Architecture Workshop, the Target technical community presented the case to promote GoLang to recommended status for teams when choosing how to build their applications.
The Back Story
A Brief Aside for Go
GoLang is an open source programming language initially developed by Google in 2009 by Robert Griesemer, Rob Pike and Ken Thompson. It focuses on making high-speed, native programming easy. A unique feature of Go is its built-in concurrency primitives called goroutines and channels.
Two Years Ago
Go quickly arrived at Target and slowly began demonstrating value to large enterprise initiatives where High Input/Output and concurrency were requirements. As engineers moved across the organization, a subset of the larger technical community began advocating for usage of Go. As usage increased the Enterprise Architecture team began to take notice and held a session discussing the placement of Go in our Recommended Technologies Guide, a field guide designed to ensure unified technical direction for teams across the organization.
During the workshop in 2016, the team was hesitant to give a broad recommendation for GoLang since it was still relatively young at Target. They cited concerns about the longevity of the Go community and wanted to watch closely to ensure the language was not just a fad inside of our engineering community. Additionally, there was another legitimate concern around the ability to hire Go programmers. The majority of those using Go within our community at the time learned on the job through self-teaching. This meant there was a risk to the enterprise that perhaps if Go were to fade in popularity, it would be become more difficult to find developers to support projects developed in the language.
Over the next two years, many applications across Target started using Go. Teams began finding more developers who knew Go before coming to joining us. As time went on, there were continuing discussions with the EA team around Go as they continued to watch its growth at within our teams.
Getting Back to the Workshop
When I joined Target, I knew I wanted to be deeply involved in the technical community I found around me (Shameless Plug: Target has one of the best technical communities of academics and self-taught technical people around, you should check us out :-)). I began participating in chat rooms and contributing to conversations on issues around me. I found that Go was listed in our guide as “limited use,” meaning before beginning serious efforts on a project, one needed to determine why Java (or other JVM languages like Kotlin and Groovy), Target’s exclusive recommended language, shouldn’t be used. After finding a growing passionate community with large projects in Go, I began participating in conversations with Enterprise Architecture about the subject and providing evidence from across our community on where it was being used.
Surprisingly, I learned I had made a name for myself with Enterprise Architecture concerning many things, but primarily my tenacity in my support for the Go community at Target. In early December, another issue was filed in the Recommended Technologies Guide about promoting Go. I decided to champion the effort, and through my support, we determined it was time to return to the workshop to consider where Go belongs at within our field guide.
I prepared to argue for the language to be promoted to recommended status by studying projects where we were using Go and discerning why so many people had grown to love Go. It was for the reasons most of us do. I found we loved the simplified syntax, strong standard library, great external community, and well-built and maintained libraries. We loved the fast compile times and incredibly small images we could build when deploying containers. As we continue to grow and scale our technical solutions to our guests, we find the concurrency primitives in Go particularly useful.
A few weeks later, I found myself in front of the CIO team with most of our principal engineers listening to me explain my stance on Go. A few voiced concerns around our general uniformity around the JVM and the unique integrations we can yield in frameworks such as Spring and Ratpack. After good discussion, we came to the conclusion that working with the community, we could construct similar integrations into Go applications built here.
In the end, we did determine that GoLang should be a recommended technology for teams, focusing primarily on systems engineering tasks and scopes where the advantages of Go make sense. We were all very pleased with the progress the Go project had achieved over the last two years and with the teams using Go.
The Future Going with Go
Now that Go is a recommended technology for Target’s engineering staff, we can more liberally use Go, in tandem with
JVM languages that are also recommended. We continue to use both languages to do what we do best, helping our guests
discover joy. Our GoLang community celebrated – then we got back to our sprints happily
About the Author
James Bell is an engineer working with guest reliability engineering in Target Technology Services, helping enable a more reliable technical solutions. He is the author of GREASE and regularly attends technical events in the MSP area. He is passionate about architecture, distributed computing and technical evangelism.