GopherCon UK 2025

Starting this post as I'm on the way home from a great few days at GopherCon UK, I had a great time.

This year's GopherCon UK was a little different than last year's given this year there were "tutorials" as a third session type.

GopherCon UK runs both "workshops" and "tutorials" - the former is a pre-conference, all-day training, whereas "tutorials" are during the conference and last 2 hours - in addition to the core "talks" which are 1 hour in length.

The introduction of tutorials alongside the core talks meant that, on top of choosing between talk sessions, I needed to choose between the two talk slots and a tutorial! Lots of tough choices as there were some really good sessions, but I very much appreciated there there was more opportunity for different learning opportunities, which is good.

I took the opportunity to almost entirely attend tutorials and focus on interactive sessions I could get value out of live, instead of joining the talks. It did mean I missed out on some great talks that I'll be catching up on when they come onto YouTube.

I'm hoping that there'll be "tutorials" next year as well - they were a lot of fun!

As you'll notice, this writeup isn't as in-depth as last year's - largely down to the fact that I was mostly in tutorials which were more hands-on!

Go Security – Past, Present, and Future

Roland Shoemaker took us through some of the history of Go's security team, the security of the project.

We heard about how many CVEs Go as a project have had - 20 in the toolchain, and ~140 in the (standard/extended) libraries.

Roland spoke about how Go's CVE count for cryptography compares to OpenSSL, noting that it's not quite a fair comparison given how long OpenSSL has been around for, but also talking about how Go doesn't aim to implement everything, as well as not having whole classes of bugs that are found in OpenSSL due to it using C.

Roland broke down the two types of CVEs Go sees:

• Denial of Service (DOS)
• Incorrect behaviour

From here, Roland walked through some examples, and briefly talked about how original Go Federal Information Processing Standards (FIPS) support was implemented for Google's use only (including a big warning saying "don't use if you're not Google"!)

Roland left us on the note that the Go security team are thinking about what comes next to secure and improve Go ecosystem security, for instance integrating govulncheck into the Go toolchain itself.

I'd also recommend a listen of Fallthrough: Patching Problems with Persnickety Proxies Purveyed by Paternalistic Princes (which I was on), as there are some interesting related thoughts from the panel.

Building a framework for reliable data migrations in Go

Bruno Scheufler took us through some principles of performing data migrations.

There were some good tips and explanations of the different approaches you can take - the slides are worth a review when they're available!

There was a good practical exercise, and I really enjoyed how Bruno's example project came with a shiny Terminal User Interface (TUI) to monitor traffic - very cool!

Bruno also shared gh-ost: GitHub's Online Schema-migration Tool for MySQL.

One quote Bruno left us with was great, and I very strongly agree with:

time spent up-front saves time during incidents

Code Generation for 10x productivity - no AI

Andrea Medda Campus took us through the process to become 10x engineers, by outsourcing boring work to machines.

I especially enjoyed the "no AI" in the tagline, as a way to stand out and/or curb folks' enthusiasm, considering these are practices we have been able to use for a bit, and that Go is generally well-suited to and are commonly used in the Go ecosystem - and AI tooling can use them, too!

Andrea noted how the benefits of using code generation for certain actions lead to:

• improved development speed
• improved standardisation and consistency
• easier to maintain (instead of needing to hand-write all that code, instead update a template that spits out all the code)
• improving scaffolding (generate code for API, DB, tests, etc)

In particular we saw how Go can be used for this:

• go generate
• go/ast, go/parser, text/template

Andrea noted that you can use these tools - inbuilt to the standard library and Go toolchain - to almost immediately be effective.

Andrea took us through the original (and still intact) design decisions for go generate, and referenced Eli Bendersky's post on it, too, about how:

• programs are written that will write other programs
• it needs to be explicitly run, not being part of go build
• it's intentionally simple

We then went through a few different tools, seeing what different things they could bring to your project:

• goenum
• mockgen
• sqlc

I was eager to see the section about OpenAPI (via oapi-codegen), but unfortunately that was something that we didn't get around to digging into during the tutorial.

Next, we looked at a tool Andrea had written to generate tests for net/http handlers, allowing writing a JSON document to manage expected request/response for (integration) unit tests, and worked to extend it.

I noticed that the generated code wasn't formatted with go fmt, so added support via go/format as we wrote out the contnet.

Hello, MCP World!

Daniela Petruzalek gave us a great live coded demo of how to write a Model Context Protocol (MCP) server.

She started with a bit of a primer on what MCP is ("the USB-C for AI? More like HTTP + REST"), how it came about, and a classic xkcd reference:

Daniela shared the three key types of interactions:

1. Tools: AI uses them, model-controlled i.e. search flights, send messages
2. Resource: context data, app controlled i.e. docs, weather data
3. Prompts: interaction, user controlled ("plan a vacation for me")

Daniela took us through a mix of live-and-vibe-coding how to write an MCP Server for returning godoc information, as well as her speedgrapher MCP server.

When Failure Is Not an Option: Surviving Cloud Outages in Go

Kevin Holditch took us through a high-level view of Form3's migration from a Java-on-AWS-ECS stack to Go-on-multi-cloud-Kubernetes stack, and some of the tech choices needed to realise the requirements from banks using Form3's services.

A true test of the hard work the team had done was during a Google Cloud outage, in which Form3 didn't see any effect to payments during the time 🚀

I also liked Kevin's comment:

treat a cloud provider as an availability zone

This was a talk that brought up work at a previous company to make things super resilient (despite very little load, impact of service outages, etc) compared to something very much more needing resiliency, but things being a little more chill.

What story does your dependency tree tell you about your org?

I gave my interactive session all about dependency-management-data, which I felt went well, based on the preview I did at Manchester Gophers a couple of weeks ago.

There was some good discussion, engagement, and insights - thanks all for coming and looking forward to hearing more from folks when they work with it some more!

I very much feel that a workshop style setup works better for Dependency Management Data, where it's possible to get a real feel for the data and what interesting things you can do.

I feel I planned well with my work to use Evidence to visualise dependency data, allowing folks to join without a laptop - it worked nicely for a number of folks who didn't have their laptop, including me 🫣

I - as ever - play "hard mode" with AV equipment by running Linux, and this time, I could only get the screen for the "presenter view", but not the actual screen.

Thanks to A for letting me borrow your laptop temporarily to present the slides, and then to Juan for the HDMI Expansion Card which did the trick - I'll definitely be getting one of those myself!

For folks that didn't make it, you can follow along at home + I'm very much more than happy to chat over email!

• Example data visualisation
• Example repo: deps-fyi/gophercon-uk-2025

Observability made painless: Go, Otel & LGTM stack

Haseeb Majid gave a really good talk on OpenTelemetry and the Loki, Grafana, Tempo, Mimir (LGTM) stack.

This was a really great talk - the pacing was perfect (for my ADHD brain) and there was a lot of good details - especially for folks who've not had much interaction with OpenTelemetry, and I'd recommend a watch.

I also learned that it's possible to get Reveal.JS to perform step-by-step highlights of code which I'll definitely be taking advantage of in the future!

This was also a great deep-dive to lead into the start of Kemal's talk.

Unleashing the Go Toolchain

Kemal Akkoyun spoke about using the Go toolchain's toolexec functionality to introduce functionality into Go programs, without modifying the source code.

We had a primer on some of the key "signals" in OpenTelemetry (logging, metrics, tracing), and how OpenTelemtry instrumentation in various languages, and in particular how Go's lack of auto-instrumentation makes it a poor developer experience.

After digging into these examples of how to write your own, Kemal showed us the Orchestrion project from Datadog, which allows Aspect-Oriented Programming (AOP) to auto-instrument as you want.

Kemal shared how Datadog have been using this approach for:

• instrumenting their code (i.e. automagically adding OpenTelemetry spans)
• security checks (i.e. making sure that any os.ReadFile first checks if we have access to read it)
• capturing error stack traces automagically

And finally, for the most "dark magic" hacks, Kemal showed how you could create a version of Java's ThreadLocal by using go build -a -toolexec ... to allow you to rewrite Go's runtime package to modify how Goroutines are run and provide "Goroutine Local Storage" - a pretty cool and slightly cursed way of doing it!

I liked one of the quotes around why Go is great for things like this:

the power/magic of Go is in the tooling, not the language

This work is being fed into the work for OpenTelemetry's Go instrumentation.

I'm still not quite sure how I feel about automagic instrumentation - given one key positive of Go being that there's "no magic" - but also love how clear your functions look when there's no instrumentation, only business logic!

Building a coding agent from scratch

Bill Kennedy a masterclass in doing live coding.

It was a fun, fairly high-energy session going into how you can build an AI agent step-by-step.

Bill was working from example10 on the ai-training in the Ardan Labs AI workshop code - which I'll definitely be digging into more.

Bill referenced Thorsten Ball's post on How to Build an AI Agent, which is a great post and resource for explaining how, at the core, agents are a straightforward loop with some ifs.

oapi-codegen

It was great to get a chance to meet some users of oapi-codegen over the last few days, and get hear some constructive and positive feedback.

I ended up being recognised by a few folks, but also managed to speak to some people who didn't recognise me, so there was a bit more chance for honest feedback - mostly things I was aware of, but still good to hear!

As ever, it's also good to get a feel for folks' usage models, scale of some of the specifications they're working with, and issues such as:

• trying to split a large spec into multiple packages/files
• large duplicated code leading to i.e. hard-to-read diffs or large files that need to be parsed by the Go toolchain
• contract testing (which can be helped by openapi.tanna.dev/go/validator)

"You're from that blog I read!"

It was also very nice to bump into some blog readers, and chat about blogging, life and sharing so publicly.

I also realised I really need to get writing a "how I blog so much" and "how I write my week notes" blog posts.

Overall

I ended up chatting to many more people this year which was good, as well as chatting to some folks I've known for a bit but haven't yet physically met - 👋🏼 Berni!

It was another great year of food + drinks - a number of things I'd love to have eaten more of!

Thanks again to the organisers for another great conference!