What is new since Go 1.25. In this talk we'll bring you up to date with all upcoming changes to the Go language and the community! Go 1.26 will be released in February 2026, we will be taking a look to all upcoming features as well as give an update on important changes in Go 1.235 This includes traditionally updates about the language, tooling, libraries, ports and most importantly the Go Community.
Profile-Guided Optimization (PGO) is a well-known compiler optimization technique that brings runtime statistics about how an application is executed to the Ahead-of-Time (AoT) compilation model, which is quite recently added to the Go compiler. However, this technique is not widely used nowadays.
In this talk, I want to discuss the current PGO state in the Go ecosystem. During my work on the Awesome PGO project, I gathered a lot of interesting data points and insights about various PGO issues and discussed many related quirks with different stakeholders like end-users, maintainers, and application developers. We will talk about:
I believe that after the talk more people will be aware of PGO, aware of usual PGO blockers, and know more about how to avoid these limitations in practice.
Target audience: performance-oriented Go users and Go compiler engineers
Go’s runtime has always prided itself on efficient, low-latency garbage collection. But modern hardware brings new challenges. More cores, bigger caches, and heavier workloads. In this talk, we’ll start by exploring how Go’s current garbage collector and memory allocator work together to manage memory. Then we’ll dive into the new GreenTea GC, an experimental redesign that cleans memory in groups (“spans”) instead of object-by-object. You’ll learn how it works, why it matters, and what this “span-based” approach could mean for your Go programs in the future.
I'll be exploring the Go source code: https://go.dev
Reflection is a form of metaprogramming that often feels like magic — letting you inspect and manipulate your code at runtime. But there's no magic here at all — just clever engineering that makes your programs simpler and more flexible.
In this talk, we'll take a look at how reflection actually works under the hood in Go. We'll explore how types and values are represented at runtime, what really happens when you call reflect.ValueOf or reflect.TypeOf, and how the compiler keeps this dynamic capability simple, yet powerful in its implementation.
After this talk, reflection will look a little less mysterious — and a lot more elegant.
Go's pprof tells you where your CPU time is spent, but not why the CPU is slow. Is it cache misses? Branch mispredictions? These hardware-level performance characteristics are invisible to pprof but critical for optimisation.
perf-go bridges this gap by leveraging Linux's perf tool and CPU Performance Monitoring Units (PMUs) to expose hardware performance counters for Go programs. It translates perf's low-level observations into pprof's familiar format, giving Go developers hardware insights without leaving their existing workflow.
In this talk, we'll: - Demonstrate the limitations of pprof for understanding performance bottlenecks - Show how perf-go exposes CPU cache behaviour, branch prediction, and memory access patterns - Walk through real benchmarks where we identify and fix cache-line contention issues - Explore how hardware counters can guide improvements that pprof alone wouldn't reveal
Go developers who want to optimise performance-critical code and understand the "why" behind their bottlenecks. Basic familiarity with profiling concepts helpful but not required.
Go 1.25 introduced testing/synctest, a package that brings deterministic scheduling and control over concurrency during tests. For developers who struggle with flaky tests, hidden data races, or hard-to-reproduce timing issues, synctest offers a powerful solution: it lets you run concurrent code in a bubble, so you can efficiently explore interleavings, force edge cases, and prove correctness.
In this talk, we’ll explore the motivation behind synctest, and dive into the testing patterns it enables. We’ll walk through practical examples of converting existing tests to use synctest. The session includes a demo illustrating how synctest can turn an intermittently failing test into a deterministic one, and surface bugs that traditional tests might miss.
Whether you build concurrent systems, maintain production Go services, or simply want more reliable tests, this talk will give you a solid understanding of what synctest brings to Go—and how you can start using it today.
Open source is under attack. Most notably the xz/liblzma backdoor incident (CVE-2024-3094) has shown how even trusted and widely adopted libraries can be compromised. Also, since February 2025, the Go language community has been observing an enormous amount of malicious Go modules being published with fake GitHub stars and very plausible contents.
This session introduces gomodjail, an experimental tool that “jails” Go modules by applying syscall restrictions using seccomp and symbol tables, so as to mitigate potential supply chain attacks and other vulnerabilities. In other words, gomodjail provides a "container" engine for Go modules but in finer granularity than Docker containers, FreeBSD jails, etc.
gomodjail focuses on simplicity; a security policy for gomodjail can be applied just by adding // gomodjail:confined comment to the go.mod file of the target program.
The session will discuss its design, implementation details, limitations (e.g., support for modules that use "unsafe" pointers or reflections), and the plan to improve its robustness and performance.
Repository: https://github.com/AkihiroSuda/gomodjail
File uploads are a ubiquitous and fundamental part of modern applications. While simple at first, they become increasingly challenging as file sizes grow. Users expect reliable data transfers, even when uploading multi-gigabyte files over unreliable mobile networks.
Conventional file uploads over HTTP fail unrecoverably when the underlying connection is interrupted. Resumable uploads, on the other hand, allow an application to continue uploading a file exactly where it left off. This preserves previously transferred data and greatly improves the user experience.
Tusd is an open-source file-upload server written in Go that makes it easy to add resumable uploads to any application - even those written in languages other than Go.
This talk explores why Go is a natural fit for such use cases. In particular, we dive into how contexts help coordinate concurrent, long-running HTTP requests, how the net/http package provides fine-grained control over request handling, and how Go’s tooling assists in testing various failure scenarios.
Additional links: - Tus homepage: https://tus.io/ - Tusd upload server: https://github.com/tus/tusd
This talk explores how to bridge sqlc’s type-safe database layer with a clean, domain-driven service architecture using Crush/OpenCode — an open source code generator written in Go.
Sqlc generates strongly typed database access, but using its structs directly can couple business logic to schema details. Crush/OpenCode automates the creation of repository layers that work with domain entities instead, orchestrating transactions while preserving compile-time safety.
Built entirely in Go, Crush/OpenCode uses Ollama and the gpt-oss model for “augmented generation,” guided by reference implementations to keep the produced code consistent and idiomatic. It also generates tests first, using testify/suite, Testcontainers-Go, gofakeit, and go-cmp, then refines repositories until tests pass.
The result is a practical Go-based workflow that reduces boilerplate, ensures consistency across repositories, and demonstrates how open source LLM tooling can enhance real-world Go development — without sacrificing simplicity or type safety.
Zero-touch observability for Go is finally becoming real. In this talk, we’ll walk through the different strategies you can use to instrument Go applications without changing a single line of code, and what they cost you in terms of overhead, stability, and security.
We’ll compare several concrete approaches and projects:
Beyond what exists today, we’ll look at how ongoing work in the Go runtime and diagnostics ecosystem could unlock cleaner, safer hooks for future auto-instrumentation, including:
runtime/trace and diagnostics primitives: Throughout the talk, we’ll use benchmark results and small, realistic services to compare these strategies along three axes:
Attendees will leave with a clear mental model of when to choose eBPF, compile-time rewriting, runtime injection, or USDT-based approaches, how OpenTelemetry’s Go auto-instrumentation fits into that picture, and where upcoming runtime features might take us next. The focus is strongly practical and open-source: everything shown will be reproducible using publicly available tooling in the Go and OpenTelemetry ecosystems.
This session will explore the development of GoDoctor, a Model Context Protocol server designed to improve the experience of coding with AI agents. This is not a product presentation, GoDoctor is actually a playground to test different types of tools applied to coding with LLMs, and in this talk I will focus on the different experiments I made and reporting on both successes and failures. The ultimate goal is to understand what works and what doesn’t for improving code generation for Go projects.
Developing Go for micocontrollers with 32kB of RAM requires a big shift in thinking, moreso if you are trying to get a complete networking stack with Ethernet, TCP/IP, HTTP to run on said device.
Over the past years we've learned how to minimize memory usage and make programs run performantly on these small devices by adopting patterns common in the embedded industry, some of which make working with Go a even better experience than the norm.
This talk explores the tried and tested "Embedded Go" programming patterns we've found to work and make developing in Go a pleasure, no matter the hardware context: - Avoiding pointers to structs within structs: rethinking the Configure() method - Zero-value programming - Eliminating heap allocations during runtime - Reusing slice capacity - Bounded memory growth on your program - Safe pointer-to-slice with generational index handles
Most Go codebases begin as straightforward layered monoliths, but years of growth often turn those layers into a web of hidden coupling and hard-to-predict side effects. Rewrites promise a clean slate but rarely succeed in practice. What the Go community lacks are real examples of large open source Go projects that have completed a transition to a modular monolith.
This talk presents the first major open source Go project undergoing this evolution. It covers how we are moving from a decade-old layered architecture to a modular design while continuing to ship features to hundreds of production environments. This is not theory. This is architectural change in a live system with real contributors, long CI pipelines, and legacy assumptions embedded throughout the code.
You will see practical strategies for decoupling features, aligning code boundaries with product teams, introducing modular service packages, and modifying database schemas without slowing ongoing development. We walk through the familiar pain points in large Go monoliths, including tight coupling, long test cycles, and frequent merge conflicts, and show how steady incremental refactoring creates a stronger and more adaptable architecture.
Whether you are working on a fast-growing Go project or maintaining a mature production system, you will leave with clear and concrete techniques to modernize your architecture safely and sustainably, all without stopping feature work or risking a disruptive rewrite.
In the 1970s, model trains were a popular hobby. Thanks to low production costs, anyone could afford a small HO gauge layout. The system was simple: a train, a motor, 12V DC in the track, and off you go!
Fifty years later, we took our trains out of the attic with a big idea in mind: to convert them to digital. With some Seeed Studio, Bluetooth, and TinyGo, we managed to get a functional railway network, were we can manage speed, direction, and lights of each train individually.
In this next edition of the "Go Wireless" saga, we will take Go to new heights...
Come speak! As every edition the last hour of the Go Devroom will be open for 5 minute lightning talks. The CfP for this will open shortly before the event and close 90 minutes before the session starts.