What’s New in Go: The Developer Ecosystem Report 2022
Every year JetBrains asks thousands of developers all around the world different questions about how they use programming languages. We then publish the results that show the current trends in various communities, including the Go ecosystem.
Today, we’re happy to share the State of Developer Ecosystem 2022 report!
EXPLORE THE STATE OF DEVELOPER ECOSYSTEM 2022 REPORT
In this post, we’ll take a deeper look at the trends around Go. We invited three members of the community to help us put our findings in perspective:
Go for enterprise
Go is undoubtedly a production-ready language. Many large companies use Go in production, and the list grows every year.
According to JetBrains’ research, the share of developers using Go for work-related projects grew from 61% to 64%.
The Developer Ecosystem data is somewhat consistent with the survey conducted by the Go team. Their data shows that the share of gophers programming at work increased from 66% in 2016 to 78% in 2021 (the Go team uses a multiple-choice question for this metric).
Expert analysis
Bartlomiej: “Amazing to see Go being used for production systems more year after year! It indicates trust in the language, as well as higher adoption.”
Michael: “Great to see Go being increasingly adopted at work – in the enterprise! This also means increasing trust in the language and its ecosystem. I am super excited about what the Go team and communities such as Sigstore and the wider Cloud Native Computing Foundation are doing to set the bar high for security (supply chain), usability (tooling), and consistency (how easy it is to read/adopt a code base). Pretty sure we’ll see this number going up further over the coming years as Go replaces a lot of legacy code bases in the enterprise and ISV/cloud space.”
Go modules
The concept of modules – Go’s dependency management system – appeared in the middle of 2018. Preliminary support for modules was added in the 1.11 version.
Recent data shows that 87% of Go developers use modules as their dependency management system.
Expert analysis
Michael: “Still a bit surprised to see that around 10% of developers are using mostly deprecated package managers. I guess it’s older code bases/projects or work projects where the tooling cannot be changed easily.”
Bartlomiej: “It’s great to see the majority of users leveraging Go modules which became the standard very quickly. If you don’t use it, I recommend switching to it as there are many innovations that work on top of Go modules, e.g. advanced security or license scanners, reliable installations of tools, and more. See an amazing guide for understanding Go modules better.”
Vendoring
Vendoring in Go means making your own local copy of all the dependencies needed for a particular project and including this copy in a file tree. This approach has its advantages – if you use vendoring, your project has all the code it needs for building an app. Every time you build a project, you get the exact same binary. You don’t have to rely on downloading dependencies from external sources. But vendoring has its downsides, too.
The share of developers using vendoring decreased from 46% to 41%.
Expert analysis
Bartlomiej: “I am so happy to see vendoring becoming less popular. It obfuscates the source repository, making it very hard to review the proposed changes to the code. It also makes developers a bit more lazy in building dedicated solutions that ensure dependency caching and reliability. In some way, the popularization of Go modules allowed developers to move away from vendoring, because of reliability and hermetic builds that are allowed by Go modules thanks to Go proxy and other mechanisms like go.sum.”
Michael: “I think Go modules and the way it distributes, manages, and verifies (beware of TOFU though) packages will further reduce the need to vendor Go projects.”
How many dependencies?
Dependencies are seen by many developers as a necessary evil. Necessary because you can’t build a non-trivial modern app without third-party packages, and evil because technologies change and having a lot of dependencies threatens your project’s stability.
Only 1 in 5 Go developers have fewer than 5 dependencies in their projects.
Expert analysis
Carolyn: “I loved it when Go updated the go.mod format to include both direct and indirect dependencies. I went from thinking that I had a totally normal number of dependencies to realizing that I actually had 4 times as many!”
Michael: “Carefully managing and verifying dependencies is a huge burden on every developer, as well as security, ops, and other teams. Shoutout to the Go core team and the Sigstore community, who are placing us in the best position to shift the complexity of supply chain management to the platform/tooling rather than leaving it to stressed out developers.”
Multiple Go versions
It is often said that Go is great at backward compatibility, but it seems not everyone can use the latest version. The share of developers using multiple versions at the same time increased from 23% to 32%.
Expert analysis
Bartlomiej: “The Go community and the Google Go team are constantly improving Go by delivering minor releases twice a year, plus many patches. With higher adoption, there will always be some projects who don’t always catch up with the latest version of Go.”
Michael: “Even 1.x.0 Go releases are pretty solid and I’m typically migrating my projects right away to a new version. However, for professional use, I set up CI to run at least with 2 – often 3 – different versions to detect when contributors introduce new language features and to catch other regressions – performance, dependencies, etc. So I’m in fact in both camps here: local development with only one version, CI with multiple.”
Go and other languages
JavaScript, Python, and Typescript are the most popular languages used along with Go in a single project.
Expert analysis
Michael: “I was initially a bit surprised to see such a high share of TypeScript. But I guess – and this is totally based on my own experience – once you experience the joy of a type-safe and statically compiled language like Go, TypeScript is what most Go and other developers would use instead of JavaScript. So I guess we’ll see this number trending up further over the coming years.”
Bartlomiej: “Since Go is used heavily for building end-to-end solutions, seeing frontend languages like JavaScript and TypeScript being used by 60% of users is not unexpected. Since mono repo is popular, it’s not uncommon to mix other languages into a single project. Results indicate over 40% work on some kind of monorepo-style projects.”
Web frameworks
Go is well-known for its great standard library when it comes to web development. Sometimes developers coming from other languages ask on Reddit what web framework they should use, and very often the answer is ‘use the standard library’ or ‘build your own framework’.
Still, quite a lot of people prefer to use ready-made frameworks like Gin. The popularity of Gin rose from 40% to 46% over the past year.
Last year’s survey didn’t include “net/http” as an answer option, which apparently led many standard library-only users to choose “None” instead. Now that we’ve added it this year, net/http is turning out to be almost as popular as Gin.
Expert analysis
Bartlomiej: “Go’s excellent standard library is sufficient to use for the majority of cases. Seeing 44% of respondents using net/http confirms that. This is good, because it means the standard library is battle-tested and ensures that auxiliary libraries and helpers are mostly focused on net/http, which makes Go so much easier to adopt.”
Testing
The built-in testing support in Go is appreciated by many developers, but there are a couple of frameworks, too. The most popular ones are testify and gomock.
Expert analysis
Michael: “Even though the number for built-in is down by a bit, I am so proud to see the built-in tooling being the standard for Go developers. If you work on a different project or language, I often find it harder to learn the tooling compared to the language itself because there seems to be no standard, especially for “older” languages. A Google search often reveals three or more different approaches, and looking at code bases is no different. That’s what I really enjoy working with Go: consistency and less ambiguity due to built-in tooling such as the powerful testing tools, go fmt, and many more!”
Bartlomiej: “It looks like we see a higher variance of user choices when it comes to testing libraries. It indicates there is still room to improve the standard library in this area. My recommendation is to stick to simpler frameworks like testutil we use in the Prometheus ecosystem. The more bloated and complex the testing framework API is, the harder it is to read, write, and rely on unit tests. This translates to developers refusing to write more tests and, as a result, less reliable code!”
Do you use a proxy?
There was a time when the go get command would download the modules directly from their source repositories in VCS systems like GitHub. This approach had some disadvantages – a module could be deleted by its author, and the versions could be edited (you can read about the pros and cons of the old approach in detail here and here).
In 2019, the Go team launched a public proxy server that caches the modules. Since the 1.13 version, GOPROXY’s default value is https://proxy.golang.org,direct. The proxy.golang.org server is a public repository accessible to all Go developers that serves modules when the go get command is launched. This approach ensures that the module you need is always available.
According to the JetBrains survey, 51% of respondents don’t use a proxy. It is probable that some developers don’t know about the default value of GOPROXY, as Carolyn Van Slyck points out in her comment below. We’ll try to take that into account when conducting a new survey.
Expert analysis
Carolyn: “I was surprised to see so many people saying that they don’t use a proxy! I suspect that many gophers don’t realize that the Go proxy is enabled by default and aren’t actually explicitly turning GOPROXY off.”
Template engines
Go’s built-in template packages text/template and html/template are a great way to generate text and HTML output. As our research shows, Go developers also use Pongo2 (Django-syntax-like template engine) and Plush.
Expert analysis
Bartlomiej: “As adoption of Go increases, we expect to see more applications that use templating engines to render artifacts other than websites (e.g. configuration). Remember to always use html/template if you render HTML pages, as it sanitizes inputs to avoid code injection attacks.”
Do you use gopls?
gopls is the official Go language server (LSP) developed by the Go team. GoLand, like other JetBrains IDEs, builds its own internal representation of the source code using an approach that is different from LSP.
This question was shown to developers who don’t use GoLand. 61% of those, as it turns out, use gopls.
We also asked gopls users about how satisfied they are with it.
Expert analysis
Bartlomiej: “gopls is getting better every day, but it’s not perfect, so I am not surprised users would like to see some improvements. I personally still prefer GoLand for all the software development work due to richer navigational, search, and refactoring features.”
Michael: “gopls definitely has gotten better over the last few years. I remember times when I had to continuously restart the language server or editor, because syntax highlighting and other features were broken. But compared to what I get with GoLand, especially the power of refactoring and smart type-matching completion, gopls has a ways to go in my opinion. But I understand that these features might also be overkill if you don’t write Go code every day/professionally.”
That’s it! Check out the full report and let us know what you think about the findings. You can ping us on Twitter, leave your comments here, or drop us a message in the Gophers Slack #goland channel. Thanks for reading!
Subscribe to GoLang Blog updates
