The Gophercon EU Berlin 2025 talks are now available on youtube, which means it is time for me to rewatch them and ponder again about the things I learned, the things that made me laugh, and the things that reignited my love for Go.

This was my second in-person Gophercon, the last one being Gophercon EU 2022, also in Berlin, and I think I enjoyed this one more. I get the feeling that the organizers get better at this every year, with small touches that increase inclusivity and make a more diverse group of people feel welcome. Not to mention some cute ways to spread the word of the Gopher.

At this one, there was a little booth where you could assemble a little gopher out of stickers, put it all on a postcard, write down a message and address, and they would mail the postcards anywhere in the world.

The quality of the talks themselves always vary based on the speakers but this year was special for me. You see, I got to see Dave Cheney in person and got to tell him in a slightly high-pitched fanboy voice about how much his writings inspired me to pick up Go. I did have to then look Matt Ryer in the eye and tell him (he was standing right next to Dave) that I enjoyed his writing as well, just not as much as Dave’s. Matt, being the gracious human being that he is, told me that he felt the same way. I think he was the second-biggest fan of Dave’s at that conference.

Levity aside, there were some quality talks given by funny and passionate people and some sad reminders of what is currently wrong with the world (a speaker unable to attend due to the current geopolitical situation).

I won’t go through all the talks, you can do so yourself at GopherCon Europe: Berlin 2025. I will go through a few specific ones that I enjoyed more than the rest.

Talks

The titles are also links to the youtube videos.

# The Things I Find Myself Repeating About Go by Dave Cheney

I’ve always been a big fan of Uncle Bob’s Clean Code school of programming. He used Java in his examples but the ideas he put forward are applicable to any programming langauge.

Although I quite enjoy deep technical talks (and there were plenty of those), I love it when someone with long experience in the field talks about the basics of writing good code in a way that spans languages and technology stacks. Especially when they do it with as much of a mix of gravitas and humor as Dave brings to the stage.

That was what Dave’s talk was all about: how to write easy-to-read, maintainable code. I didn’t agree with all that he said (is it a sign of maturity, being able to disagree with your heroes?) but I appreciated all of it.

Some takeaways:

• Good naming is worth more than a sea of comments (though comments are never a bad idea). Sometimes even the lack of a full name can be good naming based on the context.
• Reduce conditionals to reduce the load on our fleshy thinking blobs.
• Keep to the left. Left-aligned code reads faster and easier. If you can get rid of an else statement by a little code-rearrangement, it’s often (not always) worth doing it.
• main.run! A pattern I had already picked up from Matt Ryer’s blog post. If you can make your entry-point accept environment-agnostic parameters, you can ship your code to various environments much more easily, not to mention making it a lot more testable. Stdout becomes an io.Writer, os.Args becomes a []string, context.Background becomes just another context.Context and probably more things you can think of.
• Make the default case the true case. If your users don’t want to give you their data, call the conditional variable DenyTelemetry instead of having a AllowTelemetry and then setting it to false. As Dave says “Bad things happen when you accidentally ingest data for a user who has denied telemetry.”, and this applies to all kinds of scenarios.
• Helpers, write lots and lots of helpers. Code in a helper is named and it is testable.

There were many more gems in his talk and I won’t go over them all or in much detail because I want you to go to youtube and see his talk. It’s a pleasure I dare not deny you.

Am I fanboying too hard right now?

# Panel with the Go Team by Damien Neil, Jonathan Amsterdam, Michael Pratt, Michael Stapelberg

A classic Q&A session with some of the Go Team, featuring Michael Stapleberg (Protobuf), Damian Neil (Security), Michael Pratt (Runtime/Performance), and Jonathan Amsterdam (Static Analysis/MCP SDK).

Questions were submitted beforehand, and again, I won’t go into all of them, but just some I find interesting. The bold part of each sentence is also a timestamped link to that part of the video.

• Support immutable datatypes: the team (and especially Michael Pratt) agree that it would be a wonderful feature to have but they don’t know how they would do it. I don’t know about you but I’ve often held up people like the Go Team on a sort of intellectual pedestal and it’s nice to see that they too are just people trying to solve challenging problems and sometimes the answer is: “We’re not sure how to do this so we’re leaving the issue be for now.”

• Data Science/ML Libraries: the team sees Go’s role in all this quite similar to my own: Go is a language that helps productionize what’s already built in, say, Python. They are committed to implementing important AI specs (such as MCP SDKs) but apart from that they don’t see great value in directly involving Go in ML training.

• Bare Metal Go: not something they’re actively considering, it seems, though they are interested in a new proposal submitted by people from the Tamago project.

• Most Useless Feature of Go (lang and stdlib): This mostly centered around things they would remove from the standard library, mainly libraries that are badly designed or badly designed APIs. Can’t say I haven’t had thoughts like that about my own code every few weeks.

• Error Handling 😬: One of the biggest points of contention within the Go ecosystem, the Go team’s answer was (and I’m paraphrasing): “we don’t know how to make it better in a way that makes the majority happy, we’ve given up for now and will focus on more impactful matters”. They’ve blogged about this recently as well. Can’t blame them, to be honest. I’m sure a huge number of people find Go’s error handling to be a PITA. I’m not one of them. For me, it’s a mild annoyance. There are also many for whom it doesn’t matter and may even be preferable. And to change something so fundamental would take a concerted effort from the Go team. And without a clear majority benefit I can see why they would rather spend that effort somewhere else.

• Non-nil Function Arguments: I’ve seen nil-pointer dereferncing called The Billion Dollar Mistake. Maybe I’ve lived for too little a time to appreciate this, and perhaps my elders have horror stories that would curl my toes, but I’ve never really had a problem with nil (null) pointers. I can count on the fingers of my hands the number of times in my 10+ year career I’ve had a nil pointer reference error. Perhaps others’ mileage has varied. Claude tells me (you can do more thorough research of your own if you wish) that the total valuation of the tech industry in 2009 (when Tony Hoare gave that talk) was around 11-12 Trillion USD. Which means Tony Hoare’s billion-dollar mistake caused a 0.0000909091 % or so of damage. I don’t think it’s anything to lose sleep over. Write me and convince me I’m wrong if you’re so inclined. I would love a different perspective on this.

  The Go team’s take on this was similar to the immutability problem: it would be nice to have, but currently they don’t see an elegant way to solve it. By this I suppose they mean the guts of the Go compiler. Syntax and DevX-wise I think Rust’s Option type is the GOAT.

  For some added hilarity, do sympathize with Christopher Null, especially if you ever wrote code that made the life of people like him more difficult than it needed to be.

• Performance of Garbage Collector: The hardware landscape keeps changing. One day you’re running on a dual-core machine, and then suddenly you’re on a 256-core one. I can imagine scaling garbage collection in such an environment is a unique challenge. Michael Knyszek is the person making sure this scaling happens and he has a proposal for something called the Green Tea 🍵 Garbage Collector.

There was a lot more they talked about. This was just a little taste of a few things I personally found interesting. Do check out the full talk.

# Refactoring Go in Large Codebases by Brittany Ellich

Brittany started off by reminding us all that as software engineers there are certain ways of thinking we relegate ourselves to. In the context of updating existing software we look at our old messy piece of code and think to ourselves: “I can do better if I rewrite this.” It’s the kind of trap we all fall into as succinctly summarized in Brittany’s talk (each line links to the part of the talk where she talks about it):

• It will be faster to just rewrite it
• We will move faster with clean code
• The current technology stack is holding us back

Watch the full talk to learn what advice she gives on how to go about refactoring (instead of rewriting) software.

# Go Protobuf by Michael Stapelberg

Michael talked about the what, why and how’s of Protobuf, especially as it relates to Go and then moves on to talk about the Opaque API.

The Opaque API has been around since the end of 2024 but isn’t something I have given much thought until this talk reminded me that I really should be using getters instead of direct field access. Call it my failing at avoiding Hyrum’s Law. It would have made much of my code cleaner.

Fortunately for me, smarter people than I (such as Michael) are about to force my hand. At some point in the future, field access will be replaced by a xxx_hidden_ prefix (wonder who came up with that one 🤔) and I will have to update all my code to use accessor methods.

Luckily for me, the smart people are also considerate people, and they’ve created a tool (open2opaque) that rewrites your existing code to conform to the Opaque API.

The Opaque API, apart from providing a cleaner API to work with and promoting safer coding practices, also allow for memory optimizations which provide significant speedups by reducing allocation counts. I encourage you to both read the blog post and watch the talk for yourself.

Michael not only mentions the open2opaque tool but also talks about how it was written.

Michael also mentions protoscope: Cool little tool (and representational format) for inspecting the protobuf wire format.

# Faster Go Maps With Swiss Tables by Michael Pratt

Fascinating deep talk on how Go maps work in general, the challenges involved in an operation such as increasing a map’s size, and how Swiss Tables come in and make everyone’s lives faster.

I won’t talk about it much, myself, I cannot keep all the details in my head no matter how many times I go over them, but I find them fascinating, nonetheless and I think you should watch the talk.

# For the Love of Go: How to Contribute Really by Arati Rana

The beauty of this talk lies in the humility and courage of its presenter. Arati Rana took her first steps into contributing to Go, struggled once and again, and kept at it. She shares the story of adding T.Output to go, a process that was filled with a lot of twisting paths.

# Y: Recursion The Hard Way by Eleanor McHugh

I left this one for last. Eleanor McHugh is probably the funniest person I’ve come across in a while who doesn’t do comedy for a living. Her talk softened my brain, then took the little melty bits and rearranged them in interesting ways.

I think I’ll need to watch it at least 15 more times to make any sense of it but that’s okay because watching her give the talk is one of the most pleasant experiences in my life, so far.

I won’t try to explain the talk. My fingers might start melting as well. In short, it is about doing recursion without a function calling itself.

Wait, that doesn’t sound right. Or does it? 🤔

Other Things

Between sessions, beautiful artworks made by talented gophers were displayed on the screen.

Lunch was served up by Fraulein Kimchi and Papa Africa Kitchen, simple hearty meals that gets one through a day of talks.

I had the fufu with peanut sauce from Papa Africa.

Breakfast (and snackies thoughout the day) was served by I don’t know who but I was a big fan of these long round pastries filled with spinach. I wish I had taken a picture. I think I ate more of those than actual lunch or the much more healthier option of fruit. There was a lot of fruit also on offer.

I stayed in a housing complex of sorts with lots of small rooms arranged around a central courtyard. You have to pass through multiple doors to get to where you need to go, so I slept peacefully knowing any would-be murderers were probably guests staying there. I would rather be killed by hotel cutlery than a shank from a street hobo.

The room I was in (and most rooms there, I can imagine) was functional. That’s the only way I can really describe it. It wasn’t sparse, it wasn’t messy or dirty, it just felt extremely functional. The furniture was old and well-used, there was only as much furniture as one could need, everything was quite minimal. It felt…minimal. I am at a loss for words to describe it because I still have mixed feelings about it.

On the one hand it does not meet my expectations of even a basic hotel room. It lacked pizazz! At the same time it was cleaner and more well-maintained than almost any hotel I’ve been to. It confounds my senses even as I think back on it. And I like it. And I would go back 11/10.

On my way back to the airport, I came across something…disturbing.

At the airport, the German version of the TSA kept my Oathbringer keychain. This was the last picture I managed to keep of it.