Staff Software Engineer

Go has traditionally required manual instrumentation — but that's changing fast. This talk surveys every practical strategy for instrumenting Go applications without touching a single line of source code: eBPF-based agents, compile-time rewriting, shared-library injection, and USDT probes. We'll compare what's production-ready today in OpenTelemetry and the broader ecosystem, benchmark each approach for overhead and stability, and look ahead at how plausible Go runtime features could make zero-touch observability even more powerful. You'll leave with a clear framework for choosing the right approach for your services.

How to Instrument Go Without Changing a Single Line of Code

Distinguished Engineer

Refactoring is one of the most powerful tools we have as engineers: the ability to reshape a codebase without altering its behaviour. Done well, it unlocks maintainability, extensibility, and long-term velocity. Done poorly, it introduces subtle regressions that can surface as production incidents weeks later.
So how do we refactor with confidence? Especially when changes are non-trivial or assisted by AI systems that optimize for plausibility over correctness. In this talk we’ll explore a tool-driven approach to safe refactoring in Go. 


Build your own tools to Refactor Go Safely

Developer, software architect, and application security researcher

Go is an appealing choice machine learning projects, with a fast, efficient systems programming approach and a mature concurrency model. Integrating Go with CUDA for GPU programming allows developers to connect conventional software with bespoke AI/ML tooling.

In this talk, a real example project will be used to explore that journey. Join us as we solve word puzzles with Go code, design a machine learning model from scratch in CUDA, and connect the two via cgo to train our model with synthetic data.

Using a concrete case study, the talk will show how Go can handle orchestration, data generation, and evaluation - calling CUDA code inline to take over the performance-critical work of running and training our model. We will look closely at the components and architecture of a custom-built ML model, and the engineering boundary between on-host Go code and on-device GPU workloads in CUDA.

Along the way, the talk will cover practical lessons from building a mixed Go/CUDA project from scratch - including code structure, profiling with NVIDIA’s tools, and the role that Go libraries in the machine learning space can play as the project evolves.

This isn't a how-to guide on running a popular Python library or using the latest cloud tools. But if you want to look at the nuts and bolts of how Go and CUDA combine to build and train a custom neural net from scratch, join us as we move from Go to the GPU.

From Go to the GPU: Integrating Go with CUDA

Staff Systems Engineer

In high-performance Go programming, the most significant bottleneck is rarely the algorithm, but the contract defined by the public API. Using the development of a high-speed, streaming JSON parser as a case study, I demonstrate how traditional, convenience-first interfaces—like Go’s standard encoding/json—impose an "allocation tax" that no amount of micro-optimisation can overcome.

This talk explores the fundamental link between API design and runtime efficiency, proving that true performance begins with the signature of your functions. By shifting the design philosophy from caller-owned data to a sliding-window, provider-owned model, we can architect libraries that are fast by default.

API Design as a Performance Primitive: Lessons from a High-Performance JSON Parser

Senior Software Engineer

'Why did you waste two hours on that? AI would have done it in ten minutes.' Sound familiar?

Something is changing in the tech industry. Engineers who once fell in love with the craft of software development are increasingly feeling like passengers in their own codebases. There is growing pressure to ship faster, skip deeper understanding and let AI handle more of the implementation. Over time, this can quietly erode the sense of ownership and satisfaction that draws many people into tech in the first place.

This keynote will look at how this change is affecting our drive at work and what we can do to protect our passion for engineering. We'll look at some practical ways to help you keep the spark alive and maintain a sense of pride in your work in a world where writing code is no longer the primary activity.

How to Stay Passionate in Tech in the Age of AI

Principal Engineer

Six months ago I was sceptical of the AI froth. The hyperbole was as off-putting as the actual results — autocomplete was useful, sure, but hardly game-changing. Then something shifted. The chatter got more grounded. Conversations with friends turned to outcomes. An opportunity arose to focus on AI for a few weeks and see how far we could push it. That turned into a high-pressure, high-stakes deliverable for a critical business deal. We went from dipping a toe to diving off the high board — from building toys to shipping production Go in front of customers. This keynote is the honest account of that stretch: how we adapted, what we got wrong, and the lessons we're still learning.

From AI Sceptic to AI Sceptic Who Ships

Compiler internals have a reputation for being intimidating — a black box that only a handful of experts truly understand. But the Go compiler and runtime source code tells a different story: large parts of it are clean, well-structured, and genuinely accessible to any curious Go developer.
In this tutorial, we'll explore the Go source code from the inside out. Through exercises, you'll build Go from scratch, modify the lexer and parser to introduce new syntax, customize compiler passes and tooling, and alter runtime behavior — including the goroutine scheduler and select statement randomization.
You'll leave with your own custom-built Go compiler, a better understanding of how language internals fit together, and the confidence to keep exploring, or even contribute upstream.

Having fun with the go source code

Technical Lead

Python is excellent for experimentation, but when it’s time to ship AI agents to production, you need the performance, concurrency, and type safety of Go.
​In this hands-on workshop, we will abandon the Python notebooks and build a robust, autonomous AI Agent from scratch using Go. We won’t just be making API calls; we will architect a system capable of reasoning, planning, and executing tools safely.

Zero to Binary: Building a Production-Ready AI Agent in Go

My dashcam records road trips as hundreds of 1 minute MP4 clips. A recent 9 hour road trip across Western Canada produced 540 tiny files totalling over 100GB and inspired me to create a timelapse video. That’s far too many clips for any video editor to handle so I built a tool in Go to turn them into timelapses automatically.

This started as a simple ffmpeg wrapper but after some nerding away it turned into a real world coding problem: I needed to validate all 540 video files, detect trip boundaries from the metadata, and orchestrate a multi-stage processing pipeline, ideally without taking a full 30 minutes to run.  

Join me to see how I built a concurrent pipeline in Go, starting from “the dumbest thing that worked” and using goroutines, worker pools, and channels to build one step at a time. A fun pet project with practical reusable patterns for building concurrent pipelines in Go, and maybe an idea for your next road trip.

Dashcam to Timelapse: Building a Concurrent Video Pipeline in Go

Managing Partner

In this talk Bill will introduce Kronk, a new SDK that allows you to write AI based Go apps without the need of a model server. If you have Apple Metal (Mac), CUDA (NVIDIA), or Vulkan, Kronk can tap into that GPU power instead of grinding through the work on the CPU alone.

To dog food the SDK, Bill wrote a model server (KMS) that is optimized to run your local AI workloads with performance in mind. During the talk, Bill will use KMS, OpenCode, and the Gemma4 model to write a simple tic-tac-toe game. Then bill will refactor that tic-tac-toe game and integrate Kronk to be Player2. After this talk you will know how to leverage Kronk in your own applications.

Kronk: Hardware accelerated local inference

Staff Engineer

As the trend to build more and more powerful AI experiences progresses, it's becoming increasingly important to build platforms in a way that LLMs can use.

Whilst REST APIs are great for Javascript clients, LLM's struggle with their PUTs and POSTs, not to mention handling trailing commas in JSON!

Needless to say, in order to make a platform truly AI-native, a traditional HTTP API is not enough. With MCP emerging as the new standard for interoperating LLMs with external systems, software teams are now faced with the challenge to rapidly evolve their existing systems to be MCP-compatible.

At Typeform, we're on this journey. We're building towards a future where MCP compliments our existing REST API, and we're trying to do this sustainably, securely, and reliably.

In this talk, I'll share the architectural patterns we using to achieve this, as well as some real life examples of our we're making MCP our new API.


MCP is the new REST: making MCP Typeform's new API

Software Engineer

As a backend engineer, I always found myself struggling to build a full-stack web application on my own. I seemed to always get lost, in the JavaScript ecosystem. Or even simple things like how to structure a more complicated application.

So when I learnt about HTMX, I decided to give it a go (no pun intended ;) ). So I tried to build a Web app without needing to write any (or very little JavaScript) and see how far I could get.

In the end, I had a joyful developer experience building an app with Go, HTMX, templ, tailwindcss and Postgres, KISS - keep it simple stupid.


What I learnt building a web app with Go and HTMX

Freelance Reality Consultant

Like many hackers from the 80s I started coding in my bedroom with the limited BASIC and operating system which could be crammed into 16KB of ROM on an 8-bit Home Micro. Computer Science wasn't on our radar, and we learned our craft by typing in listings from magazines and books, writing dumb little programs that amused us, and figuring out how to hack save games or bypass the copy protection on the compact cassettes traded in the playground. What started as a hobby became a decades long career.

The world has changed a lot since then, and CompSci is now a standard part of the school curriculum. A standard, tedious, academic imposition on a generation surrounded by locked down consumer electronics. But those save games still need hacking, and no matter how turgid the school curriculum, inquisitive minds still want to know how the machine works. Why the machine works.

My son dislikes programming. Or at least he thinks he does. School tried to teach him python but it didn't stick. Instead he rewrote the JavaScript for their web pages, found creative ways to bypass their network blockades, got linux working on the locked down chromebook in the library.

Can learning Go change his mind about programming? And if so, just how deep down the CompSci rabbit hole can we go with just a text editor, the standard packages, and a little misapplication?

How much CompSci can Go teach?

Senior Developer Relations Engineer 

In this session we are going to learn how to use Gemini family of models to build your own 2D game from scratch. From code, to assets and even music, everything will be AI generated. We will be using Ebitengine for our game engine, a coding agent and GoDoctor for code generation, Nano Banana for assets / sprites and Lyria for music generation. A reference implementation of a match-3 arcade game will be provided for those who want a guided path, but you will be free to make your own creations using the proposed tools. At the end of this session you will have learned:
- How to improve coding agents responses with skills, hooks, MCP tools and sub-agents
- How to prompt Nano Banana to generate high quality assets
- How to prompt Lyria to generate music
- How to deploy your finished game to the cloud using Google Cloud Run

Vibe Code a 2D Game with Gemini and Go

Master explainer

Set theory is closely related to Boolean logic and databases. In practice, set operations can dramatically simplify code, replacing complex nested loops and ifs with declarative expressions that are easier to read and may offer better performance. That's why most popular, modern languages provide sets in their standard libraries, but not yet Go. In this talk I show how set operations simplify common programming tasks, and how to implement a generic set type in modern Go.

Sets in modern Go

When we want to know why our Go programs are slow, we reach for the built-in pprof tool.  Pprof tells you where in your code your CPU time is spent, but not why the CPU is slow. Deep inside the silicon, there are many bottlenecks — cache misses, branch mispredictions, and pipeline stalls — which are invisible to pprof yet can dominate real-world performance.

But did you know that modern CPUs have built-in hardware that can give you that visibility? Performance Monitoring Units (PMUs), accessed via the Linux perf subsystem, can give you an amazingly detailed view of how the system is performing.

In this talk, we'll start with what PMUs are and why they matter, then live-demo a new tool called perfgo, which translates the low-level data into pprof format. We'll walk through a concrete production win at Grafana Labs, where dTLB cache miss counters from perfgo guided us to enable huge pages on our Kubernetes clusters — a change that would have been invisible with pprof alone.

You'll leave with a practical understanding of hardware performance counters, a new tool in your optimisation toolkit, and the intuition for when pprof isn't enough.

Beyond pprof: Bringing Hardware Performance Counters to Go

Production Engineer

It's 2 AM. A downstream dependency has tripled its P95 latency. Your service is shedding requests and the on-call page is going off. The fix is embarrassingly simple: a timeout tweak, maybe a fallback. The deploy pipeline is not: CI, review, staging, rollout. Forty-five minutes if you're lucky. By the time the fix lands, the incident is already a postmortem. This bothered me enough to do something about it.

I built a small, embeddable engine in Go that lets you push runtime behaviour changes (timeouts, fallbacks, traffic gates, request transformations) as declarative policies, evaluated at request time. Simple conditions use CEL (Common Expression Language). Complex logic runs in sandboxed WASM modules via wazero. No sidecars, no service mesh, no restart. Just a small engine with a single dependency.
                                                                                                                             
The interesting part isn't the engine itself. It's the problems you hit once you start patching production behaviour on the fly. How do you avoid breaking everything? Canary rollouts with consistent hashing, so the same users stay in the same bucket. Tenant and region targeting, so you can scope a change to exactly who needs it. Traffic recording and replay, so you can test a policy against real requests before anyone sees it. Auto-rollback driven by metrics, for when you mess up anyway.
                                                                                                                      
I'll walk through the design, the trade-offs, and a live demo. You'll leave with a pattern you can implement in your own Go services. Or just steal the code.

Live Patching Production Go Services with CEL and WASM

Configuration-heavy systems often drift into two definitions of “valid”: one at the boundary, and another hidden in the runtime. This talk shows how we removed that split in Skipper-Ingress, Zalando’s open-source ingress controller, by reusing runtime routing validation in a Kubernetes admission webhook.

It covers the Go design that made this possible, reusable validation APIs, composable validators, and safe rollout patterns, turning late routing failures into fast feedback at deploy time.

One Definition of Valid: Reusing Runtime Routing Logic at Apply Time in Go

Go is a powerful language, bringing incredible developer productivity to innumerable projects and systems. However it is normally assumed that interaction is through a command line or web browser. What if you could be using Go as an app on your laptop? What if the entire desktop was written with Go?

In this talk I show how the FyneDesk project and FyshOS distribution make that a reality. We cover design and architecture including technical details about how Go is a great fit for this problem. The presentation includes beautiful visuals of the desktop and various applications, and ends with compelling call-to-action to inspire others to try building their native apps with Go!

Creating a full desktop environment with Go!

Senior Staff Engineer - Competency Lead

I started Bramfield Trading Company to answer a question: what’s actually possible when AI helps you build a trading company — and then becomes part of the decision-making inside it?

The company trades only my own capital, which makes every architectural decision real. In this talk, I’ll walk through how models move from research to production: Python for training, ONNX for portability, and Go for live inference in a system where roughly 90% of the production platform is written in Go.

I’ll cover how classical ML and CNN-based models are deployed into a 24/7 trading stack, and how LLMs are used in the live decision loop for go/no-go trade decisions and order sizing — all under one hard rule:

No manual trading allowed.