title: Go Developer Survey 2023 Q1 Results date: 2023-05-11 by:
We’re excited to share with you the results of the 2023 January edition of the Go Developer Survey. Thank you to the 5,844 respondents who shared with us how they’re using Go, their biggest challenges in using Go, and their top priorities for future improvements. These results help the Go team focus our efforts on areas that matter most to the community, and we hope these insights also help inform others who contribute to and support the Go ecosystem.
Throughout this post, we use charts of survey responses to provide supporting evidence for our findings. All of these charts use a similar format. The title is the exact question that survey respondents saw. Unless otherwise noted, questions were multiple choice and participants could only select a single response choice; each chart’s subtitle will tell you if the question allowed multiple response choices or was an open-ended text box instead of a multiple choice question. For charts of open-ended text responses, a Go team member read and manually categorized all of the responses. Many open-ended questions elicited a wide variety of responses; to keep the chart sizes reasonable, we condensed them to the top 10-15 themes, with additional themes all grouped under “Other”. We also included a category for “None” where applicable.
To help readers understand the weight of evidence underlying each finding, we include error bars showing the 95% confidence interval for responses; narrower bars indicate increased confidence. Sometimes two or more responses have overlapping error bars, which means the relative order of those responses is not statistically meaningful (i.e., the responses are effectively tied). The lower right of each chart shows the number of people whose responses are included in the chart, in the form “n = [number of respondents]”.
Most survey respondents “self-selected” to take the survey by accessing it through a link on the Go blog, @golang on Twitter, or other social Go channels. People who don’t follow these channels might respond differently from people who do closely follow them. About a quarter of respondents were randomly sampled, meaning they responded to the survey after seeing a prompt for it in VS Code (everyone using the VS Code Go plugin between Jan 18 - Feb 8, 2023 had a 10% chance of receiving this random prompt). This randomly sampled group helps us generalize these findings to the larger community of Go developers. Most survey questions showed no meaningful difference between these groups, but in the few cases with important differences, readers will see charts that break down responses into “Random sample” and “Self-selected” groups.
Our respondent demographics did not change significantly from our last survey. Consistent with previous cycles, Go is primarily used in the tech industry, and about 80% of respondents said they program in Go at work. Overall, survey respondents tended to be satisfied with Go over the past year, with 92% saying they were somewhat or very satisfied.
Our respondents spend a lot of time programming in Go compared to other languages. About a third of respondents even maintain an open source Go module. We recognize that our survey audience is made up of those who successfully adopted Go, use Go often, and are mostly satisfied using Go. To identify potential gaps in meeting community needs, we look at different sub-groups of respondents to see how they might be using Go differently or have different priorities. For example, this year we looked at how responses differ between different sample sources (i.e., the Go Blog or through the VS Code plugin), different job roles, organization sizes, and levels of Go experience. The most interesting differences were between experience levels.
Previously, we used how much time (in months / years) respondents have used Go as a proxy to gain insight into how results vary between levels of experience. This year we experimented with a new segmentation question, “What is your level of experience with Go?”, to see if self-identification might be a more useful way of examining Go experience than lumping together various intervals of time. Since categorical terms like “novice” or “expert” might vary from person to person, we provided a description to help make these buckets more objective. The options were:
We found a moderate correlation (⍴ = .66) between how long respondents had been using Go and their self-identified experience level. This means that the experience level scale, although similar to the time scale, may give us some new insights into how respondents differ by experience. For instance, the proportion of time that a respondent spends writing in Go compared to how much time they spend writing in other languages is more strongly correlated with their self-identified experience level than with how long they’ve been using Go.
In analyses where we use this segmentation we typically exclude the Awareness category since they wouldn’t be considered to have the experience necessary to answer the question and only represented about 1% of respondents.
Our randomly sampled group had a higher proportion of novice respondents than the self-selected group, suggesting that there are more new Gophers out there that we don’t tend to hear from as often. Because they are sampled through the Go VS Code plugin, we might expect this group to be more likely to prefer using VS Code or to develop on Windows more than other experience levels. While this is true, novices are also more likely to develop on Windows than other experience levels, regardless of whether they responded through the VS Code plugin.
There could be a number of reasons why we don’t see higher proportions of Windows users at higher experience levels. For example, Windows users may be more likely to experience difficulties and stop using Go, or there could be wider trends in OS usage that have nothing to do with Go. In any case, we should include more Windows users in future research around getting started with Go to make sure we provide an inclusive onboarding experience.
According to how respondents use Go right now, more experienced Gophers tend to be using Go for more types of applications. For example, the average expert used Go in at least four areas while the average novice used Go in only two areas. That’s why there are large differences in the proportion of novices and experts using Go for each use case. The top two uses, API / RPC services and CLIs, however, are the top use cases across all experience levels.
We see more interesting trends for GUIs and Website / Web services (returning HTML). All experience levels used Go for Desktop / GUI apps at about the same rate. This gives us evidence the desire for GUIs isn’t just coming from new Gophers looking for a fun starter project, but from across the experience spectrum.
Websites / services returning HTML show a similar trend. One explanation could be that this is a common use case early in someone’s Go journey (since it is in the top 3 most common for novices), or that novices are more likely to be doing work on websites or web services returning HTML. Later in the survey, we asked respondents, “In which area (if any) are you not using Go, but would most like to?” Although many respondents (29%) said they already use Go everywhere they would like to, the top two areas for expanding usage were GUI / Desktop and AI / ML applications. This was consistent across groups at different organization sizes and job roles, but not experience levels. The number one area where novices would like to use Go more is for websites / web services returning HTML.
In an open text question, 12 out of 29 respondents who said they would like to use Go for websites / web services returning HTML said they were blocked because other languages had frameworks to better support this use case. It could be that more experienced Go developers don’t try or expect to use Go for this use case when other languages already have frameworks that meet those needs. As one respondent put it,
“It's usually easier to accomplish this in other languages such as PHP or Ruby. Partly due to the excellent frameworks that exist in those languages.”
Another contributing explanation for novices' interest in web development may be related to their usage of JavaScript / TypeScript. Novices spend more of their time writing in JavaScript / TypeScript than more experienced respondents. The higher interest in web could have something to do with what novice respondents currently work on in other languages or could indicate a general interest in web technologies. In the future we’d like to learn more about this use case and how we can help new Gophers get started using Go in areas most useful to them.
Every survey cycle we ask respondents what their biggest challenge is when using Go. Historically, lack of generics was the most commonly cited challenge—for example, it was the most common response in 2020, and mentioned by about 18% of respondents. Since the introduction of generics, error handling (12%) and learning / best practices / docs (11%) have emerged at the front of a long tail of issues rather than any single issue becoming more frequent.
Feedback on error handling often describes the problem as verbosity. On the surface, this could reflect that writing repetitive code is boring or annoying. More than just an annoyance of writing boilerplate, however, error handling may also impact respondents’ ability to debug.
One respondent succinctly illustrated this issue:
“Error handling creates clutter and easily masks problems if not done correctly (no stack traces)”
“Using Go effectively. Easy to learn, hard to master.”
We’ve heard that Go is easy to learn, and a previous survey showed that over 70% of respondents feel productive using Go within their first year, but learning Go best practices came up as one of the biggest challenges to using Go. Respondents this year told us that best practices around code structure and recommended tools and libraries aren’t well documented, creating challenges for beginners and teams to keep code consistent. Learning to write idiomatic Go can be especially challenging to those coming from other programming paradigms. Respondents who were more experienced with Go attested that when developers don’t follow best practices for writing idiomatic Go, it hurts the consistency and quality of shared projects.
Go module maintainers are critical members of the Go community, helping to grow and sustain the health of our package ecosystem. This year we plan to conduct research with module maintainers to identify opportunities to support stability and growth of the package ecosystem and help grow Go adoption within organizations. To inform this research, we introduced a question on the survey to get an idea of the current top challenges for open source maintainers.
The top challenges for maintainers are keeping dependencies up to date and difficulties around versioning, including avoiding, identifying, or knowing when to introduce breaking changes. These insights, along with the results of future research, will help inform strategies to support maintainers in keeping the Go ecosystem stable and secure.
This year we asked what respondents’ biggest challenge was when deploying Go code. Being “easy to deploy” is often cited as a reason for using Go, but we received conflicting feedback during a recent study that prompted us to explore potential issues when deploying Go code. In our open text responses, by far the most common theme was difficulty cross-compiling with cgo (16%), and support for WebAssembly or WASI was a distant second (7%).
This year we used a prioritization question we’ve used in previous surveys based on the buy-a-feature method of prioritization. Respondents were given 10 “gophercoins” and asked to distribute them to areas where they want to see improvements. Respondents were randomly assigned one of three possible questions, each containing seven items related to tooling, security, or compiler & runtime. This approach allowed us to ask about items relevant to each focus area without overburdening respondents with three sets of cognitively-demanding prioritization questions.
At the end of the exercise, we gave respondents an open text prompt to tell us about any area they thought should be the Go team’s top priority in the next year, regardless of which items they spent their coins on. For example, if a respondent was shown the security section, but they didn’t care all that much about security, they still had the opportunity to tell us that in the open text area.
We chose these items to test assumptions we held on the relative importance of security practices to the community. These were the seven items as described to participants:
The highest funded security feature was for web & SQL libraries to be secure by default to avoid introducing vulnerabilities in web server code, but the top four features all relate to avoiding the introduction of vulnerabilities. The desire for secure defaults is consistent with previous security research that showed developers want to “shift left” on security: development teams often don’t have time or resources to spend on addressing security issues, and thus value tooling that reduces the likelihood of introducing them in the first place. The second most common item was a security best practices guide, highlighting the high value of best practices documentation compared to new tools or features to the majority of respondents.
Items we included in this question were inspired by feedback from VS Code plugin users. We wanted to know which tooling and IDE improvements would be most helpful to a wider audience who may use other IDEs or editors.
The most funded editor feature was support for finding types that implement an interface and interfaces implemented by a type and refactoring tools. We also saw an interesting difference in how respondents spent their gophercoins according to preferred editor usage. Most notably, VS Code users spent more gophercoins on refactoring than GoLand users, suggesting that automatic code transformations are currently better supported in GoLand than in VS Code.
Our key question for this section was to determine whether respondents wanted better performance by default, better optimization tooling, or just a better understanding of how to write performant Go code.
By far the most funded item in this list was an optimization guide. This was consistent across organization size, job role, and experience level. We asked an additional question about whether respondents had resource costs concerns. Most respondents (55%) said they did not have any cost concerns, but those who had concerns about resource costs spent more gophercoins (on average, 2.0) on reducing compute costs and memory costs than those who did not. However, even those who were concerned about resource costs still spent about as much on the optimization guide (on average 1.9 gophercoins). This is a strong signal that providing guidance for Go developers to understand and optimize Go performance is currently more valuable than additional compiler and runtime performance improvements.
Thank you for joining us in reviewing the results of our first developer survey of 2023! Understanding developers’ experiences and challenges helps us prioritize how to best serve the Go community. Some takeaways we found particularly useful:
Thanks again to everyone who responded and contributed to this survey—we couldn't have done it without you. We hope to see you later this year for the next survey.