From 7d8d2df710bab2a2ac848c578298f4b6e2718fce Mon Sep 17 00:00:00 2001 From: Todd Kulesza Date: Fri, 1 Dec 2023 21:38:17 -0800 Subject: [PATCH] _content/blog: add 2023 H2 survey results Change-Id: Ia31e363ca6c7389bcf11a2709c0e9466033fc96c Reviewed-on: https://go-review.googlesource.com/c/website/+/545856 Reviewed-by: Todd Kulesza Run-TryBot: Todd Kulesza Auto-Submit: Todd Kulesza Commit-Queue: Todd Kulesza TryBot-Result: Gopher Robot Reviewed-by: Cameron Balahan --- _content/blog/survey2023-h2-results.md | 898 ++++++++++++++++++ _content/blog/survey2023h2/arch.svg | 106 +++ _content/blog/survey2023h2/auth.svg | 102 ++ _content/blog/survey2023h2/cache.svg | 102 ++ _content/blog/survey2023h2/cloud.svg | 131 +++ _content/blog/survey2023h2/csat.svg | 58 ++ _content/blog/survey2023h2/data.svg | 100 ++ _content/blog/survey2023h2/db.svg | 131 +++ .../blog/survey2023h2/editor_self_select.svg | 81 ++ _content/blog/survey2023h2/enduser.svg | 72 ++ _content/blog/survey2023h2/err_exp.svg | 96 ++ _content/blog/survey2023h2/err_exp_exp.svg | 172 ++++ _content/blog/survey2023h2/error_handling.svg | 108 +++ _content/blog/survey2023h2/go_exp.svg | 75 ++ _content/blog/survey2023h2/industry.svg | 118 +++ _content/blog/survey2023h2/location.svg | 171 ++++ _content/blog/survey2023h2/metrics.svg | 120 +++ _content/blog/survey2023h2/ml_adoption.svg | 121 +++ _content/blog/survey2023h2/ml_use_cases.svg | 130 +++ _content/blog/survey2023h2/mod_challenge.svg | 129 +++ _content/blog/survey2023h2/mod_maintainer.svg | 65 ++ _content/blog/survey2023h2/mod_motivation.svg | 110 +++ _content/blog/survey2023h2/new_approach.svg | 90 ++ _content/blog/survey2023h2/new_challenge.svg | 113 +++ _content/blog/survey2023h2/org_size.svg | 89 ++ _content/blog/survey2023h2/os_deploy.svg | 82 ++ _content/blog/survey2023h2/os_dev.svg | 76 ++ _content/blog/survey2023h2/os_dev_exp.svg | 132 +++ _content/blog/survey2023h2/other_tech.svg | 125 +++ .../blog/survey2023h2/return_respondent.svg | 74 ++ _content/blog/survey2023h2/service_arch.svg | 78 ++ .../blog/survey2023h2/service_challenge.svg | 108 +++ _content/blog/survey2023h2/service_comm.svg | 76 ++ _content/blog/survey2023h2/service_lang.svg | 113 +++ _content/blog/survey2023h2/service_num.svg | 69 ++ .../blog/survey2023h2/template_updates.svg | 66 ++ _content/blog/survey2023h2/templates.svg | 126 +++ .../blog/survey2023h2/text_anything_else.svg | 113 +++ _content/blog/survey2023h2/text_err_wish.svg | 128 +++ _content/blog/survey2023h2/what.svg | 128 +++ _content/blog/survey2023h2/where.svg | 77 ++ _content/blog/survey2023h2/where_exp.svg | 133 +++ 42 files changed, 5192 insertions(+) create mode 100644 _content/blog/survey2023-h2-results.md create mode 100644 _content/blog/survey2023h2/arch.svg create mode 100644 _content/blog/survey2023h2/auth.svg create mode 100644 _content/blog/survey2023h2/cache.svg create mode 100644 _content/blog/survey2023h2/cloud.svg create mode 100644 _content/blog/survey2023h2/csat.svg create mode 100644 _content/blog/survey2023h2/data.svg create mode 100644 _content/blog/survey2023h2/db.svg create mode 100644 _content/blog/survey2023h2/editor_self_select.svg create mode 100644 _content/blog/survey2023h2/enduser.svg create mode 100644 _content/blog/survey2023h2/err_exp.svg create mode 100644 _content/blog/survey2023h2/err_exp_exp.svg create mode 100644 _content/blog/survey2023h2/error_handling.svg create mode 100644 _content/blog/survey2023h2/go_exp.svg create mode 100644 _content/blog/survey2023h2/industry.svg create mode 100644 _content/blog/survey2023h2/location.svg create mode 100644 _content/blog/survey2023h2/metrics.svg create mode 100644 _content/blog/survey2023h2/ml_adoption.svg create mode 100644 _content/blog/survey2023h2/ml_use_cases.svg create mode 100644 _content/blog/survey2023h2/mod_challenge.svg create mode 100644 _content/blog/survey2023h2/mod_maintainer.svg create mode 100644 _content/blog/survey2023h2/mod_motivation.svg create mode 100644 _content/blog/survey2023h2/new_approach.svg create mode 100644 _content/blog/survey2023h2/new_challenge.svg create mode 100644 _content/blog/survey2023h2/org_size.svg create mode 100644 _content/blog/survey2023h2/os_deploy.svg create mode 100644 _content/blog/survey2023h2/os_dev.svg create mode 100644 _content/blog/survey2023h2/os_dev_exp.svg create mode 100644 _content/blog/survey2023h2/other_tech.svg create mode 100644 _content/blog/survey2023h2/return_respondent.svg create mode 100644 _content/blog/survey2023h2/service_arch.svg create mode 100644 _content/blog/survey2023h2/service_challenge.svg create mode 100644 _content/blog/survey2023h2/service_comm.svg create mode 100644 _content/blog/survey2023h2/service_lang.svg create mode 100644 _content/blog/survey2023h2/service_num.svg create mode 100644 _content/blog/survey2023h2/template_updates.svg create mode 100644 _content/blog/survey2023h2/templates.svg create mode 100644 _content/blog/survey2023h2/text_anything_else.svg create mode 100644 _content/blog/survey2023h2/text_err_wish.svg create mode 100644 _content/blog/survey2023h2/what.svg create mode 100644 _content/blog/survey2023h2/where.svg create mode 100644 _content/blog/survey2023h2/where_exp.svg diff --git a/_content/blog/survey2023-h2-results.md b/_content/blog/survey2023-h2-results.md new file mode 100644 index 0000000000..0ca4db9d17 --- /dev/null +++ b/_content/blog/survey2023-h2-results.md @@ -0,0 +1,898 @@ +--- +title: Go Developer Survey 2023 H2 Results +date: 2023-12-05 +by: +- Todd Kulesza +tags: +- survey +- community +- developer experience research +summary: What we learned from our 2023 H2 developer survey +--- + + + +## 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. +1. 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. +1. 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**. +1. 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**. +1. **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 {#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](https://en.wikipedia.org/wiki/Economic_indicator#Lagging_indicators) +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](https://en.wikipedia.org/wiki/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](https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof) +(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](https://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 + +Chart of developer satisfaction with Go + +## Developer environments {#devenv} + +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. + +Chart of operating systems respondents +use when developing Go software Chart of operating systems respondents +use when developing Go software, split by duration of experience + +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. + +Chart of platforms respondents +deploy Go software to + +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. + +Chart of architectures respondents use +with Go + +The most common code editors among Go Developer Survey respondents continue to +be [VS Code](https://code.visualstudio.com/) (44%) and +[GoLand](https://www.jetbrains.com/go/) (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](https://helix-editor.com/) 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. + +Chart of code editors +respondents prefer to use with Go + +## Tech stacks {#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. + +Chart of cloud platforms respondents +use with Go + +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. + +Chart of databases respondents use with +Go + +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%). + +Chart of caches respondents use with +Go + +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. + +Chart of metric systems respondents +use with Go + +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. + +Chart of data formats respondents use +with Go + +For authentication and authorization services, we found most respondents are +building upon the foundations provided by standards such as +[JWT](https://jwt.io/introduction) and [OAuth2](https://oauth.net/2/). 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. + +Chart of authentication systems +respondents use with Go + +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. + +Chart of authentication systems +respondents use with Go + +We also looked at which technologies tended to be used together. While nothing +clearly analogous to the classic [LAMP +stack](https://en.wikipedia.org/wiki/LAMP_(software_bundle)) 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 {#gonew} + +As part of our [experimentation with project +templates](https://go.dev/blog/gonew), 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 \\`" class="quote_source">--- 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. + +Chart of challenges respondents +faced when starting new Go projects + +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. + +Chart of approaches respondents +used when starting new Go projects + +Chart of functionality respondents +requested when starting new Go projects + +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. + +Chart of respondent interest +in updatable templates + +## Developer goals for error handling {#err_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." class="quote_source">--- 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. + +Chart of respondents' thoughts +about Go's error handling approach + +## Understanding ML/AI use cases {#mlai} + +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](https://www.gartner.com/en/articles/what-s-new-in-artificial-intelligence-from-the-2023-gartner-hype-cycle). +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. +1. Generally, respondents appeared most interested in tooling that saves them + from potentially less-enjoyable tasks (e.g., writing tests or documenting + code). +1. 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. + +Chart of respondents' interest +in AI/ML support for development tasks + +### 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](https://en.wikipedia.org/wiki/Technology_adoption_life_cycle): 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." class="quote_source">--- Professional Go developer w/ 3 -- 4 years of +> experience + +Chart of respondents' current use +of (and interest in) Go for AI/ML systems + +## Toolchain error messages {#err_msgs} + +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. + +Chart of error handling experiences + +Chart of error handling +experiences, split by duration of Go experience + +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." class="quote_source">--- 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 + +Chart of potential improvements +for Go's error messages + +## Microservices {#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. + +Chart of respondents' primary +service architecture + +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. + +Chart of the number of +microservices respondents' systems involve + +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. + +Chart of how microservices +communicate with one another + +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. + +Chart of other languages that Go +microservices interact with + +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. + +Chart of challenges +respondents face when writing microservice-based applications + +## Module authorship and maintenance {#modules} + +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. + +Chart of how many respondents +have served as a maintainer for a public Go module + +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. + +Chart of the motivations of +public module maintainers + +Given the forms of [intrinsic +motivation](https://en.wikipedia.org/wiki/Motivation#Intrinsic_and_extrinsic) 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. + +Chart of challenges respondents +face when maintaining public Go modules + +## Demographics {#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. + +Chart of situations in which +respondents recently used Go + +The majority of respondents have been working with Go for under five years +(68%). As we've seen in [prior +years](https://go.dev/blog/survey2023-q1-results#novice-respondents-are-more-likely-to-prefer-windows-than-more-experienced-respondents), +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. + +Chart of how long respondents have +been working with Go + +Chart of situations in which +respondents recently used Go, split by their level of Go experience + +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. + +Chart of the types of things respondents +are building with Go + +Chart of the audience using the +software respondents build + +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. + +Chart of how many +respondents said they have taken this survey before + +## Firmographics {#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. + +Chart of the different organization +sizes where respondents use Go + +Chart of the different industries +where respondents use Go + +Chart of countries or regions where +respondents are located + +## Methodology {#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](https://en.wikipedia.org/wiki/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 {#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](https://en.wikipedia.org/wiki/Tagged_union). +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 + +Chart of other topics +respondents shared with us + +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) \ No newline at end of file diff --git a/_content/blog/survey2023h2/arch.svg b/_content/blog/survey2023h2/arch.svg new file mode 100644 index 0000000000..aff4ed679f --- /dev/null +++ b/_content/blog/survey2023h2/arch.svg @@ -0,0 +1,106 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +89% +5% +56% +5% +0% +1% +1% +1% +0% +5% + + +Loong64 +S390x +PPC64 +MIPS +RISC-V +i386 +WebAssembly +ARM32 +ARM64 +x86-64 / AMD64 +0% +50% +100% +% of respondents +(select all that apply) +Which architectures do you use when working with Go? +n = 3,499 + + diff --git a/_content/blog/survey2023h2/auth.svg b/_content/blog/survey2023h2/auth.svg new file mode 100644 index 0000000000..93ed4c445e --- /dev/null +++ b/_content/blog/survey2023h2/auth.svg @@ -0,0 +1,102 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +13% +1% +10% +5% +51% +23% +44% +8% +6% + + +Other: +None +Authy +Firebase +Okta +A solution specific to my cloud +provider +Auth0 +OAuth2 +JWT +0% +50% +100% +% of respondents +(select all that apply) +Does the Go software you work on use any of the following systems for +authentication or identity management? +n = 3,230 + + diff --git a/_content/blog/survey2023h2/cache.svg b/_content/blog/survey2023h2/cache.svg new file mode 100644 index 0000000000..35789d9ec2 --- /dev/null +++ b/_content/blog/survey2023h2/cache.svg @@ -0,0 +1,102 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +3% +4% +10% +1% +7% +32% +6% +57% +2% + + +Other: +None +LevelDB +RocksDB +BadgerDB +A solution specific to my cloud +provider +Memcached +etcd +Redis +0% +50% +100% +% of respondents +(select all that apply) +Does the Go software you work on use any of the following caches or key-value +stores? +n = 3,109 + + diff --git a/_content/blog/survey2023h2/cloud.svg b/_content/blog/survey2023h2/cloud.svg new file mode 100644 index 0000000000..1cbed2051b --- /dev/null +++ b/_content/blog/survey2023h2/cloud.svg @@ -0,0 +1,131 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +5% +48% +14% +10% +3% +29% +2% +1% +3% +25% +3% +2% +7% +1% + + +Other: +None +IBM Cloud +Tencent Cloud +Oracle Cloud +Heroku +OpenStack +Linode +Fly.io +Aliyun / Alibaba Cloud +Digital Ocean +Microsoft Azure +Google Cloud Platform (GCP) +Amazon Web Services (AWS) +0% +50% +100% +% of respondents +(select all that apply) +Does the Go software you work on use any of the following cloud service +providers? +n = 3,346 + + diff --git a/_content/blog/survey2023h2/csat.svg b/_content/blog/survey2023h2/csat.svg new file mode 100644 index 0000000000..934c573914 --- /dev/null +++ b/_content/blog/survey2023h2/csat.svg @@ -0,0 +1,58 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + +6% +4% +90% + + +0% +50% +100% +% of respondents + + + +Satisfied +Neither satisfied nor dissatisfied +Dissatisfied +Overall, how satisfied or dissatisfied have you felt while using Go during the +past year? +n = 3,531 + + diff --git a/_content/blog/survey2023h2/data.svg b/_content/blog/survey2023h2/data.svg new file mode 100644 index 0000000000..2c38b5b40d --- /dev/null +++ b/_content/blog/survey2023h2/data.svg @@ -0,0 +1,100 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +45% +6% +96% +1% +4% +44% +17% +21% +54% + + +Other: +None +HCL +TOML +XML +Protocol buffers +CSV +YAML +JSON +0% +50% +100% +% of respondents +(select all that apply) +Does the Go software you work on use any of the following data formats? +n = 3,424 + + diff --git a/_content/blog/survey2023h2/db.svg b/_content/blog/survey2023h2/db.svg new file mode 100644 index 0000000000..d291c7706e --- /dev/null +++ b/_content/blog/survey2023h2/db.svg @@ -0,0 +1,131 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +4% +10% +4% +1% +12% +22% +5% +30% +9% +3% +8% +59% +38% +29% + + +Other: +None +CouchDB +Oracle +Cassandra +CockroachDB +Microsoft SQL Server +A solution specific to my cloud +provider +MariaDB +MongoDB +sqlite +MySQL +Redis +PostgreSQL +0% +50% +100% +% of respondents +(select all that apply) +Does the Go software you work on use any of the following databases? +n = 3,369 + + diff --git a/_content/blog/survey2023h2/editor_self_select.svg b/_content/blog/survey2023h2/editor_self_select.svg new file mode 100644 index 0000000000..f28e0a5bc4 --- /dev/null +++ b/_content/blog/survey2023h2/editor_self_select.svg @@ -0,0 +1,81 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +3% +31% +1% +16% +44% +4% + + +Other: +Sublime Text +Emacs +Vim / Neovim +GoLand +VS Code +0% +50% +100% +% of respondents +What is your preferred code editor for Go? +n = 2,172 + + diff --git a/_content/blog/survey2023h2/enduser.svg b/_content/blog/survey2023h2/enduser.svg new file mode 100644 index 0000000000..a7fe8e7d26 --- /dev/null +++ b/_content/blog/survey2023h2/enduser.svg @@ -0,0 +1,72 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +62% +17% +20% +2% + + +Neither (please specify) +Mostly as part of their personal or +family life / consumer use (B2C) +Both about equally +Mostly as part of their job / business +use (B2B) +0% +50% +100% +% of respondents +When would people be most likely to use the Go software you most recently +worked on? +n = 3,000 + + diff --git a/_content/blog/survey2023h2/err_exp.svg b/_content/blog/survey2023h2/err_exp.svg new file mode 100644 index 0000000000..283b07e723 --- /dev/null +++ b/_content/blog/survey2023h2/err_exp.svg @@ -0,0 +1,96 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +11% +25% +41% +15% +28% +5% +54% + + +The error message included more +information than I needed +I didn't understand what the error +message meant +I didn't know how to fix the problem +without searching online or asking +someone else +I mostly knew how to fix the problem +but needed to find an example or +specific syntax +I had seen it before +I knew how to fix the problem without +any assistance +I understood what the problem was +0% +50% +100% +% of respondents +(select all that apply) +Think of the most recent Go error message you can recall seeing. Which of the +following reflect your experience with that error message? +n = 2,989 + + diff --git a/_content/blog/survey2023h2/err_exp_exp.svg b/_content/blog/survey2023h2/err_exp_exp.svg new file mode 100644 index 0000000000..c541c726c9 --- /dev/null +++ b/_content/blog/survey2023h2/err_exp_exp.svg @@ -0,0 +1,172 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +7% +11% +15% +18% +25% +30% +52% +42% +29% +9% +13% +21% +33% +28% +22% +3% +6% +6% +61% +54% +47% + + +The error message included more +information than I needed +I didn't understand what the error +message meant +I didn't know how to fix the problem +without searching online or asking +someone else +I mostly knew how to fix the problem +but needed to find an example or +specific syntax +I had seen it before +I knew how to fix the problem without +any assistance +I understood what the problem was +0% +50% +100% +% of respondents + + + +0 – 2 years of Go experience +3 – 4 years +5+ years +(select all that apply) +Think of the most recent Go error message you can recall seeing. Which of the +following reflect your experience with that error message? +n = 2,989 + + diff --git a/_content/blog/survey2023h2/error_handling.svg b/_content/blog/survey2023h2/error_handling.svg new file mode 100644 index 0000000000..b441c0a768 --- /dev/null +++ b/_content/blog/survey2023h2/error_handling.svg @@ -0,0 +1,108 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +43% +19% +50% +10% +31% +55% +6% +28% +28% + + +Other: +I wish I could use an exception here +Errors in Go are too easy for +developers to ignore +I want to print a stack trace here +It's hard to know which error types to +check for +I wish functions could return a single +value containing either an error or a +valid result (similar to Rust's ? +operator) +Go needs a lot of boilerplate code to +check for errors +Go's explicit error handling helped me +know when to check for error values +I like Go's approach to error handling +0% +50% +100% +% of respondents +(select all that apply) +Think about the last time you wrote or read error handling code in Go. Did you +feel or think any of the following? +n = 3,198 + + diff --git a/_content/blog/survey2023h2/go_exp.svg b/_content/blog/survey2023h2/go_exp.svg new file mode 100644 index 0000000000..3d283aa1fd --- /dev/null +++ b/_content/blog/survey2023h2/go_exp.svg @@ -0,0 +1,75 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +18% +24% +26% +27% +5% + + +10+ years +5 – 9 years +3 – 4 years +1 – 2 years +Less than 1 year +0% +50% +100% +% of respondents +How long have you used Go? +n = 3,799 + + diff --git a/_content/blog/survey2023h2/industry.svg b/_content/blog/survey2023h2/industry.svg new file mode 100644 index 0000000000..0971acf6c7 --- /dev/null +++ b/_content/blog/survey2023h2/industry.svg @@ -0,0 +1,118 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +2% +2% +13% +4% +7% +1% +2% +6% +50% +5% +3% +5% + + +Other +Manufacturing +Energy +Public sector / nonprofit +Education +Transportation +Healthcare / life sciences +Telecommunications +Retail / consumer packaged goods +Media / gaming +Financial services +Technology +0% +50% +100% +% of respondents +Which of the following best describes the industry in which your organization +operates? +n = 2,468 + + diff --git a/_content/blog/survey2023h2/location.svg b/_content/blog/survey2023h2/location.svg new file mode 100644 index 0000000000..cf48bfa9d3 --- /dev/null +++ b/_content/blog/survey2023h2/location.svg @@ -0,0 +1,171 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +3% +3% +4% +5% +4% +9% +4% +2% +2% +2% +1% +2% +1% +2% +2% +2% +1% +1% +5% +22% +23% + + +Elsewhere +Norway +Switzerland +Ukraine +Portugal +Spain +Japan +Italy +Netherlands +Poland +Russia +Sweden +Australia +Brazil +India +France +Canada +China +United Kingdom +Germany +United States +0% +50% +100% +% of respondents +In which location do you live? +n = 2,922 + + diff --git a/_content/blog/survey2023h2/metrics.svg b/_content/blog/survey2023h2/metrics.svg new file mode 100644 index 0000000000..25d6bb61c2 --- /dev/null +++ b/_content/blog/survey2023h2/metrics.svg @@ -0,0 +1,120 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +7% +15% +43% +8% +5% +25% +24% +5% +43% +12% +5% +1% + + +Other: +None +Zipkin +Splunk +New Relic +A solution specific to my cloud +provider +Logstash +Sentry +Datadog +Open Telemetry +Grafana +Prometheus +0% +50% +100% +% of respondents +(select all that apply) +Does the Go software you work on use any of the following systems for +observability or metrics? +n = 3,237 + + diff --git a/_content/blog/survey2023h2/ml_adoption.svg b/_content/blog/survey2023h2/ml_adoption.svg new file mode 100644 index 0000000000..ff87502140 --- /dev/null +++ b/_content/blog/survey2023h2/ml_adoption.svg @@ -0,0 +1,121 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +50% +39% +7% +4% +54% +34% +7% +5% +57% +37% +4% +2% +49% +39% +9% +4% +55% +37% +5% +3% +53% +35% +7% +5% +55% +35% +6% +4% + + +Developing new ML/AI models in Go +Integrating Go services with non-LLM +ML/AI models +Other infrastructure for +testing/monitoring production ML/AI +systems +API endpoints for ML/AI models written +in other languages +Data pipelines for ML/AI systems +API endpoints for ML/AI models written +in Go +Integrating Go services with LLMs +0% +50% +100% +% of respondents + + + + +Using in production +Evaluating for production use +Interested but haven't tried yet +Not interested +At work, are you using or exploring the use of Go for any of the following? +n = 2,735 + + diff --git a/_content/blog/survey2023h2/ml_use_cases.svg b/_content/blog/survey2023h2/ml_use_cases.svg new file mode 100644 index 0000000000..235cb225ee --- /dev/null +++ b/_content/blog/survey2023h2/ml_use_cases.svg @@ -0,0 +1,130 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +47% +11% +46% +20% +15% +24% +36% +14% +18% +20% +22% +2% +49% + + +Other: +Help me brainstorm ideas +Help me create examples +Convert code from another programming +language to Go +Explain what a piece of Go code does +Help me resolve compiler errors or +warnings +Generate Go code from a natural +language description +None; I'm not interested in AI/ML +support when working with Go +Help me debug failures in my code +Help me write documentation +Catch common mistakes while I'm writing +code +Suggest better practices while I'm +writing code +Help me write tests +0% +50% +100% +% of respondents +(select up to 5) +How would you like to see AI/ML support Go developers? +n = 3,027 + + diff --git a/_content/blog/survey2023h2/mod_challenge.svg b/_content/blog/survey2023h2/mod_challenge.svg new file mode 100644 index 0000000000..b08d9d5802 --- /dev/null +++ b/_content/blog/survey2023h2/mod_challenge.svg @@ -0,0 +1,129 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +22% +16% +33% +14% +26% +5% +8% +10% +4% +12% +41% +9% +15% + + +Other: +Keeping up with new versions of Go +Encouraging users to upgrade to the +latest major version +Changing a module's import path / +transferring module ownership +None; I don't have any challenges +maintaining Go modules +Testing +Getting feedback on what to improve +Working with multiple modules in the +same repo +Keeping dependencies up-to-date +Avoiding unintentional breaking changes +Attracting a community of users and +contributors +Writing good documentation +Finding time to work on it +0% +50% +100% +% of respondents +(select up to 3) +What have been your biggest challenges when maintaining a Go module? +n = 780 + + diff --git a/_content/blog/survey2023h2/mod_maintainer.svg b/_content/blog/survey2023h2/mod_maintainer.svg new file mode 100644 index 0000000000..1b6a0080bf --- /dev/null +++ b/_content/blog/survey2023h2/mod_maintainer.svg @@ -0,0 +1,65 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +21% +6% +73% + + +I used to maintain an open-source Go +module, but stopped +I currently maintain an open-source Go +module +No +0% +50% +100% +% of respondents +Have you ever been the primary maintainer for a Go open-source module? +n = 3,055 + + diff --git a/_content/blog/survey2023h2/mod_motivation.svg b/_content/blog/survey2023h2/mod_motivation.svg new file mode 100644 index 0000000000..0226c4e8fa --- /dev/null +++ b/_content/blog/survey2023h2/mod_motivation.svg @@ -0,0 +1,110 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +36% +44% +15% +63% +44% +1% +20% +58% +35% +56% + + +Other: +Other developers recognize me due to my +work on this module +I'm paid to work on this module +Others benefit from this module +Maintaining this module helps me +demonstrate skills / advance in my +career +I learn from maintaining this module +I like being a part of the Go community +I use this module at work +I use this module for personal projects +It's fun to work on +0% +50% +100% +% of respondents +(select all that apply) +Think about the most recent module you maintained. What are (or were) your +motivations for maintaining this module? +n = 802 + + diff --git a/_content/blog/survey2023h2/new_approach.svg b/_content/blog/survey2023h2/new_approach.svg new file mode 100644 index 0000000000..c58e2dd85d --- /dev/null +++ b/_content/blog/survey2023h2/new_approach.svg @@ -0,0 +1,90 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +19% +6% +37% +33% +1% +3% + + +Other: +Someone else would create the new +project and then share it with me +I start by copying an existing, +fully-featured Go project and remove +unnecessary components +I start by copying a template or +minimal example that's similar to my +project +I start with an empty project and +copy/paste the basic structure from a +similar project +I start with an empty project and write +everything by hand +0% +50% +100% +% of respondents +If you were creating a new Go project at work, which of the following best +describes your approach to get started? +n = 3,255 + + diff --git a/_content/blog/survey2023h2/new_challenge.svg b/_content/blog/survey2023h2/new_challenge.svg new file mode 100644 index 0000000000..ca7b1883d0 --- /dev/null +++ b/_content/blog/survey2023h2/new_challenge.svg @@ -0,0 +1,113 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +4% +17% +10% +21% +18% +47% +20% +5% +22% +54% + + +Other: +Learning how to integrate with my cloud +provider's platform +I don't remember, it was a long time +ago +Dependency management +Learning how to use go.mod / Go modules +Finding or evaluating appropriate +libraries to build upon +Error handling +Mapping knowledge from other +programming languages to Go +Learning common Go idioms / best +practices +Identifying an appropriate project +structure / design pattern +0% +50% +100% +% of respondents +(select up to 3) +Think back to the first non-trivial Go project you created. What was most +challenging during the first few days of working on that project? +n = 3,252 + + diff --git a/_content/blog/survey2023h2/org_size.svg b/_content/blog/survey2023h2/org_size.svg new file mode 100644 index 0000000000..bb28311c76 --- /dev/null +++ b/_content/blog/survey2023h2/org_size.svg @@ -0,0 +1,89 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +8% +36% +25% +16% +11% +2% +3% + + +I'm not sure +I am not currently employed (e.g., +student, retired, etc.) +10,000 or more employees +1,000 – 9,999 employees +100 – 999 employees +2 – 99 employees +Just me (freelance, independent +contractor, etc.) +0% +50% +100% +% of respondents +About how many people work at your organization? +n = 3,069 + + diff --git a/_content/blog/survey2023h2/os_deploy.svg b/_content/blog/survey2023h2/os_deploy.svg new file mode 100644 index 0000000000..1572d54e28 --- /dev/null +++ b/_content/blog/survey2023h2/os_deploy.svg @@ -0,0 +1,82 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +6% +96% +18% +3% +5% +22% + + +Other: +WebAssembly (WASM) +Embedded devices / IoT +macOS +Windows +Linux +0% +50% +100% +% of respondents +(select all that apply) +Which systems do you deploy your Go software to? +n = 3,549 + + diff --git a/_content/blog/survey2023h2/os_dev.svg b/_content/blog/survey2023h2/os_dev.svg new file mode 100644 index 0000000000..512b67ae74 --- /dev/null +++ b/_content/blog/survey2023h2/os_dev.svg @@ -0,0 +1,76 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +63% +58% +1% +25% +16% + + +Other: +Windows Subsystem for Linux (WSL) +Windows +macOS +Linux +0% +50% +100% +% of respondents +(select all that apply) +Which operating systems do you use when developing with Go? +n = 3,574 + + diff --git a/_content/blog/survey2023h2/os_dev_exp.svg b/_content/blog/survey2023h2/os_dev_exp.svg new file mode 100644 index 0000000000..b4178e0bb4 --- /dev/null +++ b/_content/blog/survey2023h2/os_dev_exp.svg @@ -0,0 +1,132 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +73% +64% +55% +63% +60% +52% +2% +1% +1% +18% +23% +31% +14% +16% +18% + + +Other: +Windows Subsystem for Linux (WSL) +Windows +macOS +Linux +0% +50% +100% +% of respondents + + + +0 – 2 years of Go experience +3 – 4 years +5+ years +(select all that apply) +Which operating systems do you use when developing with Go? +n = 3,574 + + diff --git a/_content/blog/survey2023h2/other_tech.svg b/_content/blog/survey2023h2/other_tech.svg new file mode 100644 index 0000000000..324736b0fc --- /dev/null +++ b/_content/blog/survey2023h2/other_tech.svg @@ -0,0 +1,125 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9% +1% +21% +1% +7% +17% +47% +1% +22% +24% +1% +17% +26% + + +None of these +Chef +Fastly +Puppet +Apache Hadoop +Firebase +Ansible +RabbitMQ +GraphQL +ElasticSearch +Apache Kafka +Terraform +gRPC +0% +50% +100% +% of respondents +(select all that apply) +Does the Go software you work on use or integrate with any of the following +systems? +n = 3,194 + + diff --git a/_content/blog/survey2023h2/return_respondent.svg b/_content/blog/survey2023h2/return_respondent.svg new file mode 100644 index 0000000000..6dbc95b0a9 --- /dev/null +++ b/_content/blog/survey2023h2/return_respondent.svg @@ -0,0 +1,74 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +46% +44% +6% +3% + + +I'm not sure +Maybe, but I don't recall every survey +I've filled out on the internet +No, this is my first time taking the Go +Developer Survey +Yes, I've taken this survey at least +once before +0% +50% +100% +% of respondents +We run this Go Developer Survey every six months, most recently in January +2023. Do you recall whether you’ve taken one of these prior surveys, or is +this your first time filling out the Go Developer Survey? +n = 3,064 + + diff --git a/_content/blog/survey2023h2/service_arch.svg b/_content/blog/survey2023h2/service_arch.svg new file mode 100644 index 0000000000..92ca39df59 --- /dev/null +++ b/_content/blog/survey2023h2/service_arch.svg @@ -0,0 +1,78 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +43% +21% +28% +6% +2% + + +Other: +I don't work on either microservices or +monolithic applications +I mostly work on monolithic +applications +About an equal mix of both +I mostly work on microservices +0% +50% +100% +% of respondents +Do you consider the Go services you work on to be microservices, monoliths, or +something else? +n = 3,065 + + diff --git a/_content/blog/survey2023h2/service_challenge.svg b/_content/blog/survey2023h2/service_challenge.svg new file mode 100644 index 0000000000..bc1dab768a --- /dev/null +++ b/_content/blog/survey2023h2/service_challenge.svg @@ -0,0 +1,108 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +20% +27% +30% +38% +3% +21% +3% +26% +46% +26% + + +Other: +Portability +Service discovery and communication +Performance optimization / cost +reduction +Deployment and versioning +Security and authentication +Service coordination +Data management and consistency +Operational complexity +Testing and debugging +0% +50% +100% +% of respondents +(select up to 3) +Which things do you find the most challenging when writing microservice-based +applications? +n = 2,053 + + diff --git a/_content/blog/survey2023h2/service_comm.svg b/_content/blog/survey2023h2/service_comm.svg new file mode 100644 index 0000000000..06a9ca2bcc --- /dev/null +++ b/_content/blog/survey2023h2/service_comm.svg @@ -0,0 +1,76 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +72% +9% +2% +14% +3% + + +Other: +GraphQL +Pub/Sub +Message queues +Request response (e.g., RPC, HTTP, +REST) +0% +50% +100% +% of respondents +Which primary mechanism do you use to communicate between your microservices? +n = 2,144 + + diff --git a/_content/blog/survey2023h2/service_lang.svg b/_content/blog/survey2023h2/service_lang.svg new file mode 100644 index 0000000000..c365e94e1f --- /dev/null +++ b/_content/blog/survey2023h2/service_lang.svg @@ -0,0 +1,113 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +11% +9% +26% +26% +5% +28% +4% +10% +33% +6% +8% + + +Other: +Kotlin +Ruby +Rust +C# +PHP +C / C++ +Java +We only use Go +Node.js +Python +0% +50% +100% +% of respondents +(select all that apply) +At work, do you integrate your Go microservices with microservices written in +other languages? If so, which other languages do you use for microservices? +n = 2,083 + + diff --git a/_content/blog/survey2023h2/service_num.svg b/_content/blog/survey2023h2/service_num.svg new file mode 100644 index 0000000000..f4e331759f --- /dev/null +++ b/_content/blog/survey2023h2/service_num.svg @@ -0,0 +1,69 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +4% +40% +20% +37% + + +More than 10 +6 – 10 +2 – 5 +1 +0% +50% +100% +% of respondents +About how many microservices does the primary application you work on have? +n = 2,132 + + diff --git a/_content/blog/survey2023h2/template_updates.svg b/_content/blog/survey2023h2/template_updates.svg new file mode 100644 index 0000000000..f978117a1f --- /dev/null +++ b/_content/blog/survey2023h2/template_updates.svg @@ -0,0 +1,66 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +14% +15% +34% +25% +11% + + +0% +50% +100% +% of respondents + + + + + +Not at all important +Slightly important +Moderately important +Very important +Extremely important +When working with project templates, is it important to be able to update the +base template and pull those updates into projects built on top of it? +n = 3,027 + + diff --git a/_content/blog/survey2023h2/templates.svg b/_content/blog/survey2023h2/templates.svg new file mode 100644 index 0000000000..a6ecf8d602 --- /dev/null +++ b/_content/blog/survey2023h2/templates.svg @@ -0,0 +1,126 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +29% +51% +31% +28% +61% +29% +27% +0% +39% +2% +40% + + +None of the above +Other: +Instructions for how to use or +customize the template +Stubbed out design patterns appropriate +to my project type +Imports recommended modules for +specific types of projects (e.g., a +template for a microservice might +include a module to handle routing) +Something to help setup or configure +build pipelines +Ability to turn components of the +template on or off (e.g., turn off +logging, turn on HTTP routing) +Company-specific best practices and +boilerplate code +Testing infrastructure or examples +Example code for common tasks (e.g., +connecting to databases, user +authentication, logging configuration, +etc.) +A preferred directory structure laid +out for my .go files +0% +50% +100% +% of respondents +(select all that apply) +When starting a new Go project, what information or features do you want in +templates or examples? +n = 2,839 + + diff --git a/_content/blog/survey2023h2/text_anything_else.svg b/_content/blog/survey2023h2/text_anything_else.svg new file mode 100644 index 0000000000..f17fdb3067 --- /dev/null +++ b/_content/blog/survey2023h2/text_anything_else.svg @@ -0,0 +1,113 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +12% +6% +9% +5% +12% +6% +5% +2% +6% +33% +23% + + +Other +Frustrated by dependency management +Hitting limits of type parameters +Improve performance / memory management +Expand use cases +Appreciates simplicity +Improve docs / examples +Improve type safety / reliability +Improve error handling +Improve expressivity / developer +velocity +General praise / thanks +0% +50% +100% +% of respondents +(open-ended text response) +Is there anything else you would like to share with us about Go? +n = 401 + + diff --git a/_content/blog/survey2023h2/text_err_wish.svg b/_content/blog/survey2023h2/text_err_wish.svg new file mode 100644 index 0000000000..089c024f8c --- /dev/null +++ b/_content/blog/survey2023h2/text_err_wish.svg @@ -0,0 +1,128 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +3% +11% +22% +21% +13% +36% +5% +14% +2% +3% +4% +8% +13% + + +Other +Related to unused variables +Related to generics +Test-related topics +Improved go cmd help / docs +Related to nil pointers +Improved formatting / use color +Module or dependency related topics +Quickly see exactly what triggered +error +Be more like Rust or Elm +Guidance to fix the error / autofix +Improved stack traces / easier +debugging from runtime crashes +Improved explanations of causes / +easier to understand +0% +50% +100% +% of respondents +(open-ended text response) +If you could make a wish and improve one thing about error messages in the Go +toolchain, what would you change? +n = 357 + + diff --git a/_content/blog/survey2023h2/what.svg b/_content/blog/survey2023h2/what.svg new file mode 100644 index 0000000000..622c197a30 --- /dev/null +++ b/_content/blog/survey2023h2/what.svg @@ -0,0 +1,128 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +34% +4% +74% +38% +62% +37% +4% +9% +7% +44% +3% +3% +42% + + +Other +Mobile apps +Games +Machine learning / Artificial +intelligence +Embedded devices / Internet of Things +Desktop / GUI applications +Agents and daemons (e.g., monitoring) +Data processing (e.g., pipelines, +aggregation) +Automation/scripts (e.g., deployment, +configuration management) +Websites / web services (returning +HTML) +Libraries or frameworks +A runnable/interactive program (CLI) +API/RPC services (returning non-HTML) +0% +50% +100% +% of respondents +(select all that apply) +What types of things do you build with Go? +n = 3,655 + + diff --git a/_content/blog/survey2023h2/where.svg b/_content/blog/survey2023h2/where.svg new file mode 100644 index 0000000000..b36885597a --- /dev/null +++ b/_content/blog/survey2023h2/where.svg @@ -0,0 +1,77 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +26% +7% +1% +59% +78% + + +None of the above +Evaluating for potential use at my +primary job +Education / to expand my skill set +Personal or open-source projects +For my primary job +0% +50% +100% +% of respondents +(select all that apply) +During the past month, in what types of situations have you used Go? +n = 3,797 + + diff --git a/_content/blog/survey2023h2/where_exp.svg b/_content/blog/survey2023h2/where_exp.svg new file mode 100644 index 0000000000..079718ab03 --- /dev/null +++ b/_content/blog/survey2023h2/where_exp.svg @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +14% +20% +38% +2% +4% +13% +0% +1% +1% +73% +57% +49% +91% +85% +63% + + +None of the above +Evaluating for potential use at my +primary job +Education / to expand my skill set +Personal or open-source projects +For my primary job +0% +50% +100% +% of respondents + + + +0 – 2 years of Go experience +3 – 4 years +5+ years +(select all that apply) +During the past month, in what types of situations have you used Go? +n = 3,796 + +