The Go Blog

Go Developer Survey 2023 H2 Results

Todd Kulesza
5 December 2023

Background

In August 2023, the Go team at Google conducted our bi-annual survey of Go
developers. We recruited participants via a public post on the Go blog and a
randomized prompt in VS Code, resulting in 4,005 responses. We primarily
focused survey questions around a few topics: general sentiment and feedback
about developing with Go, technology stacks used alongside Go, how developers
start new Go projects, recent experiences with toolchain error messages, and
understanding developer interest around ML/AI.

Thank you to everyone who participated in this survey! This report shares what
we learned from your feedback.

tl;dr

1. Go developers said they are more interested in AI/ML tooling that
   improves the quality, reliability, and performance of code they write,
   rather than writing code for them. An always-awake, never-busy expert
   “reviewer” might be one of the more helpful forms of AI developer
   assistance.
2. The top requests for improving toolchain warnings and errors were to make
   the messages more comprehensible and actionable; this sentiment was
   shared by developers of all experience levels, but was particularly strong
   among newer Go developers.
3. Our experiment with project templates (gonew) appears to solve critical
   problems for Go developers (especially developers new to Go) and does so in
   a way that matches their existing workflows for starting a new project.
   Based on these findings, we believe gonew can substantially reduce
   onboarding barriers for new Go developers and ease adoption of Go in
   organizations.
4. Three out of every four respondents work on Go software that also uses
   cloud services; this is evidence that developers see Go as a language for
   modern, cloud-based development.
5. Developer sentiment towards Go remains extremely positive, with 90% of
   survey respondents saying they felt satisfied while working with Go during
   the prior year.

Contents

• Developer sentiment
• Developer environments
• Tech stacks
• How developers start new Go projects
• Developer goals for error handling
• Understanding ML/AI use cases
• Toolchain error messages
• Microservices
• Module authorship and maintenance
• Demographics
• Firmographics
• Methodology
• Closing

Developer sentiment

Go developers continue to report high levels of satisfaction with the Go
ecosystem. A large majority of respondents said they felt satisfied while
working with Go over the past year (90% satisfied, 6% dissatisfied), and a
majority (52%) went further and said they were “very satisfied”, the highest
rating. Longtime readers have likely noticed that this number doesn’t change
much from year to year. This is expected for a large, stable project like Go;
we view this metric as a lagging
indicator
that can help confirm widespread issues in the Go ecosystem, but isn’t where
we expect to first learn about potential problems.

We typically find that the longer someone has worked with Go, the more likely
they are to report being satisfied with it. This trend continued in 2023;
among respondents with less than one year of Go experience, 82% reported
satisfaction with the Go development experience, compared to the 94% of Go
developers with five or more years of experience. There are likely a mix of
factors contributing to this, such as some respondents developing an
appreciation for Go’s design choices over time, or deciding Go isn’t a good
fit for their work and so not returning to this survey in following years
(i.e., survivorship bias).
Still, this data helps us quantify the current getting started experience for
Go developers, and it seems clear we could do more to help emerging Gophers
find their footing and enjoy early successes developing with Go.

The key takeaway is that a large majority of people who chose to work with Go
during the past year were happy with their experience. Further, the number of
people working with Go continues to increase; we see evidence of this from
external research like Stack Overflow’s Developer
Survey
(which found 14% of professional developers worked with Go during the past
year, a roughly 15% year-over-year increase), as well as analytics for
go.dev (which show an 8% rise in visitors year-over-year).
Combining this growth with a high satisfaction score is evidence that Go
continues to appeal to developers, and suggests that many developers who
choose to learn the language feel good about their decision long afterwards.
In their own words:

“After 30+ years of development in C, C++, Java, and now seven years of
programming in Go, it is still the most productive language by far. It’s not
perfect (no language is), but it has the best balance of productivity,
complexity, and performance.” — Professional Go
developer w/ 5 – 9 years of experience

“This is currently the best language I know, and I’ve tried many. The
tooling is awesome, compile times are great, and I can be really productive.
I’m glad I have Go as a tool, and I don’t need to use TypeScript
server-side. Thanks.” — Open source Go
developer w/ 3 – 4 years of experience

Developer environments

As in prior years, the majority of survey respondents told us they work with
Go on Linux (63%) and macOS (58%) systems. Small variations in these numbers
from year to year are most likely dependent upon who finds and responds to
this survey (particularly on the Go blog), as we don’t see consistent
year-over-year trends in the random sample coming from VS Code.

We do continue to see that newer members of the Go community are more likely
to be working with Windows than more experienced Go developers. We interpret
this as a signal that Windows-based development is important for onboarding
new developers to the Go ecosystem, and is a topic our team hopes to focus on
more in 2024.

Respondents continue to be heavily focused on Linux deployments. Given the
prevalence of Go for cloud development and containerized workloads, this is
not surprising but is still an important confirmation. We found few meaningful
differences based on factors such as organization size or experience level;
indeed, while novice Go developers appear more likely to develop on Windows,
92% still deploy to Linux systems. Perhaps the most interesting finding from
this breakdown is that more experienced Go developers said they deploy to a
wider variety of systems (most notably WebAssembly and IoT), though it’s
unclear if this is because such deployments are challenging for newer Go
developers or the result of experienced Go developers using Go in a broader
range of contexts. We also observed that both IoT and WebAssembly have
steadily increased in recent years, with each rising from 3% in 2021 to 6% and
5% in 2023, respectively.

The computing architecture landscape has changed over the past few years, and
we see that reflected in the current architectures Go developers say they work
with. While x86-compatible systems still account for the majority of
development (89%), ARM64 is also now used by a majority of respondents (56%).
This adoption appears to be partly driven by Apple Silicon; macOS developers
are now more likely to say they develop for ARM64 than for x86-based
architectures (76% vs. 71%). However, Apple hardware isn’t the only factor
driving ARM64 adoption: among respondents who don’t develop on macOS at all,
29% still say they develop for ARM64.

The most common code editors among Go Developer Survey respondents continue to
be VS Code (44%) and
GoLand (31%). Both of these proportions
ticked down slightly from 2023 H1 (46% and 33%, respectively), but remain
within this survey’s margin of error. Among the “Other” category,
Helix accounted for the majority of responses.
Similar to the results for operating systems above, we don’t believe this
represents a meaningful shift in code editor usage, but rather shows some of
the variability we expect to see in a community survey such as this. In
particular, we exclude the randomly sampled respondents from VS Code for this
question, as we know that group is heavily biased towards VS Code. However,
that has the side effect of making these results more susceptible to variation
each year.

We also looked at respondents’ level of satisfaction with Go based on the
editor they prefer using. After controlling for length of experience, we found
no differences: we don’t believe people enjoy working with Go more or less
based on which code editor they use. That doesn’t necessarily mean all Go
editors are equal, but may reflect that people find the editor that is best
for their own needs. This would suggest the Go ecosystem has a healthy
diversity of different editors geared towards different use cases and
developer preferences.

Tech stacks

To better understand the web of software and services that Go developers
interact with, we asked several questions about tech stacks. We’re sharing
these results with the community to show which tools and platforms are in
common use today, but we believe everyone should consider their own needs and
use cases when selecting a tech stack. More plainly: we neither intend for
readers to use this data to select components of their tech stack because they
are popular, nor to avoid components because they are not commonly used.

First, we can say with confidence that Go is a language for modern cloud-based
development. Indeed, 75% of respondents work on Go software that integrates
with cloud services. For nearly half of respondents, this involved AWS (48%),
and almost one-third used GCP (29%) for their Go development and deployments.
For both AWS and GCP, usage is equally balanced among large enterprises and
smaller organizations. Microsoft Azure is the only cloud provider that is
significantly more likely to be used in large organizations (companies with >
1,000 employees) than smaller shops; other providers show no meaningful
differences in usage based on the size of the organization.

Databases are extremely common components of software systems, and we found
that 91% of respondents said the Go services they work on use at least one.
Most frequently this was PostgreSQL (59%), but with double digits of
respondents reporting use of six additional databases, it’s safe to say there
are not just a couple of standard DBs for Go developers to consider. We again
see differences based on organization size, with respondents from smaller
organizations more likely to report using PostgreSQL and Redis, while
developers from large organizations are somewhat more likely to use a database
specific to their cloud provider.

Another common component respondents reported using were caches or key-value
stores; 68% of respondents said they work on Go software incorporating at
least one of these. Redis was clearly the most common (57%), followed at a
distance by etcd (10%) and memcached (7%).

Similar to databases, survey respondents told us they use a range of different
observability systems. Prometheus and Grafana were the most commonly cited
(both at 43%), but Open Telemetry, Datadog, and Sentry were all in double
digits.

Lest anyone wonder “Have we JSON’d all the things?”… yes, yes we have.
Nearly every respondent (96%!) said their Go software uses the JSON data
format; that’s about as close to universal as you’ll see with self-reported
data. YAML, CSV, and protocol buffers are also all used by roughly half of
respondents, and double-digit proportions work with TOML and XML as well.

For authentication and authorization services, we found most respondents are
building upon the foundations provided by standards such as
JWT and OAuth2. This
also appears to be an area where an organization’s cloud provider’s solution
is about as likely to be used as most turn-key alternatives.

Finally, we have a bit of a grab bag of other services that don’t neatly fit
into the above categories. We found that nearly half of respondents work with
gRPC in their Go software (47%). For infrastructure-as-code needs, Terraform
was the tool of choice for about ¼ of respondents. Other fairly common
technologies used alongside Go included Apache Kafka, ElasticSearch, GraphQL,
and RabbitMQ.

We also looked at which technologies tended to be used together. While nothing
clearly analogous to the classic LAMP
stack emerged from this
analysis, we did identify some interesting patterns:

• All or nothing: Every category (except data formats) showed a strong
  correlation where if a respondent answered “None” to one category, they
  likely answered “None” for all of the others. We interpret this as evidence
  that a minority of use cases require none of these tech stack components,
  but once the use case requires any one of them, it likely requires (or is at
  least simplified by) more than just one.
• A bias towards cross-platform technologies: Provider-specific solutions
  (i.e., services that are unique to a single cloud platform) were not
  commonly adopted. However, if respondents used one provider-specific
  solution (e.g., for metrics), they were substantially more likely to also
  say they used cloud-specific solutions in order areas (e.g., databases,
  authentication, caching, etc.).
• Multicloud: The three biggest cloud platforms were most likely to be
  involved in multicloud setups. For example, if an organization is using any
  non-AWS cloud provider, they’re probably also using AWS. This pattern was
  clearest for Amazon Web Services, but was also apparent (to a lesser extent)
  for Google Cloud Platform and Microsoft Azure.

How developers start new Go projects

As part of our experimentation with project
templates, we wanted to understand how Go
developers get started with new projects today. Respondents told us their
biggest challenges were choosing an appropriate way to structure their project
(54%) and learning how to write idiomatic Go (47%). As two respondents phrased
it:

“Finding an appropriate structure and the right abstraction levels for a new
project can be quite tedious; looking at high-profile community and
enterprise projects for inspiration can be quite confusing as everyone
structures their project differently” —
Professional Go developer w/ 5 – 9 years of Go experience

“It would be great if [Go had a] toolchain to create [a project’s] basic
structure for web or CLI like `go init <project name>`” — Professional Go developer w/ 3 – 4 years of
experience

Newer Go developers were even more likely to encounter these challenges: the
proportions increased to 59% and 53% for respondents with less than two years
of experience with Go, respectively. These are both areas we hope to improve
via our gonew prototype: templates can provide new Go developers with
well-tested project structures and design patterns, with initial
implementations written in idiomatic Go. These survey results have helped our
team to keep the purpose of gonew focused on tasks the Go community most
struggle with.

A majority of respondents told us they either use templates or copy+paste code
from existing projects when starting a new Go project (58%). Among respondents
with less than five years of Go experience, this proportion increased to
nearly ⅔ (63%). This was an important confirmation that the template-based
approach in gonew seems to meet developers where they already are, aligning
a common, informal approach with go command-style tooling. This is further
supported by the common feature requests for project templates: a majority of
respondents requested 1) a pre-configured directory structure to organize
their project and 2) sample code for common tasks in the project domain. These
results are well-aligned with the challenges developers said they faced in the
previous section. The responses to this question also help tease apart the
difference between project structure and design patterns, with nearly twice as
many respondents saying they want Go project templates to provide the former
than the latter.

A majority of respondents told us the ability to make changes to a template
and have those changes propagate to projects based on that template was of
at least moderate importance. Anecdotally, we haven’t spoken with any
developers who currently have this functionality with home-grown template
approaches, but it suggests this is an interesting avenue for future
development.

Developer goals for error handling

A perennial topic of discussion among Go developers is potential improvements
to error handling. As one respondent summarized:

“Error handling adds too much boilerplate (I know, you probably heard this
before)” — Open source Go developer w/ 1 – 2
years of experience

But, we also hear from numerous developers that they appreciate Go’s approach
to error handling:

“Go error handling is simple and effective. As I have backends in Java and
C# and exploring Rust and Zig now, I am always pleased to go back to write
Go code. And one of the reasons is, believe it or not, error handling. It is
really simple, plain and effective. Please leave it that way.” — Open source Go developer w/ 5 – 9 years of
experience

Rather than ask about specific modifications to error handling in Go, we
wanted to better understand developers’ higher-level goals and whether Go’s
current approach has proven useful and usable. We found that a majority of
respondents appreciate Go’s approach to error handling (55%) and say it helps
them know when to check for errors (50%). Both of these outcomes were stronger
for respondents with more Go experience, suggesting that either developers
grow to appreciate Go’s approach to error handling over time, or that this is
one factor leading developers to eventually leave the Go ecosystem (or at
least stop responding to Go-related surveys). Many survey respondents also
felt that Go requires a lot of tedious, boilerplate code to check for errors
(43%); this remained true regardless of how much prior Go experience
respondents had. Interestingly, when respondents said they appreciate Go’s
error handling, they were unlikely to say it also results in lots of
boilerplate code—our team had a hypothesis that Go developers can both
appreciate the language’s approach to error handling and feel it’s too
verbose, but only 14% of respondents agreed with both statements.

Specific issues that respondents cited include challenges knowing which error
types to check for (28%), wanting to easily show a stack trace along with the
error message (28%), and the ease with which errors can be entirely ignored
(19%). About ⅓ of respondents were also interested in adopting concepts from
other languages, such as Rust’s ? operator (31%).

The Go team has no plans to add exceptions to the language, but since this is
anecdotally a common request, we included it as a response choice. Only 1 in
10 respondents said they wished they could use exceptions in Go, and this was
inversely related to experience—more veteran Go developers were less likely
to be interested in exceptions than respondents newer to the Go community.

Understanding ML/AI use cases

The Go team is considering how the unfolding landscape of new ML/AI
technologies may impact software development in two distinct veins: 1) how
might ML/AI tooling help engineers write better software, and 2) how might Go
help engineers bring ML/AI support to their applications and services? Below,
we delve into each of these areas.

Helping engineers write better software

There’s little denying we’re in a hype cycle around the possibilities for
AI/ML.
We wanted to take a step back to focus on the broader challenges developers
face and where they think AI might prove useful in their regular work. The
answers were a bit surprising, especially given the industry’s current focus
on coding assistants.

First, we see a few AI use cases that about half of respondents thought could
be helpful: generating tests (49%), suggesting best practices in-situ (47%),
and catching likely mistakes early in the development process (46%). A
unifying theme of these top use cases is that each could help improve the
quality and reliability of code an engineer is writing. A fourth use case
(help writing documentation) garnered interest from about ⅓ of respondents.
The remaining cases comprise a long tail of potentially fruitful ideas, but
these are of significantly less general interest than the top four.

When we look at developers’ duration of experience with Go, we find that
novice respondents are interested in help resolving compiler errors and
explaining what a piece of Go code does more than veteran Go developers. These
might be areas where AI could help improve the getting started experience for
new Gophers; for example, an AI assistant could help explain in natural
language what an undocumented block of code does, or suggest common solutions
to specific error messages. Conversely, we see no differences between
experience levels for topics like “catch common mistakes”—both novice and
veteran Go developers say they would appreciate tooling to help with this.

One can squint at this data and see three broad trends:

1. Respondents voiced interest in getting feedback from “expert reviewers” in
   real-time, not just during review time.
2. Generally, respondents appeared most interested in tooling that saves them
   from potentially less-enjoyable tasks (e.g., writing tests or documenting
   code).
3. Wholesale writing or translating of code was of fairly low interest,
   especially to developers with more than a year or two of experience.

Taken together, it appears that today, developers are less excited by the
prospect of machines doing the fun (e.g., creative, enjoyable, appropriately
challenging) parts of software development, but do see value in another set of
“eyes” reviewing their code and potentially handling dull or repetitive tasks
for them. As one respondent phrased it:

“I’m specifically interested in using AI/ML to improve my productivity with
Go. Having a system that is trained in Go best practices, can catch
anti-patterns, bugs, generate tests, with a low rate of hallucination, would
be killer.” — Professional Go developer w/ 5 –
9 years of experience

This survey, however, is just one data point in a quickly-evolving research
field, so it’s best to keep these results in context.

Bringing AI features to applications and services

In addition to looking at how Go developers might benefit from AI/ML-powered
tooling, we explored their plans for building AI-powered applications and
services (or supporting infrastructure) with Go. We found that we’re still
early in the adoption
curve: most
respondents have not yet tried to use Go in these areas, though every topic
saw some level of interest from roughly half of respondents. For example, a
majority of respondents reported interest in integrating the Go services they
work on with LLMs (49%), but only 13% have already done so or are currently
evaluating this use case. At the time of this survey, responses gently suggest
that developers may be most interested in using Go to call LLMs directly,
build the data pipelines needed to power ML/AI systems, and for creating API
endpoints other services can call to interact with ML/AI models. As one
example, this respondent described the benefits they hoped to gain by using Go
in their data pipelines:

“I want to integrate the ETL [extract, transform, and load] part using Go,
to keep a consistent, robust, reliable codebase.” — Professional Go developer w/ 3 – 4 years of
experience

Toolchain error messages

Many developers can relate to the frustrating experience of seeing an error
message, thinking they know what it means and how to resolve it, but after
hours of fruitless debugging realize it meant something else entirely. One
respondent explained their frustration as follows:

“So often the printed complaints wind up having nothing to do with the
problem, but it can take an hour before I discover that that’s the case. The
error messages are unnervingly terse, and don’t seem to go out of their way
to guess as to what the user might be trying to do or [explain what they’re]
doing wrong.” — Professional Go developer w/ 10+
years of experience

We believe the warnings and errors emitted by developer tooling should be
brief, understandable, and actionable: the human reading them should be able
to accurately understand what went wrong and what they can do to resolve the
issue. This is an admittedly high bar to strive for, and with this survey we
took some measurements to understand how developers perceive Go’s current
warning and error messages.

When thinking about the most recent Go error message they worked through,
respondents told us there was much room for improvement. Only a small majority
understood what the problem was from the error message alone (54%), and even
fewer knew what to do next to resolve the issue (41%). It appears a relatively
small amount of additional information could meaningfully increase these
proportions, as ¼ of respondents said they mostly knew how to fix the problem,
but needed to see an example first. Further, with 11% of respondents saying
they couldn’t make sense of the error message, we now have a baseline for
current understandability of the Go toolchain’s error messages.

Improvements to Go’s toolchain error messages would especially benefit
less-experienced Gophers. Respondents with up to two years of experience were
less likely than veteran Gophers to say they understood the problem (47% vs.
61%) or knew how to fix it (29% vs. 52%), and were twice as likely to need to
search online to fix the issue (21% vs. 9%) or even make sense of what the
error meant (15% vs. 7%).

We hope to focus on improving toolchain error messages during 2024. These
survey results suggest this is an area of frustration for developers of all
experience levels, and will particularly help newer developers get started
with Go.

To understand how these messages might be improved, we asked survey
respondents an open-ended question: “If you could make a wish and improve one
thing about error messages in the Go toolchain, what would you change?”. The
responses largely align with our hypothesis that good error messages are both
understandable and actionable. The most common response was some form of “Help
me understand what led to this error” (36%), 21% of respondents explicitly
asked for guidance to fix the problem, and 14% of respondents called out
languages such as Rust or Elm as exemplars which strive to do both of these
things. In the words of one respondent:

“For compilation errors, Elm or Rust-style output pinpointing exact issue in
the source code. Errors should include suggestions to fix them where
possible… I think a general policy of ‘optimize error output to be read by
humans’ with ‘provide suggestions where possible’ would be very welcome
here.” — Professional Go developer w/ 5 – 9
years of experience

Understandably, there is a fuzzy conceptual boundary between toolchain error
messages and runtime error messages. For example, one of the top requests
involved improved stack traces or other approaches to assist debugging runtime
crashes (22%). Similarly, a surprising theme in 4% of the feedback was about
challenges with getting help from the go command itself. These are great
examples of the Go community helping us identify related pain points that
weren’t otherwise on our radar. We started this investigation focused on
improving compile-time errors, but one of the core areas Go developers would
like to see improved actually relates to run-time errors, while another was
about the go command’s help system.

“When an error is thrown, the call stack can be huge and includes a bunch of
files I don’t care about. I just want to know where the problem is in MY
code, not the library I’m using, or how the panic was handled.” — Professional Go developer w/ 1 – 2 years of
experience

“Getting help via `go help run` dumps a wall of text, with links to
further readings to find the available command-line flags. Or the fact that
it understands `go run –help` but instead of showing the help, it says
‘please run go help run instead’. Just show me list of flags in `go run
–help`.” — Professional Go developer w/ 3 –
4 years of experience

Microservices

We commonly hear that developers find Go to be a great fit for microservices,
but we have never tried to quantify how many Go developers have adopted this
type of service architecture, understand how those services communicate with
one another, or the challenges developers encounter when working on them. This
year we added a few questions to better understand this space.

A plurality of respondents said they work mostly on microservices (43%), with
another ¼ saying they work on a mix of both microservices and monoliths. Only
about ⅕ of respondents work mostly on monolithic Go applications. This is one
of the few areas where we see differences based on the size of organization
respondents work at—large organizations seem more likely to have adopted a
microservice architecture than smaller companies. Respondents from large
organizations (>1,000 employees) were most likely to say they work on
microservices (55%), with only 11% of these respondents working primarily on
monoliths.

We see some bifurcation in the number of microservices comprising Go
platforms. One group is composed of a handful (2 to 5) of services (40%),
while the other consists of larger collections, with a minimum of 10 component
services (37%). The number of microservices involved does not appear to be
correlated with organization size.

A large majority of respondents use some form of direct response request
(e.g., RPC, HTTP, etc.) for microservice communication (72%). A smaller
proportion use message queues (14%) or a pub/sub approach (9%); again, we see
no differences here based on organization size.

A majority of respondents build microservices in a polyglot of languages, with
only about ¼ exclusively using Go. Python is the most common companion
language (33%), alongside Node.js (28%) and Java (26%). We again see
differences based on organization size, with larger organizations more likely
to be integrating Python (43%) and Java (36%) microservices, while smaller
organizations are a bit more likely to only use Go (30%). Other languages
appeared to be used equally based on organization size.

Overall, respondents told us testing and debugging were their biggest
challenge when writing microservice-based applications, followed by
operational complexity. Many other challenges occupy the long tail on this
graph, though “portability” stands out as a non-issue for most respondents. We
interpret this to mean that such services aren’t intended to be portable
(beyond basic containerization); for example, if an organization’s
microservices are initially powered by PostgreSQL databases, developers aren’t
concerned with potentially porting this to an Oracle database in the near
future.

Module authorship and maintenance

Go has a vibrant ecosystem of community-driven modules, and we want to
understand the motivations and challenges faced by developers who maintain
these modules. We found that about ⅕ of respondents maintain (or used to
maintain) an open-source Go module. This was a surprisingly high proportion,
and may be biased due to how we share this survey: module maintainers may be
more likely to closely follow the Go blog (where this survey is announced)
than other Go developers.

Module maintainers appear to be largely self-motivated—they report working
on modules that they need for personal (58%) or work (56%) projects, that they
do so because they enjoy working on these modules (63%) and being part of the
public Go community (44%), and that they learn useful skills from their module
maintainership (44%). More external motivations, such as receiving recognition
(15%), career advancement (36%), or cash money (20%) are towards the bottom of
the list.

Given the forms of intrinsic
motivation identified above, it
follows that a key challenge for module maintainers is finding time to devote
to their module (41%). While this might not seem like an actionable finding in
itself (we can’t give Go developers an extra hour or two each day, right?),
it’s a helpful lens through which to view module tooling and
development—these tasks are most likely occurring while the developer is
already pressed for time, and perhaps it’s been weeks or months since they
last had an opportunity to work on it, so things aren’t fresh in their memory.
Thus, aspects like understandable and actionable error messages can be
particularly helpful: rather than require someone to once again search for
specific go command syntax, perhaps the error output could provide the
solution they need right in their terminal.

Demographics

Most survey respondents reported using Go for their primary job (78%), and a
majority (59%) said they use it for personal or open-source projects. In fact,
it’s common for respondents to use Go for both work and personal/OSS
projects, with 43% of respondents saying they use Go in each of these
situations.

The majority of respondents have been working with Go for under five years
(68%). As we’ve seen in prior
years,
people who found this survey via VS Code tended to be less experienced than
people who found the survey via other channels.

When we break down where people use Go by their experience level, two findings
stand out. First, a majority of respondents from all experience levels said
they’re using Go professionally; indeed, for people with over two years of
experience, the vast majority use Go at work (85% – 91%). A similar trend
exists for open-source development. The second finding is that developers with
less Go experience are more likely to be using Go to expand their skill set
(38%) or to evaluate it for use at work (13%) than more experienced Go
developers. We interpret this to mean that many Gophers initially view Go as
part of “upskilling” or expanding their understanding of software development,
but that within a year or two, they look to Go as more of a tool for doing
than learning.

The most common use cases for Go continue to be API/RPC services (74%) and
command line tools (62%). People tell us Go is a great choice for these types
of software for several reasons, including its built-in HTTP server and
concurrency primitives, ease of cross-compilation, and single-binary
deployments.

The intended audience for much of this tooling is in business settings (62%),
with 17% of respondents reporting that they develop primarily for more
consumer-oriented applications. This isn’t surprising given the low use of Go
for consumer-focused applications such as desktop, mobile, or gaming, vs. its
very high use for backend services, CLI tooling, and cloud development, but it
is a useful confirmation of how heavily Go is used in B2B settings.

We also looked for differences based on respondents’ level of experience with
Go and organization size. More experienced Go developers reported building a
wider variety of different things in Go; this trend was consistent across
every category of app or service. We did not find any notable differences in
what respondents are building based on their organization size.

Respondents were about equally likely to say this was the first time they’ve
responded to the Go Developer Survey vs. saying they had taken this survey
before. There is a meaningful difference between people who learned about this
survey via the Go blog, where 61% reported taking this survey previously, vs.
people who learned about this survey via a notification in VS Code, where only
31% said they’ve previously taken this survey. We don’t expect people to
perfectly recall every survey they’ve responded to on the internet, but this
gives us some confidence that we’re hearing from a balanced mix of new and
repeat respondents with each survey. Further, this tells us our combination of
social media posts and random in-editor sampling are both necessary for
hearing from a diverse set of Go developers.

Firmographics

Respondents to this survey reported working at a mix of different
organizations, from thousand-person-plus enterprises (27%), to midsize
businesses (25%) and smaller organizations with < 100 employees (44%). About
half of respondents work in the technology industry (50%), a large increase
over the next most-common industry—financial services—at 13%.

This is statistically unchanged from the past few Go Developer Surveys—we
continue to hear from people in different countries and in organizations of
different sizes and industries at consistent rates year after year.

Methodology

Most survey respondents “self-selected” to take this survey, meaning they
found it on the Go blog or other social Go channels. A potential problem with
this approach is that people who don’t follow these channels are less likely
to learn about the survey, and might respond differently than people who do
closely follow them. About 40% 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 mid-July – mid-August 2023 had a 10% of
receiving this random prompt). This randomly sampled group helps us generalize
these findings to the larger community of Go developers.

How to read these results

Throughout this report 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 the reader 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 the responses. Many open-ended questions
elicited a wide variety of responses; to keep the chart sizes reasonable, we
condensed them to a maximum of the top 10 themes, with additional themes all
grouped under “Other”. The percentage labels shown in charts are rounded to
the nearest integer (e.g., 1.4% and 0.8% will both be displayed as 1%), but
the length of each bar and row ordering are based on the unrounded values.

To help readers understand the weight of evidence underlying each finding, we
included 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]”.

We include select quotes from respondents to help clarify many of our
findings. These quotes include the length of times the respondent has used Go.
If the respondent said they use Go at work, we refer to them as a
“professional Go developer”; if they don’t use Go at work but do use Go for
open-source development, we refer to them as an “open-source Go developer”.

Closing

The final question on our survey always asks respondents whether there’s
anything else they’d like to share with us about Go. The most common piece of
feedback people provide is “thanks!”, and this year was no different (33%). In
terms of requested language improvements, we see a three-way statistical tie
between improved expressivity (12%), improved error handling (12%), and
improved type safety or reliability (9%). Respondents had a variety of ideas
for improving expressivity, with the general trend of this feedback being
“Here’s a specific thing I write frequently, and I wish it were easier to
express this in Go”. The issues with error handling continue to be complaints
about the verbosity of this code today, while feedback about type safety most
commonly touched on sum types.
This type of high-level feedback is extremely useful when the Go team tries to
plan focus areas for the coming year, as it tells us general directions in
which the community is hoping to steer the ecosystem.

“I know about Go’s attitude towards simplicity and I appreciate it. I just
wish there [were] slightly more features. For me it would be better error
handling (not exceptions though), and maybe some common creature comforts
like map/reduce/filter and ternary operators. Anything not too obscure
that’ll save me some ‘if’ statements.” —
Professional Go developer w/ 1 – 2 years of experience

“Please keep Go in line with the long term values Go established so long ago
— language and library stability. […] It is an environment I can
rely on to not break my code after 2 or 3 years. For that, thank you very
much.” — Professional Go developer w/ 10+ years
of experience

That’s all for this bi-annual iteration of the Go Developer Survey. Thanks to
everyone who shared their feedback about Go—we have immense gratitude for
taking your time to help shape Go’s future, and we hope you see some of your
own feedback reflected in this report. 🩵

— Todd (on behalf of the Go team at Google)