Results from the 2025 Go Developer Survey
29 points by cgrinds
29 points by cgrinds
Re: language gaps, the three top gaps are around error handling, sum types, and nil pointers.
For error handling, they've already decided there's not going to be any changes for the foreseeable future in terms of syntax support.
https://go.dev/blog/error-syntax
For sum types, there's already an FAQ entry on why Go doesn't have them:
https://go.dev/doc/faq#variant_types
For nil pointers, at GopherCon EU 2025, as part of the core team panel discussion (https://youtu.be/etl1Z8T4B9g?si=_B1VgXBDfqtC9xxk)
“And it's the same for the nilness stuff. Yes, it would be great to not have nil pointer exceptions. Um, but then that then you'd need two of everything or something. I'm not sure how it would work. Or you need, you know, flow typing, which is very interesting idea, but it makes code harder to read and understand.”
“And also like nil pointer errors are like the best kind of runtime errors because you get a stack trace and it's deterministic and it's right there. Uh let's focus on stuff like the previous speaker [on] how to deal with goroutines because the errors are non-deterministic and they often don't show up until production. That's the more interesting space. I'm not really worried about nil pointer exceptions
The panel discussion also had some mention of stack traces attached to errors.
I think it was Go 1.13 when we added errors. We had a collection of error-based proposals which did include the ability to put a stack trace in an error. Which we removed at that time due to various problems with the proposal as we had it. And I think that one of the the sort of unresolved points in there is that it's fairly easy to annotate, like to find a way of annotating an error with a stack trace, if you require people to write everywhere that they pass an error around explicit addition, like explicit annotations to add stack traces. But that's really not a very pleasant way of writing Go code. So it would be really nice if we could find some solution which doesn't require us to do that. Whether we can or not is as yet an open question.
There definitely seems to be interest/desire for a go-like language with just a few more niceties {result/option types, tagged unions/sum types}.
I though borgo was kind of a neat experiment (project seems to be in hibernation?).
There seems to be lots of interest in a Go++ language: borgo as you say, vlang, dingo, and jule come to mind. (Maybe Rue too, as another person mentions.) The problem with all of these so far is that they are not mature enough to actually use. They also seem to be the efforts of one or a small number of people, and projects like that often run out of steam entirely or undergo long quiet periods.
Go remains firmly among the languages that people complain about because they actually use it.
Steve Klabnik Is working on Rue (https://rue-lang.dev/) and it sounds a lot like Go with more affordances.
For sum types, there's already an FAQ entry on why Go doesn't have them:
Re sum types, I don't think that the existence of a FAQ entry means that the conversation is closed forever. (If I remember right, there was once such a FAQ entry on generics. I checked the wayback machine, but the earliest capture of the Go FAQ that I can find already talks about generics as an upcoming feature. Someone with a better memory than me may be able to confirm or deny what the FAQ used to say about generics.)
In the minutes from the November 25th meeting of Go's runtime and compiler group, there's this item under 2026 planning: "Think and explore language features: union type, generic methods, maybe tensor (?)" (Here's a link, but I apologize in advance: it doesn't seem to actually go to the correct anchor for me. https://github.com/golang/go/issues/43930#issuecomment-3576250284.)
I think that by "union type," they mean some sort of sum type, though people use the terms "sum type," "union type," and "enums" in all sorts of ways.
If I remember right, there was once such a FAQ entry on generics. I checked the wayback machine, but the earliest capture of the Go FAQ that I can find already talks about generics as an upcoming feature. Someone with a better memory than me may be able to confirm or deny what the FAQ used to say about generics.
This is because the site used to be at golang.org. The earliest entries were always open to the idea but looking for a design that fit. See https://web.archive.org/web/20130118182924/golang.org/doc/faq#generics.
I think that by "union type," they mean some sort of sum type, though people use the terms "sum type," "union type," and "enums" in all sorts of ways.
The specific use of the term “union type” seems very reasonable and appropriate for go (and thus hopeful): sum type (aka tagged unions) and union types are generally pretty well distinguished by their behaviour when trying to combine two instances of the same concrete type T, the union of T and T is T while the sum of T and T is 2xT.
Union types makes a lot of sense for Go, because go interfaces have a type tag, and that means you can reuse that mechanism for the runtime component of union types but it can’t differentiate between int and int, whereas sum types would require a separate runtime component, and likely additional syntactic elements (whereas union types would likely be able to reuse type switches).
Perhaps the best programming language survey and analysis I’ve ever seen. Kudos to the author Todd Kulesza and team. My only surprise was the small number of respondents. I was expecting an order of magnitude greater than the 5,000 included in the results.
My only surprise was the small number of respondents.
They run this survey every year. I'm not going to answer these every single year again and again.
Previous surveys help form questions for future ones and Go team takes action on these. So if you want to help move the language forward it could be worth it to take 10-15 minutes to fill it out once a year.
The questions are not the same. They usually try to focus on some areas. This year it was (unfortunately) AI.
I am not sure I have missed one.
I found it interesting that 70% of the surveyed Go developers used AI tools for Go development at least several times in the last week (over 50% using them multiple times per day). If forced to make a prediction of what the number would be without reading the survey results I really don't know what I would have guessed.