The Go survey separates module adoption from module satisfaction
The 2019 survey finds broad module adoption alongside persistent tooling problems. Its revised methodology also changes how several apparent year-to-year trends should be read.
Adopting a development tool does not mean that using it has become straightforward. The 2019 Go developer survey results, published today, make that distinction visible for modules. Among respondents, 89% reported adopting modules. Working with modules also remained one of the areas where importance exceeded satisfaction. A nearly completed transition can still leave substantial work in the tools people use every day.
The survey collected 10,975 responses. Its most useful contribution is a more careful account of what those responses measure. Changes to denominators and answer ordering affect several comparisons with previous years. Reading the numbers without those qualifications would produce a much cleaner story than the research supports.
I like Go for the ease of entering unfamiliar code and understanding its decisions. Dependency management and editor behavior influence that experience directly. A readable language loses some of its practical benefit when the tools disagree about which package a program imports.
Correcting what a percentage means
Previous surveys calculated percentages using everyone who started the survey as the denominator for each question. Some participants never reached the later questions. The report says that as many as 40% stopped before the final page. Counting those absent responses in later denominators depressed the reported percentages for reasons unrelated to the question itself.
This report uses the number of people who answered each question. It also recalculates the older results shown alongside the new ones. An apparent revision to historical satisfaction is therefore a measurement correction. It does not establish that developers retrospectively changed their opinion of Go.
For example, 86% of respondents answering the relevant question agreed that Go worked well for their teams. The report finds that this measure has remained stable since 2016 after normalization. Previously published percentages in the fifties and sixties included participants who never encountered the question. The corrected comparison changes the interpretation of the history.
Answer order introduces a separate problem. Some earlier lists were alphabetical, and choices near the beginning attracted disproportionately many responses. The new survey randomizes lists without an inherent order. That improves the baseline but makes some comparisons across the change invalid. The application-category question is one affected example.
Manual analysis also replaces machine-assisted categorization for free-text responses. Two researchers categorized the new answers, allowing finer distinctions. That does not make their categories directly comparable with the earlier automated analysis. These methodological changes constrain different parts of the report and should not be collapsed into a general claim that every historical comparison is invalid.
Modules are common while the tools catch up
The module adoption figure is particularly relevant after the Go 1.14 release announcement declared module support ready for production use. The survey describes developers making the transition together. Broad adoption makes remaining problems more widely encountered, even when the underlying dependency model has become the normal choice.
Package management and modules accounted for 12% of responses about the biggest challenges of using Go. That question differs from the adoption question. A respondent can use modules and still name them as a major source of difficulty. Treating the two answers as contradictory would confuse current behavior with satisfaction.
Editor integration provides another view of the transition. General improvements or better language-server support led the requests for editing-environment improvements at 19%. The report describes gopls as replacing about 80 existing tools and still being in beta. That consolidation creates a substantial integration task because the editor needs a consistent account of packages and source information.
Some respondents specifically mentioned restarting VS Code while using gopls. The report places the survey fieldwork in late November and early December 2019 and says many improvements have landed since then. The results describe that collection period. They should not be presented as an exact measurement of the language server available today.
Generics figures have different populations
The survey also illustrates how a striking percentage can lose its meaning when its denominator disappears. Among respondents who said missing language capabilities prevented greater use of Go, 79% identified generics as a critical omission. That subgroup came from the 25% who reported a missing critical language capability. The 79% figure does not describe all respondents.
A different question, asked of everyone, found that the lack of generics appeared in 15% of answers about the biggest challenges. Both results can be correct because they ask different questions of different groups. One characterizes a specific adoption blocker. The other locates a concern among the broader set of reported difficulties.
I regard this distinction as essential to a useful language-design discussion. Strong demand within a constrained use case deserves explanation, while a population-wide claim requires population-wide evidence. Neither number by itself determines which design should enter the language.
Release support affects adoption beyond the compiler
The report finds that 75% of respondents evaluate the current release for production, with another 12% waiting one release cycle. Cloud-platform support therefore affects whether developers can use the release they want. Free-text answers identify delayed runtime support as a problem for some managed deployments.
That creates a dependency between Go release engineering and the services that host Go programs. A stable toolchain can exist while a particular deployment platform still prevents its use. The survey treats cloud services, debugging, and modules as areas with high importance and lower satisfaction. Those findings direct attention to the full development environment, including the systems that build, inspect, and run otherwise ordinary Go code.