It’s Survey Time: Shaping the 2025 Go Roadmap

Host: Hey everyone, welcome back to Allur. I’m your host, Alex Chan. Today, we’re diving into something that might—at first glance—seem like just another administrative task on your to-do list, but it’s actually one of the most powerful tools we have as developers. I’m talking about the annual Go Developer Survey. Host: Joining me today is Marcus Thorne. Marcus is a Senior Backend Engineer at QuantEdge, where they’ve been running Go in production for over six years. He’s also a frequent contributor to the Go ecosystem. Marcus, it is so great to have you here on Allur. Guest: Thanks, Alex! It’s a pleasure to be here. I’m a huge fan of the show, and honestly, any excuse to talk about Go and the direction it’s heading is a win for me. Host: Well, the feeling is mutual! So, Marcus, let’s get right into it. Every year this survey pops up. For the average developer who’s busy pushing code and fixing bugs, it can feel like "just another form." Why should we actually care about the 2025 survey? Guest: (Laughs) I get it. We all have survey fatigue. But with Go, it’s… it’s actually different. The Go team is notoriously conservative about adding features—which is why we love the language, right? It stays simple. But that means when they *do* decide to change something, they need mountains of evidence to justify it. If you look at the 2025 roadmap, they’re looking at things like AI integration and the evolution of the standard library. If we don’t speak up, they might spend six months optimizing something that only five people use, while the rest of us are struggling with, I don’t know, structured logging or specific IDE lag. Host: That’s a great point. It’s about preventing that "development in a vacuum" feel. You mentioned the standard library. It’s often called Go’s "killer feature" because it’s so robust. But is it starting to show its age? I saw the survey is asking about things like HTTP/3. Guest: Oh, absolutely. I mean, the standard library is incredible, but the web in 2025 looks very different than it did in 2012. We’re seeing more demand for modern protocols out of the box. And then there’s the whole "simplicity vs. power" debate. One of the big themes this year is whether the "simplicity" ethos is actually starting to hinder productivity as our systems get more complex. Host: That’s interesting! I’ve definitely felt that. Like, sometimes I’m writing the same boilerplate and I think, "I love how clear this is, but man, I’m tired of typing this." Speaking of repetitive typing… we have to talk about the elephant in the room: error handling. Guest: (Laughs) I knew you were going to bring that up! The famous `if err != nil`. Host: I had to! It’s the meme that never dies. Do you think the survey results this year could actually lead to a syntax evolution? Or are we stuck with it forever? Guest: You know, um, actually, I think we’re at a tipping point. For years, the community said "leave it alone." But as the user base grows, the "friction," as the Go team calls it, is becoming more documented. In the survey, they’re asking specifically about developer satisfaction and productivity. If thousands of people say, "Hey, I spend 30% of my time writing error checks and it makes my code harder to read," the Go team will listen. They won’t do something radical like try-catch, but they might find a "Go-way" to streamline it. We’ve seen them do it before. Host: Right! Like with Generics. I remember the debates about Generics went on for years. People were so worried it would ruin the language. Guest: Exactly! And that’s the best example of the survey’s power. Year after year, Generics was the #1 requested feature. The Go team didn’t just ignore it; they spent that time researching how to do it *without* breaking the things we love about Go. And now, with Go 1.18 and beyond, we have `any` and type parameters. I use them in our internal libraries at QuantEdge all the time now, and it’s saved us thousands of lines of duplicated code. That wouldn’t have happened if the community hadn't been persistent in those surveys. Host: It’s like a slow-moving but very powerful feedback loop. I also noticed the survey is leaning heavily into "emerging technologies" this year—specifically AI and WebAssembly. Are you seeing much Go in the AI space? I usually think of Python for that. Guest: It’s funny you say that. Python owns the research side, but for *deploying* those models at scale—especially the glue code and the API layers—Go is becoming a huge player. But the friction is there. If you’ve ever tried to integrate a Go backend with a modern C++ based AI framework or handle massive data streams for inference, you know where the pain points are. The Go team is basically asking, "What do you need from us to make Go the best language for AI infra?" If we don’t tell them, we’re going to be stuck using wrappers that might not be optimized. Host: Right, it’s about making sure Go doesn’t become a "niche" tool for just microservices. I also want to touch on tooling. I live in VS Code, and `gopls`—the language server—is my best friend, but sometimes it just… hangs. Guest: Oh, I’ve been there. The "Language Server is restarting" notification is the bane of my existence. Host: (Laughs) Exactly! Guest: And that’s in the survey too! They want to know about IDE integration. They want to know if `go.work`—which was another feature born from survey feedback for multi-module repos—is actually working for people. It’s these "quality of life" things that often matter more on a daily basis than a big syntax change. Host: So, if I’m a junior dev, or maybe I just started learning Go three months ago, should I still take the survey? Or is this just for the "experts" like you? Guest: Oh, honestly, the junior perspective is arguably *more* important. The Go team needs to know what’s confusing for newcomers. If a senior dev is used to a weird quirk, they might not even report it as a problem anymore because they’ve developed muscle memory. But if a new dev says, "I spent three hours trying to understand how modules work," that is a massive red flag for the language’s growth. We need the hobbyists, the WASM experimenters, and the students to speak up just as much as the enterprise engineers. Host: That’s such a good point. We don’t want the roadmap to be skewed toward only one type of user. Now, I have to ask about privacy. I remember there was some drama a while back about "telemetry" in the Go toolchain. Does the survey respect that same privacy-first mindset? Guest: Definitely. The Go team is famously conservative with data. The survey is aggregated, it’s used strictly for the project, and they always release a big public report afterward. It’s very transparent. In fact, the way they handled the telemetry situation—making it opt-in and being very clear about what’s collected—was a direct result of the community saying "Whoa, hold on" in previous feedback cycles. They actually listen. Host: It’s rare to see a major tech project be that responsive to its community. So, Marcus, before we wrap up, if you could pick just *one* thing you’re hoping to see on the 2025 roadmap as a result of this survey, what would it be? Guest: Oof, tough one. Honestly? I think I’m ready for a refined iteration on error handling. Not a total rewrite, but just… something to reduce the boilerplate. If the survey shows that 80% of us are feeling the same pain, I think we might finally see a proposal for it in 2025. Host: I’m crossing my fingers for that one too. Marcus, thank you so much for joining me today. This has been a really enlightening look at the "human" side of the Go roadmap. Guest: Thanks for having me, Alex! And everyone—go take those ten minutes and fill out the survey. It matters! Host: You heard him! Seriously, if you use Go, even just for small scripts, head over to the Go Blog and find the link for the 2025 Developer Survey. It takes maybe 10 or 15 minutes, and it’s your chance to tell the maintainers what’s working and what’s driving you crazy. Whether it’s better AI support, more robust HTTP protocols, or finally fixing that IDE lag, your voice is the data they need.