Every year, the JetBrains Developer Ecosystem survey gives us a snapshot of how developers work. This year, 28,945 developers took part between May and July 2026, and 1,836 of them named Go as one of their primary programming languages.

To celebrate Go’s 17th birthday, in this post, we look at who those Gophers are, which tools they rely on, how AI is changing their day-to-day work, and what the most significant events of this year were for the Go community.

TL;DR:

• Go developers are among the most experienced in the survey: 66% have six or more years of professional coding experience, compared with 49% of all respondents.
• The standard library has caught up with Gin: net/http is now used by 46% of Go developers for web development, up from 32% last year.
• Gophers are heavy AI users, especially in the terminal: 86% use AI coding agents in the CLI at least once a week, compared with 74% of all respondents.
• They keep humans in charge: 79% often or always review AI-generated code before accepting it.
• The language took one of its biggest steps since generics, with generic methods, encoding/json/v2, and the Green Tea garbage collector arriving this year.

Who are Go developers in 2026?

Backend first, full-stack on the rise

Web services are still Go’s home turf: 80% of Go developers use Go for backend web development, and 49% use it to build CLI utilities and small tools. The biggest shift is in full-stack work, which grew from 30% in 2025 to 40% in 2026 – a trend that matches the rise of TypeScript as Go’s favorite companion language (more on that below).

In relative terms, the fastest-growing task is deploying and managing AI models, which doubled from 3% to 6%. It’s still a niche, but the tooling is maturing. Community projects like Ardan Labs’ Kronk, led by Bill Kennedy, bring hardware-accelerated local inference directly into Go applications.

Polyglots that love TypeScript

Go developers rarely live in Go alone. Only 46% name Go as their single main language. Among their other primary languages, Python (35%), TypeScript (27%), and Java (22%) are the most common.

This holds true even more so for individual projects. Just 27% of Go developers use no other language alongside Go in the same project, down from 35% in 2024. TypeScript has become Go’s most common project companion, jumping from 24% in 2024 to 43% in 2026 and leaving Python (27%) and JavaScript (24%) far behind. A Go backend with a TypeScript frontend is turning into the default stack for a growing share of teams.

Happy where they are – with a soft spot for Rust

Most Go developers aren’t looking to move: 70% don’t plan to adopt or migrate to another language in the next 12 months, up from 64% in 2024 and higher than the 63% we see across all respondents of the Developer Ecosystem 2026 survey.

Among those who do plan to learn something new, Rust dominates. Chosen by 16% of Go developers, the share has been holding steady for three years now. We see that they don’t just stop at admiring the language; they actively adopt it – the share of Go developers who used Rust in the last 12 months grew from 14% in 2019 to 25% in 2026, so one in four Gophers now has at least some experience with Rust.

That doesn’t mean Go services are being rewritten, though. Rust is the most desired language across the whole survey, and many developers may be using it for side projects or for narrow, performance-critical components.

Gophers by choice

Go isn’t just something developers are forced to use at work. While 82% use Go professionally, 70% also use it for personal or side projects, and 40% use it for hobby projects. When that many developers reach for a language in their free time, it’s a good sign that they actively choose Go rather than merely tolerate it.

Experienced and well paid

Go remains a language of experienced engineers. Two-thirds (66%) of Go developers have six or more years of professional coding experience, compared to an average of 49% of all respondents. At the other end of the scale, only 3% have less than a year of professional experience or none at all, compared with 13% overall.

That seniority is reflected by salary bands as well. 17% of Go developers earn more than USD 120,000 a year, compared with 13% of all respondents, and the share earning more than USD 180,000 is almost twice as high (9% vs. 5%).

Tools and libraries

The standard library catches up with Gin

Go’s standard library has always been one of its strongest selling points, and external frameworks struggle to compete. This year, net/http usage among Go developers rose to 46% (from 32% in 2025), putting it practically level with Gin (48%), which held steady.

Among the other options for web development frameworks, chi (15%), Echo (13%), and Fiber (13%) are the most popular, and only 12% of Go developers don’t use any web framework or router at all.

We can’t measure the reasons directly, but there are a few factors that may contribute to the rising popularity of the standard library’s net/http. Since Go 1.22, the standard ServeMux supports method matching and wildcards in route patterns, which covers much of what developers used to pull in a third-party router for. Meanwhile, the original gorilla/mux, which dominated for a long time but was archived in 2022, is likely slowly being replaced in production projects. Finally, with agentic development on the rise, one of Gin’s primary advantages – handling repetitive tasks – no longer seems relevant, since AI can handle the boilerplate on its own and will favor the standard library to avoid dependency resolution.

Testing frameworks and mock libraries follow a similar stdlib-first pattern: 35% of Go developers don’t use any external frameworks, followed by Testify at 31% and GoMock at 25% – a noticeable rise from 17% in 2024. Interestingly, the share of Go developers who don’t write unit tests dropped to 14% in 2026, from 21% in 2025. This might be because they can now use AI to help with this task; in fact, we see that 84% of Gophers use AI to generate tests weekly or more often – an increase of 20 p.p. compared to 2025!

The starkest contrast is in build systems: 86% of Go developers use go build, while 46% also rely on Makefiles. Other tools (Gradle – 6%, Bazel – 4%) lag far behind.

IDEs – a more crowded field

With the rise of AI, the editor landscape for Go has diversified. GoLand (49%) and VS Code (48%) are each used by about half of Go developers. Zed nearly tripled its share (5% to 14%) in a year, Cursor held steady at 14%, and Neovim edged up to 10% at the expense of Vim.

But we don’t see developers abandoning the IDE. As the AI section below shows, more Go developers say the time they spend in their IDE has increased over the past year than say it has shrunk, and IDE-based coding agents are part of their daily routine. The question is no longer whether developers use an IDE, but how it fits into a workflow that also includes agents running in the terminal and in the cloud.

AI – Gophers are all in

In August, Cameron Balahan and Richard Seroter from Google argued that Go is an ideal language for AI-assisted software engineering. Their case rests on Go’s design for team-based engineering: a single toolchain, enforced formatting, static types, fast compilation, a batteries-included standard library, and a compatibility promise that keeps old code building. All of these give humans and agents fast, deterministic feedback.

Our data can’t tell us whether AI output in Go is actually better than in other languages. What it does show clearly, though, is that Go developers have built AI into their work more deeply than almost anyone else.

Go developers out-use other developers

Of the 23 AI-assisted tasks we asked about, Go developers report significantly higher weekly usage than the overall developer population for 16 of them, and do not report significantly lower usage for any of them. The biggest gaps are visible in higher-level tasks:

• Editing code across multiple files: 89% (83% across the general population).
• Agentic development of features or programs: 84% (76% across the general population).
• Generating tests: 83% (72% across the general population).
• Generating code comments or documentation: 83% (76% across the general population).
• Brainstorming new ideas: 82% (73% across the general population).
• Performing code reviews: 80% (72% across the general population).

For everyday tasks like code completion (79% for both groups) or generating boilerplate (82% to 80%), Go developers are on par with everyone else.

Terminal agents are the Gopher’s tool of choice

The clearest difference is in how Go developers use AI coding agents. 86% run agents in the CLI or terminal at least once a week, compared with 74% of all respondents, and only 5% never use them (general population – 14%).

Our first guess as to why that happens was seniority – it stands to reason that experienced developers tend to feel more at home in the terminal. But the gap holds when we compare like with like: Among developers with six or more years of experience, 87% of Go developers use CLI agents weekly, compared to 75% of the general population.

A more likely explanation is the nature of Go work itself. Go developers build CLI tools, infrastructure, and services that live in the terminal, so it’s natural for their AI tools to live there too. And the Go toolchain – go build, go vet, go test, go fmt, and go fix – gives terminal agents a fast, predictable feedback loop, which aligns with the point the Go team made.

That doesn’t mean the IDE is left behind. Gophers actually use coding agents inside their IDE every day more often than average developers – 61%, compared with 51% of all respondents.

More code is fully generated by AI

Go developers also hand more of their code over to AI. 55% say that more than 60% of the code they produced for work in the last month was fully generated by AI coding agents, compared with 43% of all respondents. Only 6% say none of their code was fully AI-generated (compared with 10%).

However, that doesn’t translate into riskier habits. Go developers run agents in “YOLO” (full permission) mode about as often as everyone else: 10% do so almost always (compared with 8%), and 14% in most cases (compared with 13%).

But humans still own the review

When AI writes more of the code, reviewing it becomes an increasingly more important part of the job. Gophers take that job seriously – 79% review AI-generated code often or always before accepting it, and only 8% rarely or never do. They look well beyond whether the code compiles. In our survey, they declared checking:

• Functional correctness: 79%
• Code quality: 75%
• Architecture of the generated solution: 69%
• Security: 64%
• Readability: 62%
• Adherence to project standards: 59%
• Performance: 56%
• Style: 43%

Most of that review happens in the IDE (65%), followed by the AI coding agent itself (50%), pull/merge request review on GitHub or GitLab (42%), and the terminal (40%). Dedicated AI code review tools, such as CodeRabbit or Cursor Bugbot, are used by 16%.

Go developers use AI to help with reviews, but they want to keep the final call to themselves. When we asked which activities they would hand over to AI, code review had the highest share of devs saying they’d still do it themselves (34%), compared with just 9% for writing tests or boilerplate code.

Heavy users, healthy skeptics

Heavy use doesn’t mean blind trust. 29% of Go developers rate AI-generated solutions as worse than code they write themselves, slightly more than the 25% of all respondents. In other words, Gophers don’t rate AI output more highly than other developers do. The case for Go in the AI era rests on how well its tooling supports AI-assisted workflows, not on AI writing better Go.

At the same time, Go developers are more likely to think AI will eventually take over coding entirely: 33% agree, compared with 22% of all respondents.

The IDE isn’t going anywhere

Despite all the talk of agents replacing editors, more Go developers say the time they spend in their IDE has increased over the past year (44%) than decreased (33%). The picture is somewhat polarized, though. Go developers are at the same time more likely than average to report a significant decrease in use (15% vs 10%), which suggests that some have moved large parts of their workflow to terminal agents, while many more use the IDE as the place where they guide, review, and refine AI-generated code – 61% of Go developers run coding agents in their IDE daily.

That’s the workflow JetBrains is now building for. Recently, we introduced JetBrains Air in IDEs – an agnostic system of products for agentic software development. The Developer Ecosystem survey proves that a modern workflow no longer fits in a single window – it spans the editor, terminal, and agents, with context and responsibility becoming increasingly scattered along the way. Go developers are a prime example – they run agents both in the terminal and the IDE; they review results in the IDE, the agent, pull requests, or the command line. Air in IDEs allows you to bring the terminal agents you already use, review every change where you already would, verify it with GoLand’s tools and not just your eyes, give agents your IDE’s context, and run all the work in parallel.

As agents take on more of the execution, the bottleneck shifts from producing code to understanding, verifying, and owning it. JetBrains Air in IDEs makes that work faster by putting the agents Go developers already use right next to the code intelligence they rely on to verify the result.

The future of Go – stable and getting more experienced

Go’s footprint in the survey is steady. In each of the last three years, around 1,800 respondents named Go as one of their primary languages, and Go’s share among primary languages has stayed between 7% and 9% (7.7% in 2024, 8.5% in 2025, and 7.4% in 2026).

The developers who use Go are the same, so their demographics are naturally shifting as the community matures. The share of Go developers with six or more years of professional experience grew from 52% in 2024 to 66% in 2026, while the share with one to two years of experience fell from 14% to 9%.

Is this just proof that the whole industry is getting older and juniors are having a harder time getting in? Partly, but Go’s shift is much sharper. Across all respondents, the share of developers with six or more years of experience grew by 5 percentage points over the same period, and the share with one to two years fell by 2 points. For Go, the changes were 14 and 5 points.

Go has always appealed to engineers who already know what they want from a language: simplicity, readability, and a toolchain that stays out of the way. As the community becomes more senior, welcoming the next generation of Gophers becomes increasingly important for the ecosystem’s long-term health.

What’s new in Go – highlights from Go 1.26 and Go 1.27

This was one of the busiest years for the language since generics arrived in Go 1.18. Here are the changes we think matter most, and how GoLand supports them. For a deeper dive, watch the recordings of our Go 1.26 and Go 1.27 release parties.

Syntax updates

Generic methods (Go 1.27)

Methods on concrete types can now declare their own type parameters – one of the most requested features since Go 1.18. Interface methods still can’t be generic, and generic methods can’t be used to implement interface methods. The Go blog explains the reasoning and the design trade-offs.

type List[E any] []E
 
func (l List[E]) Map[R any](f func(E) R) List[R] {
    out := make(List[R], 0, len(l))
    for _, v := range l {
        out = append(out, f(v))
    }
    return out
}

Go 1.27 also lets struct literals set promoted fields of embedded structs directly and extends function type inference to all assignment contexts.

Pointer creation with new() (Go 1.26)

The built-in new function now accepts an expression as its initial value, so you no longer need a temporary variable to get a pointer to a computed value.

// Before
age := yearsSince(born)
p := Person{Age: &age}
 
// Go 1.26
p := Person{Age: new(yearsSince(born))}

Type-safe error unwrapping with errors.AsType (Go 1.26)

errors.AsType is a generic version of errors.As. It returns the matched error directly, so there’s no pointer to set up and no risk of a type-mismatch panic.

// Before
var pathErr *fs.PathError
if errors.As(err, &pathErr) {
    log.Println(pathErr.Path)
}
 
// Go 1.26
if pathErr, ok := errors.AsType[*fs.PathError](err); ok {
    log.Println(pathErr.Path)
}

Tooling

New go fix modernizers

Go 1.26 rebuilt go fix on the same analysis framework as go vet. It’s now home to dozens of modernizers that update code to current idioms – for example, using min and max, ranging over integers, or replacing manual string splitting with strings.Cut – as well as the //go:fix inline directive, which lets library authors ship self-service API migrations. Go 1.27 added more modernizers, including atomictypes, embedlit, slicesbackward, and unsafefuncs. With more code written by AI agents that tend to reproduce older idioms from their training data, go fix is becoming an important part of everyday Go development.

GoLand 2026.2 also shows the official go fix modernizers, including those added in Go 1.26 and 1.27, as inspections with quick-fixes. You can collect every suggested modernization across the project in the Problems tool window, review the diffs, and apply them in bulk. Recent 2026.2.1+ updates can also run go fix automatically as a pre-commit check.

For your agents, we also released the modern Golang skills, which help you generate modern idiomatic Go code from the get-go.

Goroutine leak profile

Introduced as an experiment in Go 1.26 and generally available in Go 1.27, the new goroutineleak profile reports goroutines that are blocked forever on a channel, sync.Mutex, or sync.Cond that nothing else can reach. It’s also exposed at /debug/pprof/goroutineleak.

GoLand 2026.2 introduced the Go Optimization tool window, which profiles regular applications straight from run/debug configurations. It captures CPU, memory, mutex, block, goroutine, and the new goroutine leak profile. You can check the results as flame graphs, call trees, and graphs. The tool also maps hotspots back to the offending line of code in the editor gutter. You can import pprof profiles from production or other developers. Our practical guide to profiling in Go walks through each profile type and explains when to use them in detail.

Green Tea garbage collector

The Green Tea garbage collector, previewed in Go 1.25, became the default in Go 1.26. The Go team expects a 10%–40% reduction in GC overhead for programs that rely heavily on the garbage collector, with roughly another 10% on newer CPUs that support vector instructions (such as Intel Ice Lake and AMD Zen 4 or later). Go 1.27 followed up with a size-specialized allocator that reduces the cost of some small allocations (under 80 bytes) by up to 30%. Both are on by default, so programs benefit just by upgrading.

To see what these runtime changes mean for your own code, compare memory profiles before and after upgrading in the Go Optimization tool window, and use GoLand 2026.2’s escape analysis support to see which values the compiler keeps on the stack and which escape to the heap.

Packages

SIMD (experimental)

Go 1.26 introduced the experimental simd/archsimd package for amd64, giving direct access to 128-, 256-, and 512-bit vector operations. Go 1.27 added a portable simd package with architecture-independent vector types that fall back to emulation where hardware support is missing, and extended archsimd to arm64 NEON and WebAssembly. Both still require GOEXPERIMENT=simd, and their APIs may change.

UUID (Go 1.27)

Go 1.27 adds a uuid package to the standard library, implementing RFC 9562 – one less reason to reach for a third-party dependency.

JSON v2 (Go 1.27)

After a release as an experiment, encoding/json/v2 and encoding/json/jsontext no longer require a GOEXPERIMENT flag, and the original encoding/json is now implemented on top of v2. The new package is stricter by default – it rejects invalid UTF-8 and duplicate object keys, matches field names case-sensitively, and unmarshals significantly faster. Existing code doesn’t have to migrate, and you can opt out of the new implementation with GOEXPERIMENT=nojsonv2.

Go community events in 2026

Gophers met in person all over the world this year, and we’ve been lucky to sponsor and participate in some of the events to get a chance to meet you all and share some of our knowledge as well.

Some of the highlight events included:

• GopherCon (August 3–6, Seattle), the event of the year for all Gophers. 
• GopherCon Singapore (May 20–22, Singapore), where GoLand’s Engineering Lead Arseniy Terekhov talked about modern Golang skills.
• GopherCon Europe (June 15–18, Berlin)
• GopherCon UK (August 11–13, London), where GoLand’s Developer Advocate Ainsley Clark spoke about staying passionate about programming in the age of AI.
• GopherCon LatAm (September 2–4, Florianópolis), where GoLand’s Engineering Lead Arseniy Terekhov talked about nil pointer dereference.
• GopherCon Africa (October 15–17, Nairobi), where GoLand’s Developer Advocate Ainsley Clark ran a workshop on building domain-driven Go applications with sqlc and templ and gave a talk about //go:embed.

We also hosted two release party livestreams. At the Go 1.26 release party in February, Anton Zhiyanov live-coded his way through the new features, and Alex Rios showed how GoLand supports them. For the Go 1.27 release party in August, hosts Ainsley Clark and Jesús Espino were joined by Cameron Balahan, Robert Griesemer, Alan Donovan, and Marc Dougherty from the Go team at Google, and by Joe Tsai from Tailscale, who gave a first-hand account of what’s new in this release.

Conclusion

Go in 2026 is a mature language with an experienced and loyal community. Gophers use Go for work and for fun, lean on the standard library more than ever, and test more of their code. They’re also among the most enthusiastic adopters of AI coding agents, especially in the terminal, while keeping humans firmly in charge of review.

The language hasn’t stood still either. Generic methods, a stricter and faster JSON package, UUIDs in the standard library, a faster runtime, and go fix that keeps codebases – and agent-written code – modern all make this one of Go’s strongest years.

A note about methodology

This analysis is based on the JetBrains Developer Ecosystem Survey 2026, conducted between May and July 2026 with 28,945 respondents. Unless stated otherwise, “Go developers” are respondents who selected Go as one of their primary programming languages (n = 1,836), and “all respondents” refers to the full sample. Go-specific questions (tasks, frameworks, testing, build tools, IDEs, and languages used in the same project) were answered by 1,529 Go developers. All figures are weighted. Some AI questions were shown to only a subset of respondents. Year-over-year comparisons use the 2024 and 2025 editions of the survey. Multiple-choice questions can add up to more than 100%.

Ryan chats with Ahmad Al-Dahle, CTO at Airbnb, about deploying multi-party AI agents to tackle the uniquely gnarly problem of customer support, how a moving target of rigorous evaluations helps engineers balance latency against accuracy, and the ways in which AI coding tools demand an even higher level of judgment from software engineering teams.

1236. In honor of Friday the 13th, we look at words about superstitions, including jinxes, theater curses, and the one phrase you don't say in a hospital.

The superstition segment was by Karen Lunde. Find her on igofirst.org.

A hearty thank-you to our Keepers of the Commas and one mysterious Immortal on Patreon. We appreciate your support!

• Larry Rosenblum
• Mahala Russell
• George Wilson
• Laurel Paul
• Linda Cox
• Birna Anna Björnsdóttir
• Kate Wade

🔗 Share your familect recording in Speakpipe or by leaving a voicemail at 833-214-GIRL (833-214-4475)

🔗 Watch my LinkedIn Learning writing courses.

🔗 Subscribe to the newsletter.

🔗 Find an edited transcript.

🔗 Get Grammar Girl books.

| HOST: Mignon Fogarty

| Grammar Girl is part of the Quick and Dirty Tips podcast network.

• Audio Engineer: Castria Communications
• Director of Podcast: Holly Hutchings
• Advertising Operations Specialist: Morgan Christianson
• Marketing and Video: Nat Hoopes, Rebekah Sebastian
• Podcast Associate: Maram Elnagheeb

| Theme music by Catherine Rannus.

| Grammar Girl Social Media: YouTube. TikTok. Facebook. Threads. Instagram. LinkedIn. Mastodon. Bluesky.

---

Hosted on Acast. See acast.com/privacy for more information.

Download audio: https://sphinx.acast.com/p/open/s/69c1476c007cdcf83fc0964b/e/6af1dc89625528ef28098c3c/media.mp3

---

In a normal ASP.NET Core API, the AddJwtBearer extension method points the Authority property at your Duende IdentityServer instance. On startup, the handler fetches the discovery document at /.well-known/openid-configuration and the JSON Web Key Set (JWKS), caches the validation keys in memory, and from then on validates every incoming token against them. You never think about offline authentication because connectivity and the keys are simply there.

Go 1.25 is end-of-life and no longer supported. We’ve published this release as a one-time measure to help users who still rely on Go 1.25 to mitigate this specific certificate revocation security issue. Please upgrade to a supported, secure version of Go such as the latest patch release of 1.26 or 1.27.

Microsoft build of Go 1.25.14-2 is a one-off release to backport the upstream fix for CVE-2026-111943. This release includes no other CVE fixes and still contains known, unpatched security vulnerabilities.

This release is available for download. For more information about this release and the changes included, see the table below:

Microsoft Release	Upstream Tag
v1.25.14-2	go1.25.14 release notes

The post Go 1.25.14-2 Microsoft build now available appeared first on Microsoft for Go Developers.