The Go Blog

Updating the Go Code of Conduct

23 May 2018

In November 2015, we introduced the Go Code of Conduct. It was developed in a collaboration between the Go team members at Google and the Go community. I was fortunate to be one of the community members invited to participate in both drafting and then enforcing the Go Code of Conduct. Since then, we have learned two lessons about limitations in our code of conduct that restricted us from being able to cultivate the safe culture essential to Go’s success.

The first lesson we learned is that toxic behaviors by project participants in non-project spaces can have a negative impact on the project affecting the security and safety of community members. There were a few reported incidents where actions took place outside of project spaces but the impact was felt inside our community. The specific language in our code of conduct restricted our ability to respond only to actions happening “in the official forums operated by the Go project”. We needed a way to protect our community members wherever they are.

The second lesson we learned is that the demands required to enforce the code of conduct place too heavy of a burden on volunteers. The initial version of the code of conduct presented the working group as disciplinarians. It was soon clear that this was too much, so in early 2017 we changed the group’s role to that of advisors and mediators. Still, working group community members reported feeling overwhelmed, untrained, and vulnerable. This well-intentioned shift left us without an enforcement mechanism without solving the issue with overburdened volunteers.

In mid-2017, I represented the Go project in a meeting with Google’s Open Source Programs Office and Open Source Strategy Team to address the shortcomings in our respective codes of conduct, particularly in their enforcement. It quickly became clear that our problems had a lot in common, and that working together on a single code of conduct for all of Google’s open source projects made sense. We started with the text from the Contributor Covenant Code of Conduct v1.4 and then made changes, influenced by our experiences in Go community and our collective experiences in open source. This resulted in the Google code of conduct template.

Today the Go project is adopting this new code of conduct, and we’ve updated This revised code of conduct retains much of the intent, structure and language of the original Go code of conduct while making two critical changes that address the shortcomings identified above.

First, the new code of conduct makes clear that people who participate in any kind of harassment or inappropriate behavior, even outside our project spaces, are not welcome in our project spaces. This means that the Code of Conduct applies outside the project spaces when there is a reasonable belief that an individual’s behavior may have a negative impact on the project or its community.

Second, in the place of the working group, the new code of conduct introduces a single Project Steward who will have explicit training and support for this role. The Project Steward will receive reported violations and then work with a committee, consisting of representatives from the Open Source Programs Office and the Google Open Source Strategy team, to find a resolution.

Our first Project Steward will be Cassandra Salisbury. She is well known to the Go community as a member of Go Bridge, an organizer of many Go meetups and conferences, and as a lead of the Go community outreach working group. Cassandra now works on the Go team at Google with a focus on advocating for and supporting the Go community.

We are grateful to everyone who served on the original Code of Conduct Working Group. Your efforts were essential in creating an inclusive and safe community.

We believe the code of conduct has contributed to the Go project becoming more welcoming now than it was in 2015, and we should all be proud of that.

We hope that the new code of conduct will help protect our community members even more effectively.

By Steve Francia

Go's New Brand

26 April 2018


I am delighted to announce the launch of Go’s new look and logo.

Go has been on an amazing journey over the last 8+ years. Our project, community and users have evolved through this journey and we wanted the Go brand to reflect where we have been and convey where we are going.

Go’s new brand is about our identity, our values, and our users. Over the past several months we have worked with a brand agency to develop a brand guide for Go. Our agency, Within, coordinated with and built upon the great foundation that Renee French established. Rest easy, our beloved Gopher Mascot remains at the center of our brand.

New Logo

Our logo follows the brand’s core philosophy of simplicity over complexity. Using a modern, italicized sans-serif typeface combined with three simple motion lines forms a mark that resembles two wheels in rapid motion, communicating speed and efficiency. The circular shape of the letters hints at the eyes of the Go gopher, creating a familiar shape and allowing the mark and the mascot to pair well together.

Our new logo went through an extensive design process. Here are some of the revisions we went through…

New Brand Guide

The brand guide establishes the mission, values and voice for the Go project. In general terms, a brand guide is a reference tool for establishing a consistent brand identity. It is sometimes referred to as “brand guidelines” or a “brand book”. It is a single document that serves as a guide and reference to designers, writers, and developers to create consistent, on-brand content.

New presentation themes

In addition to our brand guide we have also developed a presentation theme. This presentation theme will enable us to have a consistent representation of Go in person at meetups and conferences as well as online. Go community members are welcome to use this theme for their own presentations.

The presentations are available as Google Slides presentations. We chose Google slides as it is easy to share and maintain updates. People are welcome to port them to keynote, powerpoint, etc.

Like this blog and all our gopher images, the slide themes are Creative Commons Attribution 3.0 licensed. The photos in the slides are all from unsplash and are released under the unsplash license.

Instructions to use slides:

  • Open the Go Slide Masters presentation on Google slides.
  • File > “Make a Copy” (you may need to login first)
  • Create new slides using the layouts provided in the layouts menu.
  • Use the included example slides to help guide the styling and creation of your presentation.


The brand guide, logo and themes are copyrighted by the Go authors.

The brand guide contains the guidelines for acceptable logo use.

What’s happening next

The website will be getting a refresh based on the new design. Since we are making significant changes, we are also taking this opportunity to update our website infrastructure to better serve our global community with internationalization and multilingual support. The migration will happen in stages over the next few months starting with this blog.

By Steve Francia

A Proposal for Package Versioning in Go

26 March 2018


Eight years ago, the Go team introduced goinstall (which led to go get) and with it the decentralized, URL-like import paths that Go developers are familiar with today. After we released goinstall, one of the first questions people asked was how to incorporate version information. We admitted we didn’t know. For a long time, we believed that the problem of package versioning would be best solved by an add-on tool, and we encouraged people to create one. The Go community created many tools with different approaches. Each one helped us all better understand the problem, but by mid-2016 it was clear that there were now too many solutions. We needed to adopt a single, official tool.

After a community discussion started at GopherCon in July 2016 and continuing into the fall, we all believed the answer would be to follow the package versioning approach exemplified by Rust’s Cargo, with tagged semantic versions, a manifest, a lock file, and a SAT solver to decide which versions to use. Sam Boyer led a team to create Dep, which followed this rough plan, and which we intended to serve as the model for go command integration. But as we learned more about the implications of the Cargo/Dep approach, it became clear to me that Go would benefit from changing some of the details, especially concerning backwards compatibility.

The Impact of Compatibility

The most important new feature of Go 1 was not a language feature. It was Go 1’s emphasis on backwards compatibility. Until that point we’d issued stable release snapshots approximately monthly, each with significant incompatible changes. We observed significant acceleration in interest and adoption immediately after the release of Go 1. We believe that the promise of compatibility made developers feel much more comfortable relying on Go for production use and is a key reason that Go is popular today. Since 2013 the Go FAQ has encouraged package developers to provide their own users with similar expectations of compatibility. We call this the import compatibility rule: “If an old package and a new package have the same import path, the new package must be backwards compatible with the old package.”

Independently, semantic versioning has become the de facto standard for describing software versions in many language communities, including the Go community. Using semantic versioning, later versions are expected to be backwards-compatible with earlier versions, but only within a single major version: v1.2.3 must be compatible with v1.2.1 and v1.1.5, but v2.3.4 need not be compatible with any of those.

If we adopt semantic versioning for Go packages, as most Go developers expect, then the import compatibility rule requires that different major versions must use different import paths. This observation led us to semantic import versioning, in which versions starting at v2.0.0 include the major version in the import path: my/thing/v2/sub/pkg.

A year ago I strongly believed that whether to include version numbers in import paths was largely a matter of taste, and I was skeptical that having them was particularly elegant. But the decision turns out to be a matter not of taste but of logic: import compatibility and semantic versioning together require semantic import versioning. When I realized this, the logical necessity surprised me.

I was also surprised to realize that there is a second, independent logical route to semantic import versioning: gradual code repair or partial code upgrades. In a large program, it’s unrealistic to expect all packages in the program to update from v1 to v2 of a particular dependency at the same time. Instead, it must be possible for some of the program to keep using v1 while other parts have upgraded to v2. But then the program’s build, and the program’s final binary, must include both v1 and v2 of the dependency. Giving them the same import path would lead to confusion, violating what we might call the import uniqueness rule: different packages must have different import paths. The only way to have partial code upgrades, import uniqueness, and semantic versioning is to adopt semantic import versioning as well.

It is of course possible to build systems that use semantic versioning without semantic import versioning, but only by giving up either partial code upgrades or import uniqueness. Cargo allows partial code upgrades by giving up import uniqueness: a given import path can have different meanings in different parts of a large build. Dep ensures import uniqueness by giving up partial code upgrades: all packages involved in a large build must find a single agreed-upon version of a given dependency, raising the possibility that large programs will be unbuildable. Cargo is right to insist on partial code upgrades, which are critical to large-scale software development. Dep is equally right to insist on import uniqueness. Complex uses of Go’s current vendoring support can violate import uniqueness. When they have, the resulting problems have been quite challenging for both developers and tools to understand. Deciding between partial code upgrades and import uniqueness requires predicting which will hurt more to give up. Semantic import versioning lets us avoid the choice and keep both instead.

I was also surprised to discover how much import compatibility simplifies version selection, which is the problem of deciding which package versions to use for a given build. The constraints of Cargo and Dep make version selection equivalent to solving Boolean satisfiability, meaning it can be very expensive to determine whether a valid version configuration even exists. And then there may be many valid configurations, with no clear criteria for choosing the “best” one. Relying on import compatibility can instead let Go use a trivial, linear-time algorithm to find the single best configuration, which always exists. This algorithm, which I call minimal version selection, in turn eliminates the need for separate lock and manifest files. It replaces them with a single, short configuration file, edited directly by both developers and tools, that still supports reproducible builds.

Our experience with Dep demonstrates the impact of compatibility. Following the lead of Cargo and earlier systems, we designed Dep to give up import compatibility as part of adopting semantic versioning. I don’t believe we decided this deliberately; we just followed those other systems. The first-hand experience of using Dep helped us better understand exactly how much complexity is created by permitting incompatible import paths. Reviving the import compatibility rule by introducing semantic import versioning eliminates that complexity, leading to a much simpler system.

Progress, a Prototype, and a Proposal

Dep was released in January 2017. Its basic model—code tagged with semantic versions, along with a configuration file that specified dependency requirements—was a clear step forward from most of the Go vendoring tools, and converging on Dep itself was also a clear step forward. I wholeheartedly encouraged its adoption, especially to help developers get used to thinking about Go package versions, both for their own code and their dependencies. While Dep was clearly moving us in the right direction, I had lingering concerns about the complexity devil in the details. I was particularly concerned about Dep lacking support for gradual code upgrades in large programs. Over the course of 2017, I talked to many people, including Sam Boyer and the rest of the package management working group, but none of us could see any clear way to reduce the complexity. (I did find many approaches that added to it.) Approaching the end of the year, it still seemed like SAT solvers and unsatisfiable builds might be the best we could do.

In mid-November, trying once again to work through how Dep could support gradual code upgrades, I realized that our old advice about import compatibility implied semantic import versioning. That seemed like a real breakthrough. I wrote a first draft of what became my semantic import versioning blog post, concluding it by suggesting that Dep adopt the convention. I sent the draft to the people I’d been talking to, and it elicited very strong responses: everyone loved it or hated it. I realized that I needed to work out more of the implications of semantic import versioning before circulating the idea further, and I set out to do that.

In mid-December, I discovered that import compatibility and semantic import versioning together allowed cutting version selection down to minimal version selection. I wrote a basic implementation to be sure I understood it, I spent a while learning the theory behind why it was so simple, and I wrote a draft of the post describing it. Even so, I still wasn’t sure the approach would be practical in a real tool like Dep. It was clear that a prototype was needed.

In January, I started work on a simple go command wrapper that implemented semantic import versioning and minimal version selection. Trivial tests worked well. Approaching the end of the month, my simple wrapper could build Dep, a real program that made use of many versioned packages. The wrapper still had no command-line interface—the fact that it was building Dep was hard-coded in a few string constants—but the approach was clearly viable.

I spent the first three weeks of February turning the wrapper into a full versioned go command, vgo; writing drafts of a blog post series introducing vgo; and discussing them with Sam Boyer, the package management working group, and the Go team. And then I spent the last week of February finally sharing vgo and the ideas behind it with the whole Go community.

In addition to the core ideas of import compatibility, semantic import versioning, and minimal version selection, the vgo prototype introduces a number of smaller but significant changes motivated by eight years of experience with goinstall and go get: the new concept of a Go module, which is a collection of packages versioned as a unit; verifiable and verified builds; and version-awareness throughout the go command, enabling work outside $GOPATH and the elimination of (most) vendor directories.

The result of all of this is the official Go proposal, which I filed last week. Even though it might look like a complete implementation, it’s still just a prototype, one that we will all need to work together to complete. You can download and try the vgo prototype from, and you can read the Tour of Versioned Go to get a sense of what using vgo is like.

The Path Forward

The proposal I filed last week is exactly that: an initial proposal. I know there are problems with it that the Go team and I can’t see, because Go developers use Go in many clever ways that we don’t know about. The goal of the proposal feedback process is for us all to work together to identify and address the problems in the current proposal, to make sure that the final implementation that ships in a future Go release works well for as many developers as possible. Please point out problems on the proposal discussion issue. I will keep the discussion summary and FAQ updated as feedback arrives.

For this proposal to succeed, the Go ecosystem as a whole—and in particular today’s major Go projects—will need to adopt the import compatibility rule and semantic import versioning. To make sure that can happen smoothly, we will also be conducting user feedback sessions by video conference with projects that have questions about how to incorporate the new versioning proposal into their code bases or have feedback about their experiences. If you are interested in participating in such a session, please email Steve Francia at

We’re looking forward to (finally!) providing the Go community with a single, official answer to the question of how to incorporate package versioning into go get. Thanks to everyone who helped us get this far, and to everyone who will help us going forward. We hope that, with your help, we can ship something that Go developers will love.

By Russ Cox

Go 2017 Survey Results

26 February 2018

Thank you

This post summarizes the result of our 2017 user survey along with commentary and insights. It also draws key comparisons between the results of the 2016 and 2017 survey.

This year we had 6,173 survey respondents, 70% more than the 3,595 we had in the Go 2016 User Survey. In addition, it also had a slightly higher completion rate (84% → 87%) and a higher response rate to most of the questions. We believe that survey length is the main cause of this improvement as the 2017 survey was shortened in response to feedback that the 2016 survey was too long.

We are grateful to everyone who provided their feedback through the survey to help shape the future of Go.

Programming background

For the first time, more survey respondents say they are paid to write Go than say they write it outside work. This indicates a significant shift in Go's user base and in its acceptance by companies for professional software development.

The areas people who responded to the survey work in is mostly consistent with last year, however, mobile and desktop applications have fallen significantly.

Another important shift: the #1 use of Go is now writing API/RPC services (65%, up 5% over 2016), taking over the top spot from writing CLI tools in Go (63%). Both take full advantage of Go's distinguishing features and are key elements of modern cloud computing. As more companies adopt Go, we expect these two uses of Go to continue to thrive.

Most of the metrics reaffirm things we have learned in prior years. Go programmers still overwhelmingly prefer Go. As more time passes Go users are deepening their experience in Go. While Go has increased its lead among Go developers, the order of language rankings remains quite consistent with last year.

The following apply to me: (multiple choice) 4,201 (67%) I program at work in Go 3,935 (63%) I program in Go outside of work 3,381 (54%) I program at work in another language 1,001 (16%) I manage a programming team 506  (8%) I am a student 113  (2%) Other 27  (0%) No response

I've used Go for: (single choice) 686 (11%) Less than 3 months 1,588 (26%) 3 - 12 months 1,338 (21%) 13 - 24 months 1,678 (27%) 2 - 4 years 809 (13%) 4+ years 102  (2%) I've never used Go 25  (0%) No response

I work in the following areas: (multiple choice) 3,807 (61%) Web development 2,319 (37%) Systems programming 2,250 (36%) DevOps 1,969 (32%) Network programming 1,751 (28%) Databases 848 (14%) Security 777 (12%) Finance/Commerce 724 (12%) Data Science 696 (11%) Mobile 694 (11%) Desktop/GUI applications 647 (10%) Embedded devices/Internet of Things 581  (9%) Academic/Scientific/Numeric 581  (9%) Machine Learning/Artificial Intelligence 334  (5%) Gaming 381  (6%) Other 111  (2%) No response

I write the following in Go: (multiple choice) 4,071 (65%) API/RPC services (returning non-HTML) 3,921 (63%) A runnable/interactive program (CLI) 3,027 (49%) Web services (returning HTML) 2,766 (44%) Agents and daemons (e.g, monitoring) 2,394 (38%) Libraries or Frameworks 2,038 (33%) Automation/scripts (e.g, deployment, configuration management) 2,030 (33%) Data processing (pipeline, aggregation) 167  (3%) I don't write in Go 176  (3%) Other 70  (1%) No response

I write in Go: (single choice) 3,019 (48%) As part of my daily routine 1,802 (29%) Weekly 557  (9%) Monthly 679 (11%) Infrequently 118  (2%) I've never written in Go 51  (1%) No response

Rank the following languages in terms of your expertise 5,540 (30, 27, 17, 9, 6%) Go 3,638 (9, 16, 15, 11, 7%) JavaScript 3,369 (13, 12, 12, 10, 7%) Python 2,706 (11, 8, 8, 9, 7%) Java 2,402 (7, 8, 8, 8, 8%) C 2,020 (2, 5, 9, 10, 7%) Bash 1,631 (4, 4, 5, 7, 6%) C++ 1,475 (7, 5, 4, 4, 4%) PHP 1,042 (4, 3, 4, 3, 3%) C# 1,034 (4, 3, 3, 3, 3%) Ruby 460 (1, 1, 1, 2, 2%) Perl 284 (0.5, 0.6, 0.8, 1, 1%) Scala 278 (0.2, 0.4, 0.8, 1, 2%) Rust 260 (0.3, 0.5, 0.7, 1, 1%) Swift 223 (0.1, 0.2, 0.8, 1, 1%) Lua 185 (0.1, 0.5, 0.7, 0.8, 0.8%) Kotlin 139 (0.1, 0.2, 0.3, 0.6, 1%) Haskell 139 (0.2, 0.2, 0.4, 0.8, 0.6%) Clojure 136 (0.2, 0.3, 0.4, 0.5, 0.8%) R 124 (0.1, 0.2, 0.4, 0.6, 0.7%) Erlang 24 (0.0, 0.1, 0.0, 0.1, 0.1%) Julia 726 (3, 2, 3, 2, 2%) Other 173 (2.8%) No response

Rank the following languages in terms of your preference 5,728 (65, 18, 6, 2, 1%) Go 3,156 (7, 18, 12, 8, 4%) Python 2,463 (3, 9, 12, 8, 7%) JavaScript 1,827 (2, 7, 8, 7, 6%) C 1,764 (2, 6, 7, 7, 6%) Java 1,240 (1, 4, 5, 5, 5%) C++ 1,196 (0.6, 3, 6, 5, 5%) Bash 939 (2, 4, 4, 3, 2%) Rust 924 (2, 4, 4, 3, 2%) C# 859 (2, 4, 3, 3, 2%) Ruby 757 (0.8, 3, 3, 3, 3%) PHP 455 (1, 2, 2, 2, 0.9%) Kotlin 414 (0.7, 1, 2, 2, 1%) Swift 383 (1, 1, 1, 2, 1%) Haskell 335 (0.8, 1, 1, 1, 0.9%) Scala 305 (0.6, 1, 1, 1, 0.9%) Perl 279 (0.3, 0.8, 1, 1, 0.8%) Erlang 250 (0.1, 0.5, 1, 1, 1%) Lua 248 (0.6, 0.8, 1, 0.9, 0.6%) Clojure 113 (0.1, 0.4, 0.4, 0.5, 0.4%) R 71 (0.1, 0.2, 0.3, 0.3, 0.2%) Julia 709 (2, 3, 3, 2, 1%) Other 241 (3.9%) No response

20162017The following apply to me: (multiple choice)4,201 (67%)I program at work in Go3,935 (63%)I program in Go outside of work3,381 (54%)I program at work in another language1,001 (16%)I manage a programming team506  (8%)I am a student113  (2%)Other27  (0%)No responseThe following apply to me: (multiple choice)2,386 (66%)I program in Go outside of work2,235 (62%)I program at work in Go2,004 (56%)I program at work in another language618 (17%)I manage a programming team337  (9%)I am a student78  (2%)Other10  (0%)No response

20162017I work in the following areas: (multiple choice)2,272 (63%)Web development1,359 (38%)Systems programming1,251 (35%)DevOps1,169 (33%)Network programming1,006 (28%)Databases533 (15%)Mobile490 (14%)Desktop/GUI applications457 (13%)Security435 (12%)Data Science417 (12%)Finance/Commerce394 (11%)Embedded devices/Internet of Things379 (11%)Academic/Scientific/Numeric228  (6%)Gaming238  (7%)Other74  (2%)No responseI work in the following areas: (multiple choice)3,807 (61%)Web development2,319 (37%)Systems programming2,250 (36%)DevOps1,969 (32%)Network programming1,751 (28%)Databases848 (14%)Security777 (12%)Finance/Commerce724 (12%)Data Science696 (11%)Mobile694 (11%)Desktop/GUI applications647 (10%)Embedded devices/Internet of Things581  (9%)Academic/Scientific/Numeric581  (9%)Machine Learning/Artificial Intelligence334  (5%)Gaming381  (6%)Other111  (2%)No response

20162017I write the following in Go: (multiple choice)2,247 (63%)A runnable/interactive program2,174 (60%)API/RPC services1,886 (52%)Web services1,583 (44%)Agents and daemons1,417 (39%)Libraries or Frameworks1,209 (34%)Data processing1,120 (31%)Automation/scripts107  (3%)I don't write in Go137  (4%)Other45  (1%)No responseI write the following in Go: (multiple choice)4,071 (65%)API/RPC services3,921 (63%)A runnable/interactive program3,027 (49%)Web services2,766 (44%)Agents and daemons2,394 (38%)Libraries or Frameworks2,038 (33%)Automation/scripts2,030 (33%)Data processing167  (3%)I don't write in Go176  (3%)Other70  (1%)No response

Go usage

In nearly every question around the usage and perception of Go, Go has demonstrated improvement over our prior survey. Users are happier using Go, and a greater percentage prefer using Go for their next project.

When asked about the biggest challenges to their own personal use of Go, users clearly conveyed that lack of dependency management and lack of generics were their two biggest issues, consistent with 2016. In 2017 we laid a foundation to be able to address these issues. We improved our proposal and development process with the addition of Experience Reports which is enabling the project to gather and obtain feedback critical to making these significant changes. We also made sigificant changes under the hood in how Go obtains, and builds packages. This is foundational work essential to addressing our dependency management needs.

These two issues will continue to be a major focus of the project through 2018.

In this section we asked two new questions. Both center around what developers are doing with Go in a more granular way than we've previously asked. We hope this data will provide insights for the Go project and ecosystem.

Since last year there has been an increase of the percentage of people who identified "Go lacks critical features" as the reason they don't use Go more and a decreased percentage who identified "Go not being an appropriate fit". Other than these changes, the list remains consistent with last year.

To what extent do you agree or disagree with the following statements: (strongly disagree, disagree, somewhat disagree, neither agree nor disagree, somewhat agree, agree, strongly agree) 5,938 (2, 0.8, 1, 2, 5, 21, 64%) I would recommend using Go to others (26:1) [32:1] 5,928 (2, 1, 2, 4, 8, 20, 58%) I would prefer to use Go for my next new project (17:1) [23:1] 4,548 (1, 0.8, 1, 7, 9, 23, 31%) Go is working well for my team (21:1) [26:1] 4,716 (5, 6, 4, 17, 14, 14, 17%) Go is critical to my company’s success (3.1:1) [3.1:1]

Reading the data: This question asked how strongly the respondent agreed or disagreed with the statement. The responses for each statement are displayed as sections of a single bar, from “strongly disagree” in deep red on the left end to “strongly agree” in deep blue on the right end. The bars use the same scale as the rest of the graphs, so they can (and do, especially later in the survey) vary in overall length due to lack of responses.

The ratio after the text compares the number of respondents who agreed (including “somewhat agree” and “strongly agree”) to those who disagreed (including “somewhat disagree” and “strongly disagree”). For example, the ratio of respondents agreeing that they would recommend Go to respondents disagreeing was 19 to 1. The second ratio (within the brackets) is simply a weighted ratio with each somewhat = 1, agree/disagree = 2, and strongly = 4.

What is the biggest challenge you personally face using Go today? 582 (9.3%) lack 489 (7.9%) generics 402 (6.5%) management 277 (4.4%) libraries 266 (4.3%) dependency management 194 (3.1%) lack of generics 159 (2.6%) package 137 (2.2%) gui 137 (2.2%) library 132 (2.1%) good 132 (2.1%) work 122 (2.0%) time 115 (1.8%) enough 114 (1.8%) error handling 113 (1.8%) type 109 (1.8%) learning 106 (1.7%) projects 104 (1.7%) hard 97 (1.6%) team 91 (1.5%) dependencies 91 (1.5%) java 87 (1.4%) c 82 (1.3%) debugging 81 (1.3%) no generics 81 (1.3%) vendoring 79 (1.3%) package management 79 (1.3%) programming 77 (1.2%) gopath 76 (1.2%) features 76 (1.2%) types 75 (1.2%) people 74 (1.2%) web 73 (1.2%) python 73 (1.2%) write 68 (1.1%) development 67 (1.1%) generic 67 (1.1%) writing 66 (1.1%) difficult 64 (1.0%) interface 64 (1.0%) tools 63 (1.0%) missing 62 (1.0%) performance 60 (1.0%) interfaces 60 (1.0%) standard 58 (0.9%) community 58 (0.9%) packages 56 (0.9%) build 56 (0.9%) well 55 (0.9%) best 55 (0.9%) cgo 55 (0.9%) debugger 55 (0.9%) ide 55 (0.9%) other languages 55 (0.9%) verbose 54 (0.9%) boilerplate 54 (0.9%) finding 54 (0.9%) learn 53 (0.9%) not enough 2,956 (47.5%) No response

Reading the data: This question asked for write-in responses. The bars above show the fraction of surveys mentioning common words or phrases. Only words or phrases that appeared in 20 or more surveys are listed, and meaningless common words or phrases like “the” or “to be” are omitted. The displayed results do overlap: for example, the 402 responses that mentioned “management” do include the 266 listed separately that mentioned “dependency management” and the 79 listed separately that mentioned “package management.” However, nearly or completely redundant shorter entries are omitted: there are not twenty or more surveys that listed “dependency” without mentioning “dependency management,” so there is no separate entry for “dependency.”

If it were not for the following reasons I would use Go more: 3,077 (31, 14, 4%) I work on an existing project written in another language 2,152 (14, 16, 5%) My project / team / TL prefers another language 1,218 (10, 5, 4%) Go lacks critical features 1,100 (6, 7, 4%) Go lacks critical libraries 1,056 (6, 6, 4%) Go isn't appropriate for what I'm working on 643 (4, 4, 3%) Not enough education or support resources for Go 311 (2, 2, 1%) Go lacks critical performance 790 (5, 4, 3%) Other 1,309 (21%) No response

Which of the following functionality have you implemented (multiple choice) 3,262 (52%) Writing logs/metrics 3,123 (50%) Reading/updating configuration 2,771 (45%) User login and authentication 2,748 (44%) Process to process communication 2,504 (40%) Service authentication/authorization 2,056 (33%) Health checking 1,138 (18%) Keys & secret maintenance 831 (13%) Distributed caching 532  (9%) Distributed tracing 1,269 (20%) No response

Which of the following do you access from Go: (multiple choice) 3,784 (61%) Open Source Relational DB (MySQL/PostgreSQL/CockroachDB) 2,400 (39%) Memory Cache (Redis/memcache) 2,005 (32%) Cloud Storage (S3/Google Cloud Storage/Azure Storage/Minio) 1,891 (30%) Open Source NoSQL DB (MongoDB/Cassandra) 1,606 (26%) Authentication and federation (SSO/LDAP/OAuth) 1,546 (25%) Distributed Key-Value store (etcd/consul) 657 (11%) Proprietary Relational DB (Oracle/DB2/MSSQL/Sybase) 459  (7%) Distributed Lock Service (zookeeper) 1,367 (22%) No response

20162017If it were not for the following reasons I would use Go more:3,077 (31,14,4%)I work on an existing project written in another lang2,152 (14,16,5%)My project / team / TL prefers another language1,218 (10,5,4%)Go lacks critical features1,100 (6,7,4%)Go lacks critical libraries1,056 (6,6,4%)Go isn't appropriate for what I'm working on643 (4,4,3%)Not enough education or support resources for Go311 (2,2,1%)Go lacks critical performance790 (5,4,3%)Other1,309 (21%)No responseIf it were not for the following reasons I would use Go more:1,485 (24,14,4%)I work on an existing project written in another lang1,160 (16,12,4%)My project / team / TL prefers another language841 (11,8,5%)Go isn’t an appropriate fit for what I’m working on596 (6,6,4%)Go lacks critical libraries412 (6,3,2%)Go lacks critical features319 (3,3,3%)Not enough education or support resources for Go121 (1,1,0.8%)Go lacks critical performance374 (4,3,3%)Other1,042 (29%)No response

Development and deployment

We asked programmers which operating systems they develop Go on; the ratios of their responses remain consistent with last year. 64% of respondents say they use Linux, 49% use MacOS, and 18% use Windows, with multiple choices allowed.

Continuing its explosive growth, VSCode is now the most popular editor among Gophers. IntelliJ/GoLand also saw significant increase in usage. These largely came at the expense of Atom and Submlime Text which saw relative usage drops. This question had a 6% higher response rate from last year.

Survey respondents demonstrated significantly higher satisfaction with Go support in their editors over 2016 with the ratio of satisfied to dissatisfied doubling (9:1 → 18:1). Thank you to everyone who worked on Go editor support for all your hard work.

Go deployment is roughly evenly split between privately managed servers and hosted cloud servers. For Go applications, Google Cloud services saw significant increase over 2016. For Non-Go applications, AWS Lambda saw the largest increase in use.

I primarily develop Go on: (multiple choice) 3,973 (64%) Linux 3,048 (49%) MacOS 1,151 (18%) Windows 112  (2%) Other 328  (5%) No response

My preferred code editor 2,449 (27, 13%) VSCode 2,288 (22, 14%) Vim 1,628 (19, 7%) IntelliJ/GoLand 912 (7, 8%) Sublime Text 791 (6, 7%) Atom 490 (6, 2%) Emacs 274 (2, 2%) Visual Studio 154 (1, 1%) LiteIDE 88 (0.5, 0.9%) Eclipse 67 (0.6, 0.4%) Acme 256 (3, 2%) Other 382 (6.1%) No response

How satisfied are you with Go support in your preferred editor: (very dissatisfied, dissatisfied, somewhat dissatisfied, neither satisfied or unsatisfied, somewhat satisfied, satisfied, very satisfied) 5,730 (1, 0.9, 3, 3, 16, 38, 29%) (18:1) [24:1]

My team deploys Go programs to: (multiple choice) 2,664 (43%) Self/Company Owned Servers 1,689 (27%) AWS EC2 799 (13%) None 732 (12%) AWS Container 631 (10%) Digital Ocean 596 (10%) Google Compute Engine 485  (8%) Google Container Engine (GKE) 328  (5%) Google App Engine 262  (4%) AWS Lambda 255  (4%) Heroku 255  (4%) Microsoft Azure 183  (3%) Linode 61  (1%) Azure Container Service 51  (1%) Google Cloud Functions 13  (0%) Azure Functions 601 (10%) Other 652 (10%) No response

My team deploys Non-Go programs to: (multiple choice) 2,865 (46%) Self/Company Owned Servers 2,076 (33%) AWS EC2 806 (13%) AWS Container 644 (10%) AWS Lambda 528  (8%) Google Compute Engine 527  (8%) Digital Ocean 442  (7%) None 402  (6%) Microsoft Azure 340  (5%) Heroku 327  (5%) Google Container Engine (GKE) 188  (3%) Google App Engine 159  (3%) Linode 95  (2%) Google Cloud Functions 85  (1%) Azure Container Service 50  (1%) Azure Functions 524  (8%) Other 825 (13%) No response

20162017My preferred code editor2,449 (27,13%)VSCode2,288 (22,14%)Vim1,628 (19,7%)IntelliJ/GoLand912 (7,8%)Sublime Text791 (6,7%)Atom490 (6,2%)Emacs274 (2,2%)Visual Studio154 (1,1%)LiteIDE88 (0.5,0.9%)Eclipse67 (0.6,0.4%)Acme256 (3,2%)Other382 (6.1%)No responseMy preferred code editor1,359 (25,13%)Vim814 (14,9%)VSCode676 (10,9%)Atom687 (13,6%)IntelliJ655 (10,8%)Sublime Text305 (6,2%)Emacs137 (2,2%)Visual Studio153 (3,2%)LiteIDE99 (1,2%)Eclipse37 (0.5,0.5%)Acme238 (4,3%)Other425 (12%)No response

20162017My team deploys Go programs to: (multiple choice)1,489 (41%)Self/Company Owned Servers928 (26%)AWS EC2503 (14%)None412 (11%)Digital Ocean292  (8%)AWS Container221  (6%)Google Compute Engine188  (5%)Google App Engine161  (4%)Google Container Engine (GKE)121  (3%)Heroku114  (3%)Microsoft Azure104  (3%)Linode94  (3%)AWS Lambda301  (8%)Other639 (18%)No responseMy team deploys Go programs to: (multiple choice)2,664 (43%)Self/Company Owned Servers1,689 (27%)AWS EC2799 (13%)None732 (12%)AWS Container631 (10%)Digital Ocean596 (10%)Google Compute Engine485  (8%)Google Container Engine (GKE)328  (5%)Google App Engine262  (4%)AWS Lambda255  (4%)Heroku255  (4%)Microsoft Azure183  (3%)Linode61  (1%)Azure Container Service51  (1%)Google Cloud Functions13  (0%)Azure Functions601 (10%)Other652 (10%)No response

20162017My team deploys Non-Go programs to: (multiple choice)1,714 (48%)Self/Company Owned Servers1,122 (31%)AWS EC2360 (10%)Digital Ocean343 (10%)AWS Container249  (7%)None233  (6%)AWS Lambda210  (6%)Microsoft Azure186  (5%)Google Compute Engine185  (5%)Heroku115  (3%)Google Container Engine (GKE)100  (3%)Linode94  (3%)Google App Engine297  (8%)Other660 (18%)No responseMy team deploys Non-Go programs to: (multiple choice)2,865 (46%)Self/Company Owned Servers2,076 (33%)AWS EC2806 (13%)AWS Container644 (10%)AWS Lambda528  (8%)Google Compute Engine527  (8%)Digital Ocean442  (7%)None402  (6%)Microsoft Azure340  (5%)Heroku327  (5%)Google Container Engine (GKE)188  (3%)Google App Engine159  (3%)Linode95  (2%)Google Cloud Functions85  (1%)Azure Container Service50  (1%)Azure Functions524  (8%)Other825 (13%)No response

Working Effectively

We asked how strongly people agreed or disagreed with various statements about Go. All questions are repeated from last year with the addition of one new question which we introduced to add further clarifaction around how users are able to both find and use Go libraries.

All responses either indicated a small improvement or are comparable to 2016.

As in 2016, the most commonly requested missing library for Go is one for writing GUIs though the demand is not as pronounced as last year. No other missing library registered a significant number of responses.

The primary sources for finding answers to Go questions are the Go web site, Stack Overflow, and reading source code directly. Stack Overflow showed a small increase from usage over last year.

The primary sources for Go news are still the Go blog, Reddit’s /r/golang and Twitter; like last year, there may be some bias here since these are also how the survey was announced.

To what extent do you agree or disagree with the following statements: (strongly disagree, disagree, somewhat disagree, neither agree nor disagree, somewhat agree, agree, strongly agree) 5,555 (1, 2, 4, 7, 27, 34, 13%) I have a good understanding of Go best practices (9.5:1) [11:1] 5,549 (0.4, 0.9, 3, 4, 17, 42, 23%) I am able to quickly find answers to my questions (21:1) [31:1] 5,528 (0.4, 0.4, 1, 2, 6, 32, 47%) Go's performance meets my needs (48:1) [80:1] 4,614 (1, 2, 4, 12, 15, 26, 13%) Go's support for language interoperability meets my needs (6.8:1) [8.8:1] 5,478 (0.8, 2, 5, 6, 24, 36, 13%) I am able to quickly find libraries that I need (8.9:1) [12:1] 5,443 (0.9, 2, 5, 7, 23, 37, 12%) The Go libraries I use have the stability and features I need (9.1:1) [12:1] 5,521 (0.8, 2, 4, 5, 17, 37, 22%) Go language, library, and tool documentation meet my needs (11:1) [16:1]

To what extent do you agree or disagree with the following statements: (strongly disagree, disagree, somewhat disagree, neither agree nor disagree, somewhat agree, agree, strongly agree) 5,446 (0.8, 2, 6, 6, 21, 37, 14%) I am able to effectively diagnose bugs in my Go programs (8.7:1) [12:1] 4,968 (0.7, 2, 6, 13, 22, 27, 9%) I am able to effectively diagnose performance issues in Go programs (6.7:1) [8.7:1] 5,319 (0.7, 2, 3, 6, 16, 35, 24%) I am able to effectively use Go’s concurrency features (goroutines, channels, select) (14:1) [21:1] 5,096 (2, 5, 8, 15, 24, 21, 7%) I am able to effectively debug uses of Go’s concurrency features (goroutines, channels, select) (3.6:1) [3.9:1]

Which Go libraries do you need that aren’t available today? 306 (4.9%) gui 221 (3.5%) library 185 (3.0%) libraries 90 (1.4%) native 83 (1.3%) good 60 (1.0%) ui 59 (0.9%) machine learning 54 (0.9%) framework 48 (0.8%) gui library 48 (0.8%) orm 48 (0.8%) processing 47 (0.8%) desktop 44 (0.7%) web 41 (0.7%) cross-platform 39 (0.6%) client 39 (0.6%) platform 37 (0.6%) standard 35 (0.6%) audio 34 (0.5%) image 34 (0.5%) mobile 33 (0.5%) sql 32 (0.5%) soap 31 (0.5%) pdf 30 (0.5%) api 30 (0.5%) package 4,578 (73.5%) No response

Rank the following in terms of where you get Go answers from: 4,337 (28, 20, 13, 6, 2%) Stack Overflow 3,791 (29, 17, 9, 4, 1%) 3,362 (13, 17, 14, 8, 2%) Reading source code (e.g., standard library, open-source packages) 2,428 (4, 11, 13, 8, 3%) GitHub 1,408 (5, 6, 6, 5, 2%) Coworkers 1,071 (2, 4, 5, 4, 2%) golang-nuts mailing list ( 895 (1, 2, 4, 4, 3%) Reddit (r/golang) 569 (1, 2, 2, 2, 2%) Gopher Slack ( 432 (0.9, 1, 2, 2, 2%) Friends 283 (0.5, 0.7, 0.9, 1, 1%) Twitter 214 (0.2, 0.8, 0.8, 1, 0.6%) Go Forum ( 186 (0.5, 0.7, 0.7, 0.6, 0.5%) IRC 386 (2, 1, 1, 0.9, 0.7%) Other 844 (14%) No response

Rank the following in terms of where you get Go news from: 2,809 (16, 14, 9, 4, 2%) 1,838 (15, 7, 4, 3, 1%) Twitter 1,703 (12, 7, 4, 2, 1%) Reddit (r/golang) 1,617 (13, 7, 3, 2, 0.7%) 1,578 (9, 8, 5, 3, 1%) Hacker News 1,051 (2, 5, 5, 3, 2%) Community Blogs 859 (2, 4, 4, 2, 2%) GitHub 798 (4, 4, 3, 1, 0.6%) Coworkers 704 (1, 3, 3, 2, 1%) Just For Func 516 (2, 2, 2, 1, 0.7%) golang-nuts mailing list ( 428 (1, 2, 2, 1, 0.6%) Go Time podcast 393 (2, 2, 1, 1, 0.4%) 333 (1, 1, 1, 1, 0.7%) Gopher Slack ( 287 (1, 1, 1, 0.7, 0.4%) golang-announce ( 120 (0.5, 0.5, 0.4, 0.2, 0.3%) Facebook 86 (0.1, 0.4, 0.4, 0.2, 0.2%) Go Forum ( 205 (1, 1, 0.7, 0.3, 0.1%) Other 1,040 (17%) No response

I have attended: (multiple choice) 2,497 (40%) None 1,618 (26%) A Go meetup 947 (15%) A Go themed conference (GopherCon, GothamGo, etc) 506  (8%) A Go remote meetup / online event 363  (6%) Go training 228  (4%) A technical conference for it's Go content 65  (1%) A Women Who Go event 64  (1%) A GoBridge event 58  (1%) Other 1,440 (23%) No response

The Go Project

59% of respondents expressed interest in contributing in some way to the Go community and projects, up from 55% last year. Respondents also indicated that they felt much more welcome to contribute than in 2016. Unfortunately, respondents indicated only a very tiny improvement in understanding how to contribute. We will be actively working with the community and its leaders to make this a more accessible process.

Respondents showed an increase in agreement that they are confident in the leadership of the Go project (9:1 → 11:1). They also showed a small increase in agreement that the project leadership understands their needs (2.6:1 → 2.8:1) and in agreement that they feel comfortable approaching project leadership with questions and feedback (2.2:1 → 2.4:1). While improvements were made, this continues to be an area of focus for the project and its leadership going forward. We will continue to work to improve our understanding of user needs and approachability.

We tried some new ways to engage with users in 2017 and while progress was made, we are still working on making these solutions scalable for our growing community.

I contribute to open source projects written in Go: (single choice) 382 (6.1%) As part of my daily routine 463 (7.4%) Weekly 603 (9.7%) Monthly 2,180 (35.0%) Infrequently 1,792 (28.8%) Never 806 (12.9%) No response

I have or am interested in contributing in the following ways to the Go community and projects: (multiple choice) 1,785 (29%) Standard library 1,331 (21%) Tools (go guru, go vet, go doc, etc) 1,129 (18%) Documentation 1,115 (18%) Tutorials 967 (16%) Community support via Stack Overflow, Slack, mailing list, etc 863 (14%) Being a technical mentor 829 (13%) Community involvement (workgroups, meetup attendance) 727 (12%) Toolchain (compiler, linker, etc) 514  (8%) Go Project maintenance (issue triage) 474  (8%) Event planning (meetup, conference, etc) 433  (7%) Language translation 337  (5%) General UX & Design contributions 309  (5%) website (code, UX, IA, content, etc) 148  (2%) Other 2,553 (41%) No response

To what extent do you agree or disagree with the following statements: (strongly disagree, disagree, somewhat disagree, neither agree nor disagree, somewhat agree, agree, strongly agree) 4,091 (1, 3, 4, 19, 12, 18, 8%) I feel welcome to contribute to Go (compiler, standard library, documentation, website) (4.3:1) [5.0:1] 4,083 (3, 8, 10, 17, 11, 11, 5%) The process of contributing to the Go project is clear to me (1.3:1) [1.3:1] 3,657 (2, 3, 5, 23, 10, 13, 4%) The Go project leadership understands my needs (2.8:1) [2.8:1] 3,860 (2, 5, 6, 20, 10, 14, 6%) I feel comfortable approaching the Go project leadership with questions and feedback (2.4:1) [2.7:1] 4,351 (1, 2, 2, 12, 10, 26, 18%) I am confident in the leadership of Go (11:1) [13:1]


At the end of the survey, we asked some demographic questions.

The country distribution of responses is largely similar to last year with minor fluctuations. Like last year, the distribution of countries is similar to the visits to, though some Asian countries remain under-represented in the survey.

Perhaps the most significant improvement over 2016 came from the question which asked to what degree do respondents agreed with the statement, "I feel welcome in the Go community". Last year the agreement to disagreement ratio was 15:1. In 2017 this ratio nearly doubled to 25:1.

An important part of a community is making everyone feel welcome, especially people from under-represented demographics. We asked an optional question about identification across a few underrepresented groups. We had a 4% increase in response rate over last year. The percentage of each underrepresented group increased over 2016, some quite significantly.

Like last year, we took the results of the statement “I feel welcome in the Go community” and broke them down by responses to the various underrepresented categories. Like the whole, most of the respondents who identified as underrepresented also felt significantly more welcome in the Go community than in 2016. Respondents who identified as a woman showed the most significant improvement with an increase of over 400% in the ratio of agree:disagree to this statement (3:1 → 13:1). People who identified as ethnically or racially underrepresented had an increase of over 250% (7:1 → 18:1). Like last year, those who identified as not underrepresented still had a much higher percentage of agreement to this statement than those identifying from underrepresented groups.

We are encouraged by this progress and hope that the momentum continues.

The final question on the survey was just for fun: what’s your favorite Go keyword? Perhaps unsurprisingly, the most popular response was go, followed by defer, func, interface, and select, unchanged from last year.

Did you take last year's survey (single choice) 1,569 (25%) Yes 2,892 (46%) No 952 (15%) I don't remember 813 (13%) No response

To what extent do you agree or disagree with the following statement: (strongly disagree, disagree, somewhat disagree, neither agree nor disagree, somewhat agree, agree, strongly agree) 4,970 (0.5, 0.8, 1, 10, 10, 34, 22%) I feel welcome in the Go community (25:1) [33:1]

List of Countries (multiple choice) 1,561 (25%) United States of America 436  (7%) Germany 343  (6%) United Kingdom 211  (3%) Canada 200  (3%) France 174  (3%) Russia 130  (2%) Australia 113  (2%) India 110  (2%) Sweden 103  (2%) China 99  (2%) Netherlands 95  (2%) Spain 94  (2%) Brazil 89  (1%) Japan 84  (1%) Poland 62  (1%) Ukraine 58  (1%) Italy 57  (1%) Switzerland 48  (1%) Taiwan 42  (1%) Israel 873 (14%) Other 1,244 (20%) No response

We want the Go community to be inclusive; we want to see how we're doing and how to improve. Plea... (multiple choice) 2,591 (42%) I do not identify as part of an underrepresented group 790 (13%) I prefer not to answer 197  (3%) I identify as LGBTQIA 191  (3%) I identify as ethnically or racially underrepresented 164  (3%) I identify as neurodiverse or as having a disability 156  (3%) I identify with an underrepresented group not listed (please specify) 101  (2%) I identify as a woman 81  (1%) I identify as part of an underrepresented group, but I prefer not to specify 2,085 (33%) No response

Just for fun: What is your favorite Go keyword? (multiple choice) 1,627 (26%) go 856 (14%) defer 539  (9%) func 384  (6%) select 375  (6%) interface 242  (4%) range 222  (4%) chan 215  (3%) struct 114  (2%) fallthrough 96  (2%) goto 90  (1%) switch 89  (1%) type 82  (1%) for 71  (1%) map 48  (1%) import 39  (1%) if 33  (1%) package 32  (1%) return 27  (0%) var 24  (0%) continue 22  (0%) const 15  (0%) break 10  (0%) case 5  (0%) else 969 (16%) No response

Is there anything else you would like to share with us? 130 (2.1%) great 119 (1.9%) generics 104 (1.7%) love 104 (1.7%) thank you 99 (1.6%) thanks 87 (1.4%) community 58 (0.9%) programming 56 (0.9%) simple 52 (0.8%) awesome 51 (0.8%) i love 48 (0.8%) people 44 (0.7%) team 40 (0.6%) golang 38 (0.6%) keep up the good work 38 (0.6%) time 37 (0.6%) hard 37 (0.6%) languages 36 (0.6%) job 35 (0.6%) features 35 (0.6%) great work 30 (0.5%) 3 30 (0.5%) amazing 30 (0.5%) c 30 (0.5%) google 5,167 (83.0%) No response

Finally, on behalf of the entire Go project, we are grateful for everyone who has contributed to our project, whether by being a part of our great community, by taking this survey or by taking an interest in Go.

By Steve Francia

Go 1.10 is released

16 February 2018

Happy Friday, happy weekend! Today the Go team is happy to announce the release of Go 1.10. You can get it from the download page.

See the Go 1.10 release notes for all the details.

The most exciting part of this release for many people will probably be that the go tool now does automatic caching of build & test results. Of course, one of the hundreds of smaller changes may be your favorite.

To celebrate the release, Go User Groups around the world are holding release parties. See if there's one in your area, or feel free to organize one!

Thanks to everyone who contributed to this release and everyone who helped test the Go 1.10 betas and release candidates to ensure a perfect, bug-free final release. However, if you do notice any bugs or unexpected changes not noted in the release notes, be sure to file a bug.

Enjoy the weekend, and enjoy the new release!

P.S. Many of this year's Go conferences are accepting talk proposals this month. We always love to see new speakers and encourage you to think about proposing a talk. For more information, see

By Brad Fitzpatrick

See the index for more articles.