1. 10,000 Requests per Second with One Go Service

Abstract

Description

Scaling systems often leads teams toward complicated architectures. More services, more infrastructure, and more operational overhead.

Yet many high throughput systems can handle enormous load with surprisingly small designs.

This talk walks through how to build a Go service capable of handling 10,000 requests per second while remaining understandable and easy to operate.

We will examine the decisions that actually matter for performance:

• Efficient request handling patterns • Memory allocation strategies • Connection management • Practical profiling and bottleneck discovery

Using a benchmark harness, we will watch a simple Go service evolve step by step until it reaches high throughput while maintaining stable latency.

The goal is to show that performance is often the result of thoughtful design rather than complexity.

Notes

Some recordings from my previous conference talks:

React India 2025 [REDACTED]

React Kolkata [REDACTED]

I have also delivered talks at DevFests, CityJS World Series, and several developer conferences and community meetups internationally.

This talk includes a live performance demonstration that gradually evolves a simple Go service into a high throughput system capable of handling very high request rates while maintaining stable latency.

The focus is on practical engineering decisions rather than complex infrastructure.

No special assistance required.

^ back to index

2. 150% faster crypto/chacha20 with Go assembly code

Abstract

Description

The ChaCha20 stream cipher is the backbone of modern TLS traffic, SSH connections, and countless embedded systems. While its simplicity (using only XOR, addition, and rotation) makes it ideal for software implementation, its performance can be a bottleneck—especially on RISC-V platforms without dedicated cryptographic accelerators.

This session dives into the black art of accelerating ChaCha20 using the RISC-V Vector (RVV) extension. We will move beyond theoretical SIMD concepts and explore a real-world implementation that achieves a 150% performance gain on a cheap RISC-V SBC (Banana Pi F3 RVV 1.0, VLEN=256).

We will start with a brief refresher on the ChaCha20 quarter round and matrix layout, then dissect the specific challenges of vectorizing this algorithm:

1. Solving the Matrix Puzzle: How to use segmented load instructions (like vlseg4e32.v) to transpose the 4x4 state matrix directly from memory with zero step stride.

2. Handling Rotations: Managing the lack of dedicated vector rotation instructions in base RVV and how the upcoming Zvkb (Vector Crypto Bit-manipulation) extension will cut critical path latency by 66%.

3. Scalable Throughput: Demonstrating how RVV’s length-agnostic programming model allows the same binary to process 4 blocks on one core and 8 blocks on another, automatically scaling with future hardware.

Finally, we will review benchmark data from the upstream Go crypto library patch and discuss the current state of SIMD support in high-level languages.

Attendees will leave with a concrete understanding of how to think in vectors, optimize memory access patterns for cryptography, and future-proof their code for the next generation of RISC-V hardware.

Notes

1. None
2. None
3. None (but I submit to GopherCon EU, too)
4. No
5. This talk based on a CL of mine [REDACTED]

^ back to index

3. Beyond the Graph: The Memory Physics Behind Go’s Garbage Collector

Abstract

Description

When Go developers think about garbage collection, they usually imagine graphs of objects connected by pointers. The runtime walks these graphs, marks reachable objects, and reclaims the rest.

But on modern hardware the real cost is not the algorithm. The real cost is memory.

As heap sizes grow into tens or hundreds of gigabytes, garbage collection performance is increasingly dominated by cache misses and memory latency. Traversing object graphs often means jumping between distant memory locations, forcing the CPU to wait hundreds of cycles for data to arrive.

This talk examines Go’s garbage collector from a hardware perspective.

Instead of focusing only on algorithms, we will look at how memory layout, pointer density, and data locality influence the cost of GC scanning. Small structural changes in how data is organized can dramatically change how efficiently the collector runs.

We will explore:

• Why pointer chasing becomes expensive on modern CPUs • How Go’s heap layout and span system affect scanning behavior • How cache locality influences GC throughput • Why some data structures are far more GC friendly than others

Using real benchmarks from high allocation Go services, we will demonstrate how improving memory locality can significantly reduce GC overhead and tail latency without changing application logic.

The talk concludes with practical design guidelines for building Go systems that cooperate with the runtime instead of fighting it.

Attendees will leave with a deeper mental model of how Go’s garbage collector interacts with modern hardware and how small data structure choices can produce surprisingly large performance improvements.

Outline

The memory wall: why memory latency dominates modern systems Pointer chasing and cache misses inside Go heaps How Go organizes memory using spans and size classes How object layout affects GC scanning cost Benchmarking GC behavior in high allocation workloads Practical data structure patterns that improve locality

Notes

Recordings of some of my previous conference talks:

React India 2025 [REDACTED]

React Kolkata [REDACTED]

I have also spoken at DevFests, CityJS World Series, and other international developer conferences and community meetups.

This talk is based on practical experience working with high throughput backend systems and performance sensitive infrastructure where GC behavior becomes visible at large heap sizes.

The session includes benchmarks and runtime analysis tools that engineers can use to observe memory behavior in their own services.

No special assistance required. I will attend the conference in person.

^ back to index

4. Bridging the Context Gap: Modern Go for Tools and Agents

Abstract

Description

Introduction

While pkg.go.dev (pkgsite) provides an excellent web experience, programmatic access is currently fragmented. CLI tools like go doc often rely on local source or limited proxies, while external tools are forced into unreliable web scraping. This creates a “context gap” that limits the precision of our developer tools and the effectiveness of modern AI agents.

Outline

• The Dual Interface Strategy: Why we decoupled the REST API from the MCP interface to serve both high-throughput services and token-constrained LLMs.
• REST API Design for the Ecosystem: Exploring how to design APIs that satisfy high-impact community needs, such as discovering package importers and providing structured, programmatic search results.
• Engineering for AI (MCP): Implementing the Model Context Protocol as a “universal adapter” for Go. We’ll discuss how providing standardized access to package metadata allows agents to retrieve critical information “just-in-time”.
• Patterns for Reliable AI Tooling: Designing interfaces that prioritize clarity and reliability for machine-driven workflows, ensuring that agents can consistently and accurately interact with the Go ecosystem.
• Security and Reliability: Integrating vulndb to help agents choose trustworthy dependencies and operational lessons from optimizing Pkgsite’s backend to eliminate ingestion backlogs and improve service reliability.

Conclusion

By providing stable, machine-readable endpoints, we are enabling a new generation of Go tooling. Attendees will leave with a blueprint for how IDE integrations and autonomous agents can finally reason about the Go ecosystem with the precision it deserves.

Notes

^ back to index

5. Build Your Own USB HID Keyboard with TinyGo (Live Coding)

Abstract

Description

Go is widely known for cloud services and backend systems — but it can also run on real hardware.

TinyGo is a Go compiler for microcontrollers and small devices, allowing you to write firmware in pure Go. In this talk, I’ll demonstrate how to build a USB HID keyboard using TinyGo and explain how Go code becomes firmware running directly on a microcontroller.

The core of the session is a short live-coding demo. In a short live-coding session, we’ll build a minimal keyboard firmware with layer support, step by step:

Send a single key press and release after time.Sleep()

Read a physical button and send key events (including key repeat)

Expand from one button to multiple hard-coded buttons

Refactor the buttons into a slice for scalability

Add a simple layer feature that changes key behavior while a modifier button is held

Along the way, we’ll briefly explore how USB HID works, how TinyGo targets microcontrollers, and how to structure embedded firmware in Go.

This session is accessible even if you have no prior embedded systems experience. If you know Go, you already have everything you need to get started.

Attendees will leave with:

A clear understanding of how TinyGo runs on microcontrollers

Practical knowledge of USB HID basics

A mental model for structuring firmware in Go

The confidence to start building hardware projects with Go

If you’ve ever wondered whether Go belongs beyond the cloud, this session will give you a concrete, hands-on answer.

Notes

I am the author of [REDACTED], a USB HID keyboard firmware implementation written from scratch in TinyGo.

I have been deeply involved in TinyGo’s USB and USB HID implementation, contributing to and working closely with the lower-level USB stack. The live demo in this session is based on real-world firmware used in our hands-on keyboard workshops.

You can find related materials here:

GitHub repositories

• [REDACTED]
• [REDACTED]
• [REDACTED]

TinyGo USB-related contributions

• [REDACTED]

Technical blog post

• [REDACTED]

This talk is based on a session previously delivered to a technical audience and refined through real-world workshops, combining both implementation depth and practical teaching experience.

Risk Management for Live Demo:

To ensure a smooth experience regardless of hardware or connection issues, I will prepare a pre-recorded video of the entire live-coding sequence as a backup. I have delivered similar live-demo sessions at local meetups and conferences with high success.

^ back to index

6. Building Open Infra for AI Agents with Go

Abstract

Description

AI agents are emerging as a new paradigm for building intelligent systems. While many agent frameworks focus on prompt orchestration and model interaction, real-world deployments require robust infrastructure to manage task execution, tool integration, and system reliability.

This talk explores how Go can be used to build the infrastructure layer for AI agent systems. We examine how Go’s concurrency primitives including goroutines, channels, and worker pools enable efficient execution of agent tasks such as tool calls, API interactions, and asynchronous workflows.

The session also discusses architectural patterns for agent infrastructure, including task queues, event-driven services, and distributed workers running alongside containerized workloads. By leveraging open-source infrastructure platforms, developers can build scalable and transparent agent systems that integrate with modern cloud-native environments.

Attendees will learn practical design patterns for building reliable AI agent infrastructure using Go and open-source technologies.

Notes

[REDACTED]

Let me know if travel support can’t be provided, this should not hinder me from participating.

^ back to index

7. Choosing the Smallest LLM That Won’t Completely Fail You

Abstract

Description

You’ll learn how to build a framework in Go that leverages Docker’s Model Runner as inference engine to automatically spin up SLMs, run controlled evaluation scenarios, and collect observability metrics. We’ll define an Evaluator Agent that executes a battery of standard prompts across multiple models, an approach that helps you understand performance, accuracy, and resource trade-offs in practical developer setups.

We’ll move from building a reusable evaluation harness to defining and orchestrating prompts as tests for different models. You’ll see how to instrument Go benchmarks with metrics and traces to visualize behavior instantly and make informed decisions. And of course, you’ll walk away with practical insights on selecting the smallest model that won’t fail you.

By the end, you’ll have a repeatable approach for testing and comparing language models.

Warm up your GPUs, but less than you think.

Notes

^ back to index

8. Concurrency + Testing = testing/synctest

Abstract

It’s time to put your concurrency skills to the test with testing/synctest!

The testing/synctest package that was introduced into Go 1.25 has only two functions, but unlocks a wide range of tests that you can now write for your concurrent code, packed with time travel. Let’s explore it together.

Description

Go 1.25 introduced testing/synctest, a package that brings more 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, manipulate time passing, wait for goroutines to run, 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, including converting common intermittently failing tests into deterministic tests, 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 testing/synctest brings to Go—and how you can start using it today.

Notes

^ back to index

9. Creating a full desktop environment with Go!

Abstract

Go is super powerful, boosting productivity for many projects and systems. However it is normally used to build CLI/backend or web sites. What if you could be using Go as an app on your laptop? What if the entire desktop was written with Go?

Start here if you’ve ever dreamed of building a desktop!

Description

In this talk I show how the Fyne Desk project and FyshOS distribution make that a reality.

Setting the scene - 2min

The complexities of building a desktop environment - all the things involved in delivering such an ambition. Also covering the background on why we would do this with Go and how it has been a great fit.

Technologies and Architecture - 2min

This section shows the components and responsibilities in a graphical linux desktop. This is currently X11 based and so will cover the client/server nature of apps, the desktop (login) manager and how the graphics are made available.

As a refresher for anyone not familiar this will also cover responsibilities of the compositor, app switcher and virtual desktop components of a window manager.

Implementation of the basics - 7min

This is the main technical (code) section of the talk, covering implementation details and how Go modules and projects are set up to collaborate and connect to system services.

Here we look in detail at the APIs and design decisions that come together to deliver such a large project. The main areas of interest are:

• X11 server
• Window manager
• Desktop and widget arrangement
• App / launch / icon handling
• Graphical compositor

Rather than going into serious detail this section will be technical but at an overview level - the main API and code location for people to what to dig in further.

Integrations - 3min

A good desktop experience depends on the features and system integrations to do all that users expect of their environment.

This section covers standard features like notifications and system tray. I will also show more advanced integrations like login and authentication manage.

Lastly this section covers extension points so that third party apps and features can also integrate.

App suite for our desktop - 4min

A quick flick through the tools that make a desktop complete - covering:

• system management (screens, wifi)
• utility apps (textedit, terminal, file manager, colour picker)
• productivity (presentation, app editor)
• plus games of course!

Try it out and contribute - 2min

In this call to action section the audience will be wowed by some very lovely screenshots of the full desktop (transparency, features etc).

Following that the basic instructions on getting started and trying out the main aspects of the project will be shared. As well as just testing it out, the audience will be shown how they could contribute to the project and help to deliver a complete Go based desktop environment they deserve :).

Notes

I have spoken at many conferences (GopherCon, GopherCon UK, GoLab, FOSDEM) - more info on topics and videos are at [REDACTED] The talk proposed above has not been presented at any other locations.

The presentation could be extended to cover more detail in a longer slot. I would also be happy to present a “Building graphical apps with Go” workshop, similar to what I have previously delivered at GoLab. Travel support would be appreciated, but I could make it there without.

^ back to index

10. Debugging the Black Box: How Spinbit Mutex Exposed Our Code in the Go Upgrade Cycle

Abstract

Description

In a modern, modular Go environment, version upgrades are no longer simple patch releases—they are high-stakes technical and organizational challenges. This talk delivers a comprehensive Upgrade Playbook providing a blueprint for safe, predictable adoption of future Go version lifecycles.

This playbook is essential, as demonstrated by recent issues like the severe P99 tail-latency regressions experienced after upgrading to Go 1.24. In that case, the new “spinbit mutex” amplified pre-existing cross-request interference.

What You Will Learn (The Upgrade Playbook): Mastering the New Reality (Process): Strategies for addressing non-technical challenges: Coping with the loss of shadow builds and reliable rollbacks. Managing dependency chain breakage where MVS forces a toolchain upgrade. The Spinbit Crisis (Case Study & Technical Fixes): Our deep dive into the Go 1.24 incident: Diagnosis and Mitigation: How we isolated the P99 spike to the spinbit mutex, used the immediate GOEXPERIMENT opt-out. The Root Cause (Technical): How global synchronization primitives (like sync.WaitGroup and global sync.Mutex) created the cross-request interference exposed by the new runtime. This is a must-attend for any engineer managing latency-sensitive Go services in a large-scale environment. Learn from our crisis to establish the strategic process and technical discipline necessary to ensure smooth, predictable Go upgrades.

Notes

^ back to index

11. Don’t let One Goroutine burn the house down: Graceful Panic Recovery in Go

Abstract

Description

In the world of Go, goroutines are cheap and powerful but they can also become the hidden danger. An unhandled panic in a background goroutine doesn’t just fail that task, it brings down your entire application. While Go’s recover() is the built-in safety net, managing it across hundreds of goroutines leads to boilerplate, lost stack traces, and blind failures where you know something crashed but don’t know why.

This session explores the patterns for building resilient Go services that handle failures gracefully. Using the design philosophy of the go-recovery library as a case study, we will dive into:

• The anatomy of a panic and why standard recover() often isn’t enough for production.
• How to implement a “Safe Go” wrapper that preserves stack traces and integrates with modern structured logging (slog and zap).
• Using Contextual Metadata to make panics actionable, passing transaction IDs or user data into recovery handlers to allow for precise cleanup and alerting.
• Design patterns for custom recovery handlers: When to retry, when to shut down, and how to close resources (DB connections, sockets) when the unthinkable happens.

Notes

^ back to index

12. Durable Executions - Primitives to Design Patterns

Abstract

Description

Modern distributed systems fail in unpredictable ways, e.g. process crashes, network partitions, invalid data, timeouts, and partial completions. What if reliability wasn’t something you stitched together with queues, retries, cron jobs, and compensating scripts — but something built into your execution model?

In this talk, we explore Durable Execution as a foundational approach to building crash-proof, long-running workflows. You’ll learn how core durable primitives—such as Activities, Workflows, Timers, and Signals—turn application state into something inherently persistent and replayable, enabling true crash recovery and consistency.

We’ll then move beyond primitives into real-world design patterns, including time-boxed approvals, resumable activities, and Saga-based compensations. Through practical examples and a live demo, you’ll see how these patterns simplify complex coordination logic while preserving correctness under failure.

If you build distributed systems, this session will reshape how you think about reliability.

Notes

^ back to index

13. Error Tracing in Go: Lessons Learned from the Trenches

Abstract

Description

Notes

^ back to index

14. Extending sqlc: augmented generation of repositories and integration tests

Abstract

Description

This talk explores a practical approach to bridging the gap between sqlc (SQL compiler)’s generated code and a clean service architecture in Go. Sqlc provides type-safe, compile-time checked access to the database. However, using sqlc generated structs directly in the service layer risks coupling domain logic too tightly to the database schema. To address this, we still would like to have a repository layer — one that accepts/returns domain entities, not sqlc-generated records, and that can orchestrate transactions across multiple operations.

Rather than hand-writing boilerplate repositories for every entity, this talks proposes using augmented code generation (for example, with Claude Code) to build them. In this approach, repository methods delegate to one or more sqlc-generated queries, and when needed, wrap these calls in transactions. This preserves sqlc’s benefits — strong typing and compile-time guarantees — while adding a repository abstraction that returns domain entities, keeps the service layer free of database concerns, and centralizes transaction orchestration. By grounding the generation in a reference implementation, we also reduce the risk of LLM hallucinations or stylistic drift, ensuring the produced repositories stay consistent and predictable across entities.

Test generation follows the same augmented approach. Starting from the repository interface, tests are generated before the repository implementation itself. This allows Claude Code (or another LLM) to execute the tests against the generated repository and iteratively refine the implementation until all tests pass. The generated tests adhere to the reference example’s patterns: they use table-driven design, testify/suite for structure, Testcontainers for isolated database environments, gofakeit for realistic random data, and go-cmp for deep comparisons.

In summary, this approach combines the best of both worlds: the type safety and compile-time guarantees of sqlc with a clean, domain-focused repository layer that handles transactions and isolates the service layer from database details. By leveraging augmented code generation guided by reference implementations, we can automate the creation of both repositories and their tests, reduce repetitive boilerplate, and ensure consistency, reliability, and maintainability across the codebase.

Notes

^ back to index

15. Fixing a 15-Year-Old JPEG Bug in Go

Abstract

Description

Go’s image/jpeg package has long rejected certain valid JPEG images with the error “unsupported luma/chroma subsampling ratio”. The issue dates back over 15 years and affects images using non-standard YCbCr subsampling, such as those using different sampling factors for Cb and Cr, or a Y component without the maximum sampling factor.

In this lightning talk, I’ll explain why these images are valid according to the JPEG spec, and why Go rejected them for so long. I’ll walk through my solution: a “flex mode” decoder that handles arbitrary subsampling by decoding into a YCbCr444 backing buffer and manually expanding pixels based on each component’s sampling factors.

Outline:

1. The bug (1 min)

• The error message everyone has seen
• Real-world images that trigger it

2. Why these JPEGs are valid (1 min)

• Quick primer on YCbCr subsampling
• What the JPEG spec actually allows vs. what Go assumed

3. Why the fix took 15 years (1 min)

• The original decoder’s assumptions
• Why naive fixes break performance or correctness

4. The solution (2 min)

• Decode to YCbCr444, expand manually
• Trade-offs and edge cases

Links:

https://go-review.googlesource.com/c/go/+/738280

Notes

I previously presented at Go Conference 2025 (Japan): [REDACTED]

For travel, I plan to seek sponsorship from my employer, but I may need additional support depending on the circumstances.

^ back to index

16. Flight Recorder: Go's Black Box for Production

Abstract

Description

Main idea: FlightRecorder continuously traces execution into a circular buffer with 1-2% overhead. When something interesting happens (slow request, error spike), you snapshot the buffer. The cause is already captured—no need to reproduce or predict when to start tracing.

Questions this talk answers:

Why can’t pprof explain latency? pprof samples what’s currently running on CPU. A goroutine blocked on a slow database call isn’t running—it’s invisible. pprof shows the CPU is idle. FlightRecorder captures blocking events, mutex contention, syscalls, and goroutine state changes—everything needed to understand where time went.

What’s the overhead? 1-2% CPU overhead when recording. The runtime already collects most trace events; FlightRecorder just keeps them in a ring buffer rather than discarding them. Writes are batched and occur on dedicated goroutines to minimize latency impact.

What are MinAge and MaxBytes? MinAge says “try to keep at least this much history” (e.g., 30 seconds). MaxBytes says “but don’t use more than this much memory” (e.g., 50MB). These are hints—the runtime balances them based on event rate. High-frequency events fill the buffer faster.

Why only one FlightRecorder per process? The trace infrastructure is process-global. Multiple recorders would need to coordinate buffer management and could interfere with each other. The limitation simplifies the implementation and avoids subtle bugs.

When should I snapshot? When request latency exceeds P99 threshold. When error rate spikes. When anomaly detection fires. Via a ‘/debug/snapshot’ endpoint for manual investigation. The key insight: snapshot after detecting the problem, not before.

*Benefits for listeners: Attendees will know how to integrate FlightRecorder into production services, configure it appropriately (trading history length vs. memory), implement automatic snapshot triggers, and analyze traces with ‘go tool trace’. The talk includes production patterns from real deployments.

This talk is currently proposed as intermediate level, but I’m open to adapting the depth if it benefits the conference.

Notes

blog: [REDACTED]

From a few 2025 events: Golab: [REDACTED] (videos are not online yet) Golang X Conf: [REDACTED] Gophercon India: [REDACTED] GopherCon Africa: [REDACTED] (videos are not online yet) Keynote of GopherCon LATAM (Portuguese): [REDACTED]

^ back to index

17. From Bytes to BigInts: Accelerating Go on IBM Z with Memory and Crypto Optimizations

Abstract

Description

From memory primitives to Montgomery multiplication, this talk explores how low-level optimizations can significantly improve Go’s performance on IBM Z.

Core runtime functions such as memclr and memmove sit on critical hot paths across allocation, garbage collection, and slice operations. Optimizing these primitives can have a broad impact across the entire Go ecosystem. This talk demonstrates how architecture-aware tuning and instruction-level improvements on s390x lead to substantial gains in memory throughput and runtime efficiency.

The second half dives into big-integer cryptography. By vectorizing Montgomery multiplication in Go’s crypto/internal big-number implementation, we achieve up to ~60% speedups in modular arithmetic operations—directly benefiting cryptographic workloads such as RSA.

Several of these optimizations have already been merged into the Go project, improving performance for Go workloads running on IBM Z systems.

Along the way, we’ll also discuss ongoing work to further improve Montgomery workloads in the common Go implementation, making these optimizations more broadly applicable beyond architecture-specific code.

Talk Outline:

1. How Go’s runtime and crypto internals rely on architecture-specific assembly routines
2. Techniques for vectorizing big-integer arithmetic on IBM Z
3. Optimizing core memory primitives (memclr and memmove) in assembly
4. Benchmarking methodology and real performance results

Takeaways: By the end of the talk, attendees will gain a deeper understanding of why Go provides architecture-specific implementations for critical routines and how these optimizations translate into real-world performance improvements. We’ll also touch on profiling tools, benchmarking techniques, and performance metrics that help developers reason about and improve the performance of their own Go applications.

Whether you’re a Go developer, performance engineer, or simply curious about what happens under the hood of the Go runtime, this talk provides practical insights into making Go faster on modern hardware.

Notes

Related blog posts: memclr and memmove optimizations on [REDACTED] Z: [REDACTED] (A follow-up blog on vectorizing Montgomery multiplication for Go’s big-integer crypto is currently in progress and will be published on the same [REDACTED] Community website.)

Previous presentations: I have presented these topics (memory routine optimizations and Montgomery multiplication improvements on [REDACTED] Z) at the Performance and Scale Meetup 2025: [REDACTED] LinkedIn post from the session: [REDACTED]

Additional context: The Montgomery multiplication improvements show ~60% performance gains in big-integer modular arithmetic on s390x. The memclr/memmove work targets core Go runtime hot paths (allocation, GC, slices), providing measurable improvements in real workloads.

Note: No special assistance required.

^ back to index

18. From TODO to OSS Contribution: How TinyGo Builds a Community That Keeps Going

Abstract

Description

I have worked as a project manager, engineering manager, backend engineer, and in operation design for sales organizations, but I have no professional experience in embedded systems development.

Despite that, I am involved in a hardware-oriented community called TinyGo Keeb, which includes both embedded systems experts and complete beginners. The organizers strongly care about giving newcomers hands-on experience and helping them enjoy the process.

Our community is far from perfect. In every workshop, participants tend to get stuck at the same points. While following the code with hints from community members, I found TODO comments and thought, “Maybe I can work on this myself.” That moment became my first OSS contribution.

In this session, starting from my first contribution to TinyGo, I explore how communities that encourage people to “just try it” lower the barrier to OSS, and how we can design beginner-friendly entry points in Go OSS—from both community practices and the codebase itself.

Notes

Talk Structure

Part 1: TODO Is Not Just a Technical Task, but an Entry Point

This challenge started from a problem repeatedly observed while running workshops: participants kept getting stuck at the same points.

In this part, I will talk about:

• The psychological barriers I felt before contributing to OSS, especially as someone outside the embedded systems domain
• How encouragement from the community transformed a TODO from “unfinished work” into an invitation to participate
• My first merge—and the reality that contribution does not end with a single PR

Part 2: How to Build and Sustain a Community

TinyGo Keeb includes both experts and non-experts, yet the community continues to grow.

In this part, I will share:

• How we create an atmosphere where beginners feel comfortable joining and trying
• How recurring workshop pain points are turned into shared learning assets
• How intentionally leaving OSS “unfinished” creates entry points for the next challengers

Audience Takeaways

• The first step into OSS starts not only with skills, but with having the right point of contact
• Communities last when momentum and fun are intentionally designed
• Unresolved work is not a failure—it can become the next entry point

Instead of thinking, “It’s too early for me,”
think, “Maybe I’ll try working on this TODO.”

“TODO” here refers not only to TODOs in code, but also to TODOs in community activities.

^ back to index

19. Functional options, a decade later

Abstract

Description

Why: 10 minutes on why an initialisation pattern is needed,

examples; public fields, impact on api design and implementation
pitfalls; leaking internal state, data races, silent corruption
anti patterns; APIs with many parameters

How: 10 minutes

Basic examples
    Binary flags 
    Options that take parameters
Handling defaults

Advanced examples and best practice: 5 mins

Options that take their own options

Notes

^ back to index

20. Fundamentals of Memory Management in Go: Learning Through the History

Abstract

Description

Notes

Here’s the outline of the session:

1. Introduction (3min)

   • Memory management (programming language): strategy to manage variable data in memory
   • Memory management is important for performance
     • Example case: one memory allocation change -> 57% reduction in CPU usage and 99% lower memory consumption
   • Sessions about memory management are difficult
     • Contain large technical details of logic and implementation techniques (“how”)
     • Lack of structured abstract interpretation of processing and understanding of needs (“what” and “why”)
   • To learn advanced Go memory concepts, we need to understand the basics of a broad range of functionalities
     • We can acquire this only by grasping the “what” and “why” of each functionality
     • Let’s focus on the “what” and “why”, not the “how”: the most efficient path from 0 to hero
   • Pre-requirement: what go provides
     • 2-phases: compiler and runtime

2. What memory is: Ancient memory management (1min)

   • Memory = temporary data storage for the process
     • App can use them as KV store
   • Direct data insertion to memory (data management of assembly)

3. Era of variables: the stack and the heap (4min)

   • (Pain) Programmers need to know all the addresses
   • High-level programming language arose
     • Variable: abstraction of data
     • Programmers don’t need to know the address, but language needs to manage them
   • Invention of the stack
     • The stack was perfect to represent the nested structure of function calls & variable scope on memory space
     • Illustrated explanation of the stack
   • Partial use of direct insertion: the heap and the pointer
     • For big / unknown-sized data
     • For data which is used across the functions
     • Illustrated explanation of the heap and the pointer
   • Pointers deep dive: illustrated explanation of pointer args vs value args

4. Automatic heap management: garbage collection (2min)

   • (Example) malloc & free function in C
   • (Pain) Programmers need to delete data in the heap when they are no longer in use
     • Risk of memory leak & OOM kill
   • Garbage collection (GC)
     • Mark: detection of unused data in the heap
     • Sweep: Deletion of them
     • Illustrated explanation of GC
   • Optimization of GC in Go
     • Concurrent GC, GC triggers, Green Tea
     • Pursues simple logic

5. Heap escaping in Go (5min)

   • (Pain) Placing many data in the heap = high GC cost
     • (Example) Putting all non-primitives in heap -> over half of the variables are GC target
   • Heap escaping
     • Put as much data in the stack as possible
     • Put necessary data in a heap, types don’t matter
   • Heap escape analysis & membench
     • Heap escaping is mostly determined by the compiler, runtime also has some influence
     • A build option to show variable analysis log
     • We can see actual allocation result with membench
   • The structure of heap
     • Objects with the same size are grouped in span
     • Spans are grouped in bigger groups…
   • Zero-allocation libraries
     • Package that no data escapes to the heap in its functions
     • Efficient, basically increases performance
     • Sometimes it slows down performance, measure the impact before using

6. Flexible stack with stack copying (4min)

   • (Pain) The stack sometimes has a limit = stack overflow happens
   • Preparing a huge stack may be good…
   • (Pain) Always having a huge stack = a small amount of heap, which is also inconvenient
   • Flexible-sized stack = efficient memory usage
     • Segmented stacks (old implementation)
     • Stack copying (current implementation)
   • Illustrated explanation of stack copying
   • Does Go have stack overflow?
     • Yes, but it’s rare
     • Stacks are flexible, but they have a limit

7. Explanation of the example case in the introduction (3min)

   • cf. <[REDACTED] (written in Japanese)
   • Filtering function makes one slice in the heap every time it is called
     • This escaped variable was the bottleneck

   type targetList []any
   
   func (list targetList) Filter(match func(any) bool) targetList {
     filtered := make(targetList, 0, len(list)) // The bottleneck
     for _, e := range list {
       if match(e) {
         filtered = append(filtered, e)
       }
     }
     return filtered
   }
   

   • Deleting allocation by updating the existing slice

   type targetList []any
   
   func (list targetList) Filter(match func(any) bool) targetList {
     n := 0
     for _, e := range list {
       if match(e) {
         list[n] = e
         n++
       }
     }
     list = list[:n]
     return list
   }
   

   • 99% lower memory consumption
     • Shows how one allocation in a common function affects the performance
   • 57% reduction in CPU usage
     • The reduction of allocation & GC CPU usage combined

8. Conclusion (2min)

   • This session is the start
   • Deep dive into each functionality with existing sessions!

9. Recommendation of the past sessions to see next (if I have extra time)

   • With the basics of a broad range of functionalities in this session as a strong foundation, you can move on to the next step!
   • Heap escape condition and analysis: “Escape Analysis in Go: Understanding and Optimizing Memory Allocation” at Go Conference 2023 Online
   • GC logics: “Garbage Collection Semantics” at GopherCon SG 2019
   • Memory optimizations with pprof: “Memory Management in Go: The good, the bad and the ugly” at GopherCon UK 2023
   • (Advanced) Allocation of heap/stack (how Go allocation works with OS): “Understanding Go’s Memory Allocator” at GopherCon UK 2018
   • Memory design over concurrency (memory model): “The Go Memory Model” at GoSF Meetup

^ back to index

21. Give Your Coding Agent a Laptop of its own

Abstract

Description

Codegen agents are becoming increasingly popular for both local and remote workloads. However, as their capabilities increase, so does the need for environment isolation, to reduce the blast radius when their experiments go wrong.

This hands-on lab teaches participants how to create isolated compute environments for agents using sandboxes. These sandboxes provide airtight isolation and near-instant boot times, giving agents fast, deterministic environments to run arbitrary code without compromising other parts of the system.

Key Takeaways

• Learn how to securely run untrusted agent-generated code
• Get hands-on experience in building high-performance, low-latency sandbox environments in the cloud using native SDKs
• Understand how to connect cloud sandboxes with agentic workflows

Audience

• Builders of AI codegen agents
• Security engineers concerned with limiting arbitrary code execution by agents
• Platform engineers building compute infrastructure for agents
• Developers interested in sandboxed compute environments

Talk outline (120 min)

• Introduction (5 min)
• Risks of AI generated code execution (5 min)
• Requirements for AI sandboxes (10 min)
• Introduction to Blaxel - CLI, API, SDKs (5 min)
• Hands-on live coding (80 min)
• Create a Blaxel sandbox in the cloud
• Connect and explore the sandbox
• Execute code in the sandbox
• Connect the sandbox with an agentic workflow
• Logging and debugging
• Optimization options (10 min)
  • Sandbox templates
  • Volumes
• Summary and Q&A (5 min)

Notes

Most recent talk:

TREDACTED] August 29, 2025 | Amsterdam | AI_dev Europe 2025 [REDACTED]

Complete list of previous talks at [REDACTED]

There are many blog posts on this topic by me at [REDACTED]

Special note: I will be travelling from [REDACTED]. In this case, i will need appropriate documentation ie. invitation letter and written confirmation that the event is not political/religious/etc to qualify for the “speaker work pass exemption” under SG MOM rules. Rules at: [REDACTED]

^ back to index

22. Go 1.26 Prints Floats Faster: How I Brought Dragonbox to Go

Abstract

Description

Dragonbox is a modern float-to-decimal conversion algorithm by Junekey Jeon. I recently ported it from C++ to Go and worked on integrating it into the Go standard library. That work will likely ship in Go 1.26, and it has already inspired follow-up research by Russ Cox on an even simpler algorithm that is expected to land in Go 1.27.

Float-to-ASCII conversion matters more than it first appears. In JavaScript and JSON, there is no distinction between integers and floats - every number goes through float formatting. This is why Dragonbox has already been adopted in production C++ codebases and runtimes like Node.js, where it speeds up JSON.stringify and reduces output size.

In this talk, I’ll trace the evolution of float formatting in Go: from Grisu3, Ryu, and finally to Dragonbox. I’ll share lessons learned from porting a highly optimized C++ algorithm into Go - preserving performance characteristics and correctness guarantees - as well as working directly with Junekey Jeon, the author of the Dragonbox paper, on copyright and final reviews.

I’ll close with Russ Cox’s newer approach, which builds on ideas from Dragonbox but simplifies the core model further. Unlike Dragonbox, Russ’s algorithm applies the same underlying method to both float parsing and formatting, and extends naturally from shortest-width to fixed-width decimal printing - demonstrating how float formatting remains an active problem in 2026.

Outline:

1. Why float formatting matters (3 min)

• Floats are everywhere (JSON, logging, serialization)

2. Brief history of float formatting in Go (5 min)

• Pros and cons of Grisu3 and Ryu
• How each transition happened

3. New default in Go 1.26: Dragonbox (7 min)

• How it works at a high level
• Why it’s faster than Ryu
• Challenges of porting from C++ to Go:

4. What comes next: Russ Cox’s unified approach (3 min)

• Same algorithm for parsing and formatting
• Extends to fixed-width printing
• Simpler invariants, easier to verify

5. Takeaways (2 min)

• Float formatting is still evolving
• The value of revisiting solved problems

Links:

https://go-review.googlesource.com/c/go/+/700075 https://go-review.googlesource.com/c/go/+/731600

Notes

I previously presented at Go Conference 2025 (Japan): [REDACTED]

For travel, I plan to seek sponsorship from my employer, but I may need additional support depending on the circumstances.

^ back to index

23. Go at the Edge: Building Ultra Low Latency Services Close to Users

Abstract

Description

Edge computing is changing how backend systems are designed. Instead of large centralized services, more logic is now executed closer to users.

This creates a different set of engineering constraints. Services must start quickly, run with minimal resources, and respond within extremely tight latency budgets.

In this talk we explore how Go fits naturally into this environment.

We will walk through patterns for building lightweight edge services that handle routing, authentication, and data transformation with minimal overhead.

Topics include:

• Designing ultra fast request pipelines • Minimizing cold start latency • Safe caching strategies at the edge • Observability when services run globally

A demo will show a small Go service deployed in an edge style environment processing requests within a few milliseconds.

The talk focuses on practical techniques teams can apply immediately when moving workloads closer to users.

Notes

Some examples of my previous speaking engagements:

React India 2025 [REDACTED]

React Kolkata [REDACTED]

I have also spoken at DevFests, CityJS World Series, and other international developer events.

This talk includes a demonstration of a lightweight Go service designed for edge style deployments with extremely low latency budgets. The examples focus on practical patterns that engineers can adopt immediately.

I have not presented this talk at any other conference yet.

No special assistance required. I will attend the conference in person.

^ back to index

24. Go Fast or Go Home: Building High-Throughput AI Evaluation Systems with Go + Python

Abstract

Description

Machine learning practitioners often rely on Python-based scripts for experimentation, but evaluation pipelines quickly become complex when scaling to real-world workloads. Evaluating speech models across languages, datasets, and model architectures requires processing large collections of audio, coordinating multiple inference jobs, and computing metrics such as word error rate, character error rate, and semantic fidelity. This talk presents an architectural approach that combines Go and Python to build reliable, high-throughput evaluation systems. Go is used to orchestrate concurrent workloads, manage data processing pipelines, and provide robust CLI tooling, while Python handles model inference and ML-specific computation. Through a case study of a multilingual speech evaluation framework, we explore how this hybrid architecture enables reproducible benchmarking, efficient parallel processing, and scalable experiment workflows. In this talk, we will see how infrastructure decisions shape the reliability and usability of AI evaluation systems, and how thoughtful system design can transform ad-hoc research scripts into maintainable, production-ready tooling.

Key Takeaways

1. Learn how evaluation workloads differ from model training pipelines and why benchmarking systems require careful handling of concurrency, dataset management, and metric computation.

2. Understand how Go’s concurrency model, lightweight deployment, and CLI ecosystem can complement Python’s machine learning stack to build reliable evaluation tooling.

Notes

^ back to index

25. Go’s Memory Model: From Stack to GC and Everything In Between

Abstract

Description

Memory management in Go is mostly invisible—until your application slows down or hits a memory ceiling. In this talk, we’ll peel back the abstraction and explore how Go actually manages memory. You’ll learn how the compiler uses escape analysis to decide between stack and heap allocations, how the garbage collector works under the hood, and how to detect and reduce unwanted memory use.

We’ll cover:

=> The difference between stack and heap allocations => Escape analysis and its impact on performance => Go’s garbage collector: how it works, what triggers it, and what it costs => How to inspect memory behavior with tools like -gcflags, pprof, and runtime.MemStats => Common pitfalls that lead to memory bloat => Best practices for writing memory-conscious Go code => Talk about the newly adopted Green Tea span-based garbage collector and what it means for performance

Attendees will leave with a strong mental model of Go’s memory lifecycle and actionable techniques to diagnose and optimize memory usage in production-grade Go programs.

Notes

OUTLINE:

1. The Hidden Cost of Memory

A quick production example where latency or memory usage increases due to allocation pressure. Why understanding Go’s memory behavior matters even with automatic memory management.

2. Stack vs Heap in Go

How goroutine stacks work and when values are moved to the heap. Common patterns that trigger heap allocations (returning pointers, closures, slice growth).

3. Escape Analysis

How the Go compiler decides whether values escape. Demonstration using go build -gcflags="-m" to inspect allocation decisions and identify hidden heap allocations.

4. Garbage Collection in Practice

Overview of Go’s concurrent mark-and-sweep garbage collector and how allocation patterns influence GC frequency and CPU overhead. Observing GC activity with GODEBUG=gctrace.

5. Recent Runtime Improvements: Green Tea GC

Overview of the span-based garbage collector introduced in Go 1.25 and becoming default in Go 1.26, and how it improves GC efficiency and cache locality.

6. Debugging Memory Behavior Using Go’s built-in tooling to investigate allocations:

• pprof heap profiles
• runtime.MemStats
• GC tracing and runtime metrics

7. Key Takeaways Practical guidelines for identifying and reducing unnecessary allocations in Go programs.

PREVIOUS SPEAKING ENGAGEMENTS:

🇸🇬 Go Singapore Meetup (Sept 2021) 🇮🇹 GoLab 2022 🇺🇸 GoWest Conf 2022 🇮🇳 GopherCon India 2023 🇮🇳 GopherCon India 2025

^ back to index

26. Good by monorepo!

Abstract

Description

Our backend monorepo became a bottleneck: git status took several seconds locally, CI took close to 30 minutes. Mitigations such as sparse checkouts or Bazel yielded underwhelming results. We decided to break down the monorepo.

Modularisation: We split 1 large Go module into 1300 smaller modules. We tried incrementally, but we ran into intractable circular dependencies. We ended up modularising the entire monorepo at once, over a weekend. We pushed intermediate commits with broken dependencies, so that the go.mod of the next commits could reference them. After several carefully planned commits everything fell back in place!

Modules proxy: Because all the modules were still in the monorepo go get would take 30 minutes per dependency. We set up Athens as a module proxy. We build a CLI to help developers release their modules. Behind the scenes the CLI triggers a server-side job which populates the Athens S3 backend from the Git tag. We configured Athens not to clone the monorepo.

Import paths: To avoid significant refactoring after relocating the modules to a new repo, we looked at vanity imports. But implementation is non-trivial unless done right from the beginning. Instead, we decided to modify the job which pushes to the Athens S3 backend to handle the name change.

A lot more went into making this project a success. We adapted our strategy to manage proto files, we wrote new CI pipelines, and we migrated the Git history for each repo. We broke down our monorepo, saved our GitLab server, and made Go development at Grab a more pleasant experience!

Notes

^ back to index

27. Green Tea GC: The Insight Behind Go's New Garbage Collector

Abstract

Description

Main idea: Green Tea required new data structures to batch objects by span. The 128-byte ‘spanInlineMarkBits’ structure stores mark/scan state inline at the end of each 8KB span. FIFO queues (not LIFO) let spans accumulate marks before scanning. An ownership protocol prevents duplicate work. And the regular data layout enabled SIMD acceleration in Go 1.26 using AVX-512 instructions originally designed for AES cryptography.

Questions this talk answers:

• Why 63 bytes for marks/scans? An 8KB span with 8-byte objects could hold ~1000 objects. But most size classes are larger. 63 bytes × 8 bits = 504 bits covers typical cases while keeping the structure at 128 bytes (two cache lines).

• Why FIFO queues instead of LIFO? LIFO (stack) would scan spans immediately after adding them—potentially with only one marked object. FIFO lets spans sit longer, accumulating more marks. When finally scanned, you process 10 objects in one cache-friendly pass instead of 10 separate passes.

• How does the ownership protocol work? Three states: unowned, one-mark, many-marks. When you discover a pointer, you atomically set its mark bit and try to acquire the span. If you get it, you enqueue the span. If someone else owns it, you just set the bit—they’ll scan your object when they process the span. The one-mark state enables a fast path: skip bitset operations and scan the single object directly.

• How does SIMD help? Mark bits are 1 per object. Pointer scanning needs 1 bit per word (8 bytes). A 48-byte object needs its 1 mark bit expanded to 6 bits. The VGF2P8AFFINEQB instruction does 8×8 bit matrix multiplication—one instruction expands marks for an entire span. This instruction exists for AES; the Go team repurposed it.

• When does SIMD lose? Setup overhead matters. Dense spans (many marked objects) benefit from SIMD. Sparse spans (few marked objects) are faster with scalar iteration. The runtime tracks density and chooses dynamically.

Attendees will understand the data structures well enough to read ‘mgcmark_greenteagc.go’ themselves, know why each design decision was made (FIFO over LIFO, ownership states, dense vs. sparse paths), and see how architectural decisions cascade: span-based scanning enabled regular data layouts, which enabled SIMD, which the old object-centric GC couldn’t use.

This talk is proposed af advanced level. Attendees should be comfortable with atomic operations, cache behavior, and reading Go runtime code. If needed, I’m open to adjusting the depth to benefit the conference.

Notes

blog: [REDACTED]

From a few 2025 events: Golab: [REDACTED] (videos are not online yet) Golang X Conf: [REDACTED] Gophercon India: [REDACTED] GopherCon Africa: [REDACTED] (videos are not online yet) Keynote of GopherCon LATAM (Portuguese): [REDACTED]

^ back to index

28. How AI Coding assistants work - Building an agent in Go

Abstract

Description

AI coding assistants feel magical—but under the hood, they are structured systems that orchestrate models, tools, and code execution loops. In this talk, we’ll break down the architecture behind modern AI developer tools and build a minimal coding agent in Go.

Rather than focusing on prompt engineering, this session explores the engineering patterns that make coding agents possible: tool interfaces, structured model outputs, execution loops, streaming responses, and safe automation. We’ll design a simple agent that can read files, propose edits, execute commands, and iteratively refine results—demonstrating how Go’s concurrency primitives, context management, and strong typing make it a powerful language for orchestrating AI systems.

Along the way, we’ll cover real-world challenges such as:

Managing model hallucinations safely

Designing tool execution boundaries

Handling streaming token responses

Enforcing structured JSON outputs

Preventing runaway loops and resource leaks

By the end of this talk, attendees will understand how AI coding assistants actually work and walk away with practical patterns to build their own developer agents, AI gateways, or automation systems in Go.

Notes

I have previously spoken at multiple conferences and community events across India. Some notable ones include DevFest Ranchi, CodeDay, and MLH Hackcon, where I presented on topics around AI systems, developer tooling, and practical software engineering patterns.

Video recordings are not available but the posts can be seen on my LinkedIn.

This is my first time applying to GopherCon, and I’m excited to contribute to the Go community.

^ back to index

29. Hunting Goroutines: Go's Experimental Leak Detector

Abstract

Description

[What attendees will learn]

• Why goroutine leaks are insidious: no crash, gradual accumulation
• Common leak patterns: early returns, orphaned senders, forgotten cleanup
• The insight: ask the GC about channel reachability
• How the detector temporarily “hides” channel references
• The new _Gleaked goroutine state in the runtime
• Using pprof/goroutineleak in tests and production

[Questions to highlight]

• What are the most common goroutine leak patterns?
• How do I add leak detection to my existing tests?
• How do I distinguish real leaks from false positives?
• Should I check for leaks in every test?
• How does the detector work with test subtests?

[Initial outline]

1. The problem: goroutines that never wake up
2. Why detection is hard: waiting looks the same as stuck
3. The insight: reachability implies wakeability
4. Asking the GC nicely: how to detect unreachable channels
5. The mechanism: hiding references, iterative marking
6. The new state: _Gleaked joins _Grunning and _Gwaiting
7. Using it: pprof.Lookup("goroutineleak")
8. Real bugs caught: CockroachDB (18), Kubernetes (14), Moby (11)
9. Integrating leak detection into your test suite

[Target audience]

Go developers who write concurrent code, maintain long-running services, or want to catch goroutine leaks before they hit production. The talk covers both practical usage and the elegant GC trick that makes it possible.

If the Program Committee prefers other levels for this subject:

For a beginner audience, the talk would focus on what goroutine leaks are and how to spot them, rather than implementation details. I’d start with the mental model: a goroutine leak is a goroutine that will never terminate, usually because it’s blocked waiting on a channel that will never receive or send. The talk would emphasize practical detection, using runtime.NumGoroutine() in tests, the goleak package for automated detection, and reading goroutine dumps with pprof. Code examples would show common patterns that leak (unbuffered channels with no receiver, forgotten context cancellation, time.After in loops) and their fixes. The goal is that attendees leave able to add leak detection to their test suites and recognize the three or four most common leak patterns in code review.

For an advanced audience: the talk would dive into why leaks happen at the runtime level and sophisticated detection strategies. We’d examine how the Go scheduler manages blocked goroutines, why a leaked goroutine consumes ~2KB of stack (which grows if it ever runs), and how it pins the memory it references. The talk would cover building custom leak detectors that track goroutine creation sites using runtime.Stack, integrating leak detection into production monitoring (not just tests), and analyzing complex leak scenarios involving multiple blocked goroutines forming a cycle. We’d also explore edge cases: goroutines blocked on finalizers, leaks hidden behind sync.Pool, and the interaction between leaked goroutines and the garbage collector. Code examples would include production instrumentation patterns and debugging real-world leak cascades.

Notes

blog: [REDACTED]

From a few 2025 events: Golab: [REDACTED] (videos are not online yet) Golang X Conf: [REDACTED] Gophercon India: [REDACTED] GopherCon Africa: [REDACTED] (videos are not online yet) Keynote of GopherCon LATAM (Portuguese): [REDACTED]

^ back to index

30. Hunting Heisenbugs in Go Using Systematic Concurrency Testing

Abstract

Description

Hunting Heisenbugs in Go Using Systematic Concurrency Testing

Abstract

Go makes concurrency easy to write — but hard to test.

Goroutines, channels, and shared memory introduce subtle, timing-dependent bugs that are notoriously difficult to detect and nearly impossible to reproduce. Many concurrency issues only appear under rare interleavings and often escape unit tests, CI pipelines, and even production diagnostics.

In this talk, we introduce our ongoing work GCT, which is a concurrency testing framework for Go that makes schedule exploration systematic and failures reproducible. We’ll explain the core ideas behind GCT, highlight its key features, and show its workings through a live demo.

Motivation: Why Concurrency Bugs Are So Hard

Concurrent Go programs suffer from:

• Schedule-dependent race conditions
• Deadlocks triggered by rare interleavings
• Atomicity and ordering violations
• Heisenbugs that disappear when programmers try to observe, analyze, or debug it

Even with -race or Go’s built-in deadlock detector, many higher-level concurrency bugs remain undetected. Traditional testing relies on the runtime scheduler, which explores only a tiny fraction of possible execution orders.

To reliably find concurrency bugs, we need to treat scheduling as a controllable input — not a source of randomness.

What is Controlled Concurrency Testing (CCT)?

Underneath, GCT is built on the simple idea of Controlled Concurrency Testing, where one systematically controls and explores goroutine scheduling decisions. That is, instead of letting the Go scheduler decide execution order, GCT:

• Intercepts concurrency operations
• Controls scheduling decisions
• Systematically explores different interleavings
• Reduces redundant schedules

This transforms nondeterministic concurrent execution into a reproducible and searchable space, dramatically increasing the chance of exposing hidden concurrency bugs.

Our Concurrency Testing Framework for Go

We are building GCT, a practical CCT-based framework for Go with the following key features:

1. Pluggable Exploration Algorithms

Users can choose among multiple scheduling strategies borrowed from deep academic research, such as:

• Random walk exploration (RW)
• Partial order sampling (POS)
• Probabilistic concurrency testing (PCT)

This allows tuning for fast CI checks or deeper bug hunting.

2. Integration with TSAN

Naively intercepting sync operations and using Go’s sync primitives to control schedules introduces additional happens-before (HB) edges, which can confuse TSAN and prevent proper race detection. Our tool avoids this problem by controlling schedules without adding extra HB edges, enabling:

• Coordinated schedule exploration alongside TSAN
• Accurate detection of both memory races
• Reliable signal quality without false positives from scheduler instrumentation

3. Record-and-Replay

We provide deterministic record-and-replay:

• Record scheduling decisions
• Replay failing executions exactly
• Deterministically reproduce concurrency bugs

This eliminates “cannot reproduce” failures and makes debugging reliable.

4. Integration with MCPs and Agents

Our framework can integrate with MCPs to involve intelligent agents in schedule exploration:

• Agent-guided scheduling
• Feedback-driven exploration
• Hybrid human + AI debugging workflows

This opens the door to adaptive and automated concurrency testing.

Live Demo

We’ll demonstrate:

• A subtle, schedule-dependent bug in a Go program
• Why traditional testing misses it
• How our tool systematically exposes it
• Deterministic replay of the failure

Takeaways

You’ll learn:

• Why concurrency bugs are inherently hard to test
• How Controlled Concurrency Testing works
• How deterministic replay changes debugging
• How our framework GCT makes systematic concurrency testing practical in Go

Concurrency doesn’t have to be nondeterministic chaos — we can test it systematically.

Notes

^ back to index

31. Implementing RFC 9401: Understanding Go’s net Package Beneath net/http

Abstract

Description

Most Go developers use net/http every day, yet few pause to consider what happens beneath it. Even in the age of AI-assisted coding, the fundamentals of networking remain unchanged: at the end of every abstraction lies an operating system socket.

In this session, I implement RFC 9401 — a humorous Internet protocol — in Go to explore how Go’s net package interacts with the OS. RFC 9401 serves as a lightweight and approachable specification, allowing us to focus not on the complexity of the protocol itself, but on how specifications become working network code.

Through this implementation journey, we will examine:

• How to read an RFC with implementation in mind
• The roles of net.Listen, net.Dial, and net.Conn
• How Go maps connections to operating system file descriptors
• A high-level look at Go’s I/O model
• How net/http is built on top of net

This talk is designed for beginner to intermediate Go developers who regularly use net/http but want a clearer mental model of what happens under the hood. Attendees will leave with a deeper understanding of Go’s networking stack and greater confidence when designing or debugging networked systems.

Notes

This talk is based on a hands-on re-implementation of RFC 9401 in Go, tracing how Go’s net package operates beneath net/http through practical experimentation and source code analysis.

The full experimental implementation discussed in this talk is available here: [REDACTED]

This will be my first international conference talk. I regularly write technical blog posts in Japanese about systems programming and Go internals, which you may refer to here: [REDACTED]

No special assistance required.

This session aims to bridge the gap between RFC documents and real-world Go networking implementations.

^ back to index

32. Inside CGO: How Code Generation Connects Go and C

Abstract

Description

Abstract

Using CGO makes it appear easy to work with C functions and data structures from Go. However, beneath that simplicity lies a complex build process and precise code generation designed to bridge fundamental differences between Go and C—such as their ABIs, stack models, and calling conventions. The C code embedded in comments, the unusual C.add() style calls, and other behaviors that differ from ordinary Go all arise from technical requirements imposed by these internal processes.

This session begins with the common questions CGO users encounter—“Why must I write it this way?” and “Why does it behave like this?”—and explains, step by step, how Go generates intermediate code and how the build process connects it to C. We clarify why this intermediate code is necessary given the ABI and stack model differences, how go tool cgo uses the C compiler as a type calculator, and how the Go and C worlds are ultimately linked in the final build.

By walking through these processes, participants will gain a clear understanding of the technical motivations behind CGO’s surface-level peculiarities, allowing them to reinterpret its unusual syntax and build behavior in a more coherent and convincing way. The goal of this session is to provide a solid mental model for using CGO more effectively and confidently.

Outline

1. Introduction

CGO includes behaviors that differ from standard Go, such as writing C code inside comments or calling functions like C.add(). These “oddities” stem from the intermediate code generated behind the scenes. This section introduces the mechanisms of CGO by examining where these seemingly strange surface behaviors originate.

2. The Invisible Wall: Technical Collision

Here we clarify why Go and C inherently have different execution models. Specifically, differences in ABI, calling conventions, and stack management make it unsafe to directly connect the two languages with naïve function calls.

We then explain CGO’s strategy for overcoming this “collision of execution models,” and walk through how bridging code—trampolines, stubs, and auxiliary code used for consistency—is generated step by step.

3. The Anatomy: How the Bridge is Built

In this part, we examine how go tool cgo uses the C compiler as a “type calculator,” extracting structure sizes, offsets, and function signatures from DWARF information to generate Go-side type definitions (_cgo_gotypes.go). We also cover how user-written C.add is transformed into _Cfunc_add (.cgo1.go), the role of trampoline functions generated on the C side (.cgo2.c), and how C code inside comments is incorporated into the final build.

Finally, we explore how object files generated separately by the Go compiler and the C compiler are merged by an external linker, and why CGO delegates the linking phase to an external linker by design.

4. Conclusion

We conclude by summarizing how Go and C cooperate when viewed through the lens of CGO’s code generation. Understanding these internals provides solid grounding when debugging or evaluating performance, ultimately enabling more reliable interface design.

Through this session, participants will come to see CGO not as a mysterious mechanism with unpredictable behavior, but as a well-structured system built to satisfy concrete technical requirements.

Notes

^ back to index

33. Less is More: The Go Way to Optimization

Abstract

Description

Go is built on the idea that less is more. Simple code is easier to reason about, maintain, and often performs well by default. But as developers, we still fall into traps: trying to optimize too early, adding abstractions we don’t need, or writing “future-proof” code that no one asked for.

This talk is based on a set of real engineering experiences, where trying to write “clean” or “fast” Go code ended up making things more complicated, not better. One of the key moments was while I was integrating RabbitMQ into a service.

I created an abstraction layer with interfaces like MessageBroker, Publisher, and ConsumerHandler, thinking it would help us swap RabbitMQ with any other tool (like Kafka or NATS) in the future. I wrapped the amqp package completely, believing I was writing elegant and future-proof code.

THE PROBLEM?

We had already made an informed decision to use RabbitMQ. We weren’t switching tools. My reviewer left a simple but telling comment: “Do we really need this many interfaces? Can we simplify this? The code is very hard to follow.”

That’s when it hit me - none of this abstraction was needed. It just made the code hard to understand, harder to debug, and even harder to maintain.

In this session, we’ll look at common ways Go developers overthink things in the name of performance or flexibility:

• Abstracting too early with interfaces and layers
• Spawning goroutines for everything without clear benefit
• Benchmarking without understanding real-world load
• Optimizing the wrong part of the system—or too soon

Then we’ll switch to a practical, data-driven approach:

• Using pprof and trace to find real bottlenecks
• Writing focused benchmarks with testing.B and benchstat
• Understanding escape analysis and heap allocations
• Optimizing for simplicity and maintainability first

This talk is about making smart, data-driven decisions, not just for speed, but for cleaner, more effective Go code.

You’ll walk away with tools, patterns, and a mindset to help you write Go that’s truly optimized for real-world use.

Notes

TALK OUTLINE - What Will Be Covered

1. The RabbitMQ Integration Story RabbitMQ integration: Created abstract interfaces to make things “future-proof” Reviewer feedback: “Do we really need this many interfaces? Can we simplify this? The code is very hard to follow.” Realization: Solving a problem we didn’t have, and making the code worse

2. Common Mistakes in Go Optimization

• Overusing interfaces and generalization
• Unnecessary goroutines and concurrency
• Benchmarking isolated code without real context
• Optimizing code paths that don’t need it

3. Smarter, Data-Driven Optimization

• Using pprof to identify CPU and memory bottlenecks
• Using trace to inspect blocking, GC, and scheduling
• Writing real-world benchmarks with testing.B and analyzing with benchstat
• Using go build -gcflags=-m to identify unnecessary allocations (escape analysis)

Examples of simplifying and improving code without over-abstracting

4. Takeaways & Checklist

• Optimize only with data, not assumptions
• Prioritize clarity and maintainability
• Use Go’s tooling early in the process
• Think performance-aware, not performance-obsessed

This talk is a blend of war stories, code examples, and practical Go tooling that will resonate with both new and experienced Go developers.

This talk addresses a common but often under-discussed challenge in Go development: the temptation to optimize code too early or for the wrong reasons. It discusses relatable experiences that many developers have faced like over-engineering solutions, trusting gut instincts over measurements, and chasing performance that never mattered in the first place.

PREVIOUS SPEAKING ENGAGEMENTS:

🇸🇬 Go Singapore Meetup (Sept 2021) 🇮🇹 GoLab 2022 🇺🇸 GoWest Conf 2022 🇮🇳 GopherCon India 2023 🇮🇳 GopherCon India 2025

^ back to index

34. Let’s Play Go: Learning Go Concepts Through a Board Game

Abstract

Description

Learning Go is usually done by writing code.
However, concepts like architecture, structure, and team collaboration are often hard to understand through code alone.

To explore a different approach, I created a board game inspired by real-world Go development.
Players build systems by combining feature cards, while bug cards introduce unexpected problems.
Through simple rules, players naturally experience Go concepts such as separation of concerns, dependencies, and dealing with failures.

In this session, I will cover:

• The design concept of the Go board game
• How Go concepts map to game mechanics
• Why learning through play is effective

After the talk, attendees will be invited to play the game together.

Notes

^ back to index

35. Lets Build a MCP server on GO !

Abstract

Description

This talk walks through building a Model Context Protocol (MCP) server from scratch using Go over Streamable HTTP transport protocol. We will cover the protocol, transport, and tool registration patterns. Attendees will leave knowing how to expose their own Go services as MCP servers that any AI agent can talk to.

We’ll start by understanding what MCP is and why it matters, then implement a working server that exposes tools an AI agent can call over plain HTTP with streaming responses.

Outline:

1. What is MCP and why should Go developers care?
2. The MCP protocol: why Streamable HTTP over SSE or stdio?
3. Streamable HTTP in depth: how requests and streamed responses flow
4. Writing a minimal MCP server in Go from scratch

Notes

^ back to index

36. Nil dereference problems and tools to catch them

Abstract

Description

Abstract

Nil pointer dereference is a common Go pitfall that can cause production crashes for developers at any experience level. This talk uses short spot-the-bug puzzles to highlight non-obvious code patterns that pass reviews and tests but still contain nil pointer dereferences. The talk also covers static analysis tools that can catch nil pointer dereferences before they reach production.

Description

Tony Hoare called null pointers his “billion-dollar mistake”*. While Go avoids many classic pointer problems through garbage collection and escape analysis, nil dereferences can still crash production systems.

This talk focuses on nil bugs that look correct at first glance. Each example is presented as a small interactive puzzle: you see the code, predict what happens, and then we unpack the Go behavior that makes the bug easy to miss. Every puzzle ends with a concrete takeaway: a step-by-step trace of how the nil value appears, a coding habit to prevent the issue, or an analyzer that can detect it.

The final part maps these bug classes to today’s tooling. We compare what analyzers catch reliably, what they miss, and why. You will leave with clear guidance on which tools and practices to use for each class of nil bug.

Notes

Relevant Talks and Articles

I have previously given a related version of this talk at GoWest conference, where it was accepted and well received. A video recording of that presentation is available at the link below:

• Spot the Nil Dereference: How to avoid a billion-dollar mistake

I have also written several blog posts. Two of them are related to static analysis of Go code. The first one covers interprocedural analysis, which I will partly discuss in the final section of the talk, where I compare the capabilities of different tools.

• Interprocedural Analysis: Catch nil Dereferences Before They Crash Your Code
• Data Flow Analysis for Go

Please note that this is not a product pitch, and I will not be promoting anything.

Talk outline (25 minutes):

Here I would like to present an approximate outline of the talk. The talk consists of three parts.

Part 1: Nil fundamentals: introduction (~8 min)

• The billion-dollar mistake: I briefly cover the history of nil and null pointer issues to show the scale of the problem
• Why it matters today: I share recent real-world Go service outages caused by nil dereference
• Nil basics: I explain nilable types, where nil values come from, and which operations panic to bring everyone to the same level

Part 2: Non-obvious nil bugs (~15 min)

In this section, I present non-obvious nil bugs as interactive puzzles. Each example follows the same structure: see the code, spot the problem, understand why it’s dangerous, and learn the takeaway.

• Example 1: warm-up – nil as the default value for pointers in variable and struct field initialization
• Example 2: variable shadowing hides error handling and causes subtle nil dereference
• Example 3: typed nil converted to interface – a source of subtle and unexpected bugs
• Example 4: nil dereference hidden by function call chains – when nil originates deep inside other functions

Part 3: Tooling (~10 min)

In this section, I review tools for automatic nil dereference detection, their capabilities, and limitations.

• Overview of intraprocedural (local) static analysis tools: go vet, staticcheck, golangci-lint
• Oerview of interprocedural (global) deep interprocedural analyzers: NilAway (free solution) and GoLand (paid solution)
• Practical recommendations: how to use these tools on a regular basis – on-the-fly in your editor and in CI/CD pipelines to prevent nil bugs before production

Part 4: Conclusion (1 min)

I wrap up with a reminder that nil dereference is a real problem worth addressing, and encourage everyone to adopt static analysis tools to catch these bugs before they hit production.

^ back to index

37. OCR Magic in Go: Build AI-Powered Text Extraction with Ollama in Minutes

Abstract

Think Go can’t power AI OCR apps? Think again. With Ollama, scanning text from images becomes a breeze.

Build a fast, local OCR tool in Go using Ollama-no Python needed. Join this session to unlock Go’s untapped potential in AI-powered OCR.

Description

Are you tired of people saying Go doesn’t work well with AI? Or that Python and JavaScript are better suited for AI? If you love Go (or you’re an aspirant gopher), join my talk and unleash the potential of Go in the AI world!

In this talk, we will focus on how OCR technologies work with Go. To play with OCR (Optical Character Recognition), we’ll use the Ollama platform to run large language models locally in Go. Ollama allows us, among other features, to run models both locally and in the cloud.

The models we’re going to use are vision models, such as qwen3-vl, granite3.2-vision, llava, etc. We’ll explore the approaches - the generate and the chat - we can use to talk to LLMs.

Understanding these differences is key to building effective AI applications in Go. This hands-on session blends theory with live coding to demystify integrating vision models into Go applications.

Leave with the skills to build real-world OCR tools using Go and open-source vision models.

Notes

^ back to index

38. Platform Advocate

Abstract

Description

Notes

^ back to index

39. Practical sqlc: leveraging SQL-first code generation

Abstract

Description

Sqlc brings compile-time safety and raw SQL performance to Go by generating type-safe query code directly from SQL files. It eliminates runtime errors common in hand-written database code — but adopting it in production introduces new challenges.

This talk focuses on real-world patterns for using sqlc effectively. We’ll explore how to handle dynamic conditional queries, decide between pgx and pure Go types for generated code, and keep domain models separate from sqlc-generated structs to avoid leaking database schema details. You’ll also see how to structure projects cleanly with repositories and services, ensuring that sqlc-generated code stays confined to the data layer.

The session shares practical techniques to extend sqlc’s static nature while keeping its strong compile-time guarantees. You’ll learn how to design queries, structure code, and test effectively — balancing the precision of SQL with the maintainability of idiomatic Go.

Takeaways:

• Real-world patterns for using sqlc, including dynamic queries and type choices.
• How to structure projects and repositories to keep domain logic separate from generated code.
• Practical techniques for testing and extending sqlc while preserving compile-time safety.

Notes

^ back to index

40. Real Failure: Designing Go Systems That Use Failure as a Feature

Abstract

Description

Most production systems spend enormous effort trying to avoid failure. Retries, circuit breakers, timeouts, and alerts all exist to keep failure away from users. Yet in practice, failure is unavoidable. Networks partition, dependencies slow down, data becomes inconsistent, and unexpected states appear.

Instead of treating failure as an exception, this talk explores a different approach: designing systems where failure is a first class signal.

We will look at a design pattern where failures are modeled as structured events that move through the system just like successful results. Rather than hiding them behind logs or retries, failures become observable, routable, and testable components of the architecture.

Using Go as the implementation language, the talk introduces a small runtime pattern where services emit typed failure signals that can trigger controlled responses such as compensation, state correction, or safe rollback. Generics are used to keep failure handlers type safe and composable, while maintaining the simplicity of idiomatic Go.

A live demo will walk through a simplified payment processing pipeline. The system intentionally injects controlled failures such as downstream latency spikes or partial transaction errors. Instead of collapsing under these conditions, the pipeline uses failure signals to coordinate safe recovery steps while maintaining system integrity.

We will also explore how this approach improves observability. Because failures are structured signals rather than opaque logs, operators gain a clear view of how the system reacts during incidents.

The talk concludes with practical guidelines that teams can apply immediately:

How to model failures in Go APIs How to propagate failure signals safely across services How to test failure scenarios without fragile integration tests How to expose meaningful operational signals for debugging production incidents

The goal is not to eliminate failure. The goal is to make failure useful.

Notes

This talk includes a live demo implemented in Go that simulates a production style payment workflow. The demo intentionally introduces several failure scenarios and demonstrates how structured failure signals allow the system to recover safely.

The code examples are small and self contained so attendees can experiment with the patterns after the talk.

I am happy to provide the demo repository and sample implementations if the talk is shortlisted. I will also be attending the conference in person.

Previous talks:

React India 2025: [REDACTED]

React Kolkata: [REDACTED]

^ back to index

41. Register-Based ABI: Engineering Go’s Next-Generation Calling Convention on IBM-Z

Abstract

Description

Register-Based ABI on s390x: Engineering Go’s Next-Gen Calling Convention on IBM Z:

With Go 1.26, s390x joins other architectures in adopting Go’s register-based ABI (RegABI), modernizing how functions pass arguments and return values.

This talk presents a technical walkthrough of bringing RegABI to IBM Z: > Transition from stack-based to register-based calling convention > Changes across the Go compiler (SSA backend, lowering, ABI rules) > Handling spills, stack maps, and GC correctness > Interactions with assembly, cgo, and runtime entry points

We will analyze how argument passing in GPRs and FPRs reduces memory traffic, improves instruction scheduling opportunities, and lowers call overhead.

Beyond implementation details, I will present real workload measurements showing up to 25% performance improvement in selected applications after enabling RegABI on s390x.

This session is ideal for:

Compiler engineers Runtime contributors Architecture port maintainers Developers interested in exploring or learning about Go compiler internals and ABI working.

Notes

^ back to index

42. Rethinking Time Semantics in Go’s Runtime Scheduler (sysmon) for improved performance in Virtualized Environments

Abstract

Description

Problem Statement:

On highly virtualized environment on IBM-Z enterprise servers, we observed a significant performance issues, mainly because of the fact that Go’s runtime scheduler (sysmon) relies on counter based timing heuristics to balance latency, CPU efficiency, and fairness rather than the real wall-clock time.

Currently, Go scheduler (sysmon) takes a large number of usleep “system calls” before it actually recognizes that it is idle and goes to sleep for a long time. This large number of usleep calls is causing the increased problems when working in conjunction with the Hypervisor (LPAR) scheduler.

The core of the problem is about the choice of polling vs. sleeping in the main Go scheduler (sysmon) loop. While this assumption holds reasonably well for a bare metal system, but in a virtualized environment, this causes already idle Go processes to still consume resources that the rest of system would like to use.

In an Enterprise Systems, vCPUs may be preempted, throttled, migrated, or power-managed independently of the guest runtime. Under these conditions, the assumption that loop progression correlates with real elapsed time no longer holds.

The result can be disproportionate delay escalation, increased wakeup latency, fairness anomalies, and measurable throughput degradation under contention.

This talk is based on hands-on investigation of Go runtime behavior under virtualized workloads, including controlled benchmarking and runtime instrumentation across multiple architectures (IBM-Z and x86_64 etc..).

This paper presentation will include:

A walkthrough of the current Go runtime scheduling (sysmon) logic. A prototype modification that replaces counter-driven delay progression with wall-clock-based decisions. Measured benchmark data demonstrating latency amplification under vCPU preemption. Cross-architecture observations showing the issue is not platform-specific. Quantitative comparison of latency, throughput, and fairness characteristics.

The session is “technical” and intended for Go developers interested in runtime internals, performance improvements, and Go’s behavior in enterprise or cloud-native deployments.

Notes

^ back to index

43. Revisiting the Outbox Pattern in Go

Abstract

Description

My talk title mimics Gunnar Morling’s article, “Revisiting the Outbox Pattern.” The pattern isn’t new, but the article summarizes implementations well. I’ll show how to implement these in Go.

Problem & Naive Solutions The pattern solves the dual-write problem when storing data and publishing events. Writing to a DB first risks losing messages; writing to a queue first risks inconsistency. Holding a DB transaction open while sending events can exhaust connections.

Outbox Table & Relay A safer approach is inserting events into an outbox table within the DB transaction. The challenge is efficiently reading and publishing them.

Implementations Debezium (Java, CDC) has high memory overhead.

Polling in Go (SELECT + UPDATE) creates dead tuples.

Offset tracking avoids updates (Watermill SQL).

Logical replication in Go (jackc/pglogrepl) is promising but complex.

PeerDB is built on top of jackc/pglogrepl which also uses Temporal.

Outbox remains relevant in 2026, with emerging Go solutions.

Notes

^ back to index

44. Rewriting [REDACTED] in Go: creating the foundation of a brand new ecosystem

Abstract

Description

Abstract

With 12k GitHub stars,[REDACTED] is arguably a very popular open-source project, featured in several Linux distributions, including openSUSE Aeon, SteamOS, and more.

This talk shares the journey of rewriting [REDACTED] from POSIX shell to Go. I’ll discuss the design decisions, architectural principles, and lessons learned in maintaining 100% feature parity while leveraging Go’s modularity, testing capabilities, and performance. You’ll see how this foundation enables future expansion and community innovation.

note to reviewer: the code this talk is based on is going to be public by the end of the month. We are taking a bit of time to plan a good communication with the community.

Outline

• Intro (5 minutes)
  • Introduiction
  • The Challenge with POSIX
  • POSIX Had Real Advantages
  • Our Three Principles
  • Unexpected Joy #1
• The Rewrite (10 minutes)
  • Design: Three-Layer Architecture
  • Making a Plan
  • Unexpected Joy #2
• Conclusion (2 minutes)
  • What’s Next
• Q&A (3 minutes)

Full description

note to reviewer: ideally each item is a slide to show, ~2 minutes each.

0: Introduction

[REDACTED] is a tool that allows you to run any Linux distribution inside the terminal by leveraging containers. It was written in POSIX shell and first released in November 2021.

The project grew quickly. We now have contributions from over 200 developers, and [REDACTED] has become an everyday tool for many people. Including myself, and that’s why I’m here talking to you.

Because [REDACTED] is established and widely used, we decided to undertake a complete rewrite in Go. This V2 will accelerate development of new features and strengthen the foundation for future work.

1: The Challenge with POSIX

As said, the project started with POSIX shell. It worked, but as the project grew, maintaining it became increasingly difficult.

• No modularization, everything tightly coupled and hard to reuse, which led to a lot of duplications.
• No effective unit testing
• Given everyting is stdin/stdout, a lot of quote escaping is required
• Parsing structured data (JSON, TOML) is very uncomfortable
• Hard to integrate in third-party software

These are all aspects in which Go shines, and that’s why we decided for a complete rewrite over a simple refactoring.

2: POSIX Had Real Advantages

POSIX shell comes also with some streghts we didn’t want to overlook:

• No build step is required, just copy the source and execute it
• Multi-architecture support was automatic (Linux, macOS, BSD)
• Given that Distrobox interacts a lot with the host’s container managers (docker, podman, …), the integration is seamless and requires no abstraction - just run the command (podman exec …)

In Go, we have to handle these differently. Building for multiple architectures takes work. We decided the gains elsewhere were worth it, but we had to approach V1 carefully to minimize disruption.

3: Our Three Principles

We built around three principles:

• 100% feature parity—drop-in replacement for V1, no breaking changes
• (quasi) Zero dependency, to reduce bundle size and vulnerability surface. We made exceptions for the cli (urfave), toml (ini.v1) and dotfile parser (godotenv)
• Modularity, to allow packages to be reused internally and from third-party applications

These three principles guided every decision.

4: Unexpected Joy #1

Performance improved dramatically:

Go implementation vs POSIX shell:

• Significantly faster execution across the board
• Startup time reduced

We we actually doubtful about performance before starting, as we thought spawning processes from Go would have waste resources.

5: Design: Three-Layer Architecture

We structured the code in three layers:

The CLI layer:

• Binds commands to the shell and user configuration
• Handles the user-facing interface
• Composed of internal packages used by Distrobox

The command layer:

• Implements each distrobox subcommand
• Commands can be composed from other commands
• Creates an inheritance graph that ensures consistency and code reuse

The container manager layer:

• Abstraction over podman, docker, and future support for lxc and systemd-nspawn
• Promotes modularity and interchangeability

This structure kept concerns separate, made the code testable, and exposed reusable packages for future integrations.

6: Making a Plan

We took a systematic approach:

Reverse engineering:

• V1 is procedural scripts with tangled control flow and ad-hoc fixes
• Required careful analysis to separate concerns

Command inheritance graph:

• We mapped dependencies between commands
• Developed one command at a time, starting from those with fewest dependencies
• This prevented cascading rewrites

Periodically rebase with V1 upstream:

• Stayed synchronized with V1 improvements
• Ensured we weren’t diverging from the reference implementation

7: Unexpected Joy #2

The Go implementation exposed bugs in V1 that we could fix upstream. As we reimplemented features, we found edge cases and inconsistencies in the original code. We reported and fixed them. The V1 codebase benefited from the scrutiny.

8: Testing

We made unit tests part of the development process:

Unit testing:

• Every command has tests
• Developed alongside the code, not after

Comparative test suite:

• Runs both V1 and V2 in parallel
• Uses combinatorial flag generation to explore the command space
• Compares command output, dry-run results, and container inspect data

This caught regressions early and ensured feature parity.

9: What’s Next

Current status and plans:

Release strategy:

• V2 is available for user preview
• V1 is in feature freeze
• Milestone: replace V1 with V2 at 100% feature parity

Ecosystem growth:

• Build a community-driven ecosystem of tools on top of Distrobox
• V2 exposes its logic through public packages, making it available for other projects to build on

Future container manager support:

• Once V2 becomes the main upstream, expand support for additional container managers
• Currently focused on podman and docker

This positions Distrobox as a foundation, not just a standalone tool.

Links

• https://distrobox.it
• https://github.com/89luca89/distrobox

Notes

^ back to index

45. Self-Documenting Codebase: Domain Driven Design Patterns for the Agentic Era

Abstract

Description

we’ll share techniques that make business flow discoverable:

• Clear module ownership so agents know where changes belong
• Consistent entry points for business actions (use cases, not scattered logic)
• Event definitions that read like business facts (ProductShippedBySellerEvent, not EntityUpdated)
• Translation layers that keep partner/external data formats from spreading into core code

We’ll also show how to encode important rules in forms AI can follow: decision tables, state transition rules, and tests that act as executable requirements.

You’ll leave with a practical AI-Readability Assessment—what to document, how to structure modules, how to design contracts between domains, and how to guide an agent to read the right context before it writes code.

These patterns have a name: Domain-Driven Design. But we’ll focus on why they matter now when AI agents read your code as often as humans do.

Appealing points

• A checklist for agent-friendly DDD signals: ubiquitous language, context maps, contracts, invariants, and boundaries.
• How to structure a multi-domain repo so agents can follow the flow (events, orchestration points, read models) without guessing.
• How to use tests and decision tables as executable business specs that agents can align changes against.
• A workflow for running agents safely: “read-first paths”, constraints, and review gates tied to domain boundaries.

Notes

^ back to index

46. So What Really Changed: Deep Dive Into Go 1.26's New GC

Abstract

Description

In this talk we’ll look into one of the latest changes to Go, a brand new garbage collector that shipped with Go 1.26, and why it matters for your services.

Initially the GC worked by chasing pointers across memory, jumping from object to object to figure out what was still alive. This was a reasonable approach for its time, but modern hardware changed the equation. CPUs evolved faster than memory, and the software layer had to evolve with them. Two objects pointing to each other can live anywhere in memory, and fetching from main memory is up to 100x slower than reading from cache. More than a third of GC time was being wasted just waiting on memory, not doing any useful work.

The new Green Tea GC tackles this head on and we will cover how this works, what workloads benefit the most, how to opt out if you need to before Go 1.27 removes that option, and close with a look at the new goroutine leak detector that came along for the ride.

Notes

^ back to index

47. Teaching AI to Write Modern Go

Abstract

Description

AI can write Go — but it often writes Go from the past.

Modern coding agents frequently fall back to patterns that were common many years ago. Instead of using modern idioms like slices.Contains, they often generate manual loops and helper functions. The code still works. But it is verbose and increasingly out of step with how Go is written today.

In this talk we’ll explore why this happens. We’ll focus on two key causes: training data lag and frequency bias in large language models. Through real examples, we’ll see how coding agents repeatedly choose outdated patterns even when modern alternatives exist.

We’ll then introduce guidelines that teach coding agents to write modern Go. These guidelines encode recent language and standard library improvements. We’ll also show how applying them significantly improves generated code in a benchmark of Go tasks.

Notes

Speaking at a conference experience

I have previously given a talk at GoWest 2025 conference:

• Spot the Nil Dereference: How to avoid a billion-dollar mistake

Blog posts

I have also written several blog posts. Two of them are related to static analysis of Go code, and one discusses AI-generated Go code and modern Go idioms, which is directly related to the topic of this talk:

• Write Modern Go Code With Junie and Claude Code
• Interprocedural Analysis: Catch nil Dereferences Before They Crash Your Code
• Data Flow Analysis for Go

Approximate talk outline

Here is the approximate outline of the talk. Please note that this is not the final version and may change:

1. Introduction: AI Writes Go from the Past We begin with a short introduction to the growing role of AI coding agents in Go development and the surprising observation that they often generate outdated Go code. As a quick example, we show a simple case where an agent writes a manual loop instead of using slices.Contains. This sets up the central question of the talk: why do coding agents write outdated Go, and how can we teach them to write modern Go instead?

2. Why Coding Agents Write Outdated Go We examine two key reasons. First, training data lag: models are trained on code that often predates recent Go features. Second, frequency bias: even when models know modern APIs, older patterns appear more frequently in training data and are therefore preferred. For each cause, we show concrete code examples of how coding agents choose outdated patterns over modern alternatives.

3. What Is “Modern Go”? We define what we mean by modern Go by looking at recent language and standard library evolution. We highlight several important idioms and improvements and briefly discuss how tools like the modernize analyzer capture these changes.

4. Teaching Coding Agents Modern Go We introduce a set of guidelines designed to help coding agents produce modern Go. These guidelines encode language evolution and standard library improvements, allowing agents to choose modern idioms when generating code.

5. Evaluation: Do the Guidelines Work? We present a benchmark of Go tasks designed to test whether coding agents use modern idioms. We show how agents perform without guidance and how their behavior changes after applying the guidelines.

6. Conclusion: Takeaways for Go Developers We conclude with practical lessons for Go developers and tool builders: how to encourage modern Go in generated code, how tooling like modernize can help, and why guiding AI tools will be increasingly important as they write more of our code.

Related GitHub repo

This talk is based on the repository [REDACTED], which defines guidelines that help AI coding agents generate modern, idiomatic Go code.

^ back to index

48. The Death of the Wrapper: Building Native Go MCP Servers for AI Agents

Abstract

Description

As AI agents begin to interact with real software systems, most integrations follow a familiar pattern: wrap an existing REST API and let the model call it.

While convenient, this approach loses important context. Type safety disappears, error handling becomes fragile, and the agent ends up interacting with a thin abstraction rather than the real capabilities of the system.

The Model Context Protocol introduces a different idea. Instead of exposing endpoints, applications expose tools, resources, and structured capabilities that agents can reason about directly.

In this talk we explore how Go can be used to build native MCP servers that expose application logic to AI agents without relying on fragile API wrappers.

We will walk through a practical example where an existing Go service exposes internal capabilities through an MCP interface. The agent is able to discover tools, invoke operations, and retrieve structured data with clear contracts.

Topics covered include:

How MCP changes the way applications expose functionality to AI agents Designing tool interfaces that preserve Go’s type safety Handling agent tool calls efficiently using Go concurrency Reducing latency compared to traditional API based integrations Observability and safety considerations when agents interact with production systems

A live demonstration will show a small Go service exposing internal capabilities to an agent through MCP, illustrating how this approach enables richer interactions while keeping the system predictable and maintainable.

The goal of this talk is to move beyond simple wrappers and explore how Go applications can become first class participants in agent driven systems.

Notes

Recordings of some of my previous conference talks:

React India 2025 [REDACTED]

React Kolkata [REDACTED]

I have also spoken at DevFests, CityJS World Series, and other international developer conferences and community meetups.

This talk is based on practical experimentation with agent based systems and emerging protocols that allow applications to expose capabilities to LLM driven agents. The session will include a live demonstration implemented in Go.

I have not presented this talk at any other conference yet.

No special assistance required. I will attend the conference in person.

^ back to index

49. The Debugging Time Machine: Reconstructing Production Incidents in Go

Abstract

Description

Every production engineer has faced the same frustrating moment. Something went wrong in a distributed system, but the logs only show pieces of the puzzle.

We see requests, retries, and errors, yet we still cannot answer the real question: why did the system behave this way?

This talk introduces a practical technique called causal tracing. Instead of simply recording events, the system records relationships between events.

Using Go, we will build a lightweight tracing model that propagates causal identifiers across services. These identifiers allow us to reconstruct the chain of decisions that produced an incident.

A demo will show how a simulated outage unfolds across several services. With causal tracing enabled, we can replay the entire story and see how small timing differences created the failure.

Attendees will learn:

• How to propagate causal context across services • How to store and query causal graphs • How to debug incidents using reconstructed execution timelines • How this approach complements traditional tracing systems

The result is something closer to a debugging time machine than a log file.

Notes

Links to previous speaking engagements:

React India 2025 [REDACTED]

React Kolkata [REDACTED]

In addition, I have spoken at multiple DevFests, CityJS World Series events, and international developer meetups.

This talk includes a practical demonstration of a lightweight causal tracing approach implemented in Go. The demo shows how a distributed system incident can be reconstructed step by step using causal relationships between events.

I have not presented this specific talk at other conferences yet.

No special assistance required. I will attend in person.

^ back to index

50. The End of Determinism: The Rise of the Probabilistic Engineer

Abstract

Description

Notes

^ back to index

51. The Hidden Cost of Goroutines: When Concurrency Becomes Your Production Bug

Abstract

Description

One of the first things developers love about Go is how easy it is to start a goroutine.

But in production systems, uncontrolled concurrency quietly becomes one of the most common sources of instability. Memory spikes, latency storms, and cascading failures often start with a few innocent goroutines.

This talk explores what actually happens when goroutines scale beyond what the system can safely handle.

Through real examples, we will examine how seemingly harmless patterns create hidden feedback loops inside services. The talk will demonstrate how queueing effects, scheduler behavior, and resource contention combine to produce surprising failures.

We will then walk through practical techniques for building concurrency that remains predictable:

• Structured concurrency patterns • Safe worker pool architectures • Concurrency budgets and backpressure • Observability techniques for goroutine explosions

A small live demo will show how a system that looks correct during testing can collapse under realistic load and how a few simple design changes make it stable again.

Notes

Recordings of some of my previous conference talks:

React India 2025 [REDACTED]

React Kolkata [REDACTED]

I have also spoken at DevFests, CityJS World Series, and various international developer meetups.

This talk is based on real production experiences debugging concurrency related incidents and performance bottlenecks in distributed systems. The session includes a small live demonstration showing how uncontrolled goroutine patterns can trigger cascading failures under realistic load.

^ back to index

52. The Interface Your Go API Doesn't Need

Abstract

Description

Introduction

Go’s design is opinionated about simplicity. Implicit interfaces. No inheritance. “A little copying is better than a little dependency.” We know the proverbs.

But knowing them and practicing them are different things.

In 2024, I submitted a 94-line implementation to Ruby Core — a new class with 12 method overrides. The maintainer, Kou-san, asked two questions: “Do we need to override all class methods? Can we just override TSV#initialize?” My 94 lines became 6. Not through optimization — through realizing that inheritance already gave me everything. Most of my code had no reason to exist.

That review broke something in my brain. I went back to Go codebases I’d built — specifically the API layer for Hokusai, an NFT infrastructure platform on Polygon using go-ethereum — and started seeing the same disease everywhere. Not bad code. Working code. Code that passed tests and shipped to production. But code that didn’t need to exist.

This talk is a guided hunt through five specific Go patterns where we write code “just in case” — and what the codebase looks like after we delete it.

Talk Outline

Pattern 1: The Premature Interface (4 min)

Go’s implicit interfaces are powerful, but they create a trap: defining interfaces before you have multiple implementations.

I’ll show a real pattern from API development:

type TokenMinter interface { Mint(ctx context.Context, to common.Address, uri string) (*types.Transaction, error) }

type polygonMinter struct { … }

When polygonMinter is your only implementation, the interface adds indirection with zero benefit. Go’s implicit interfaces mean you can extract this interface LATER, when a second implementation actually exists. I’ll show the diff that removes the premature abstraction and how the code becomes easier to test, not harder.

Takeaway: “Don’t design for the second implementation until it arrives.”

Pattern 2: The Helper Package That Duplicates stdlib (3 min)

Building Go APIs for blockchain interaction, I created utility functions that wrapped standard library functionality with minor additions. Example:

// utils/strings.go func ContainsAny(s string, substrs …string) bool { … }

This exists in strings.Contains with a simple loop. I’ll show three categories of helper functions that commonly duplicate Go’s standard library: string manipulation, error formatting, and HTTP response helpers. Each with the stdlib alternative that makes the helper unnecessary.

Takeaway: “Before writing a helper, spend 5 minutes in pkg.go.dev.”

Pattern 3: The Error Type That Wraps Nothing (3 min)

Go’s error handling is verbose by design, and the community response is often to create custom error types. But many custom error types are just:

type APIError struct { Code int Message string }

func (e *APIError) Error() string { return fmt.Sprintf(“api error %d: %s”, e.Code, e.Message) }

When your custom error type doesn’t carry more information than fmt.Errorf would provide, it’s ceremony without value. I’ll show when custom error types earn their existence (sentinel errors for behavior-based checking with errors.Is/errors.As) versus when fmt.Errorf with %w is the correct choice.

Takeaway: “A custom error type must enable the CALLER to do something fmt.Errorf cannot.”

Pattern 4: The Middleware That Should Be Two Lines (3 min)

In HTTP API development, middleware chains accumulate. From building the Hokusai API’s HTTP layer, I’ll show a real pattern where a logging middleware, a recovery middleware, and a request-ID middleware were three separate functions — when Go’s http.Handler composition allows collapsing them. I’ll demonstrate the before (three middleware registrations, three files) and after (one handler wrapper, clearer control flow).

Takeaway: “Count your middleware. If removing one changes nothing in production, it shouldn’t exist.”

Pattern 5: The Struct Field Nobody Reads (3 min)

When building Go structs for API responses or internal state, fields accumulate over time. Using go-ethereum’s transaction receipt handling as context, I’ll show how response structs grow fields that are populated but never consumed by any caller. Go’s compiler won’t warn you. Only code review catches it.

I’ll show a technique: grep every field in your response struct for read access outside the struct itself. Fields with zero external reads are candidates for deletion.

Takeaway: “A struct field that is written but never read is dead code the compiler can’t see.”

Connecting the Patterns: The Subtraction Checklist (2 min)

All five patterns share a single question — the one Kou-san asked me about my 94 lines: “Does this need to exist?”

I’ll present a three-question checklist that Go developers can apply during code review:

1. Does this type/function/package have exactly one caller or implementation? → It might not need to be extracted yet.
2. Does this duplicate something in the standard library or an existing package? → Delete it and use the original.
3. If I remove this, does any test fail or any behavior change? → If not, it was already dead.

Conclusion (2 min)

Rob Pike’s Go proverbs describe a language designed for subtraction. Implicit interfaces mean you don’t declare what you don’t need. Composition over inheritance means you don’t inherit what you don’t use. No generics (until recently) meant you couldn’t abstract what didn’t demand abstraction.

But Go developers are still developers. We still write code “just in case.” We still create interfaces for one implementation, error types that wrap nothing, and helper packages that shadow the standard library.

The hardest skill in Go isn’t writing code. It’s opening a pull request that deletes code — and having the confidence that less is correct.

My 94 lines becoming 6 wasn’t a failure. It was the moment I understood what Go has been trying to tell us all along: the best code is the code that doesn’t exist.

Notes

SPEAKING EXPERIENCE: Speaker at DroidKaigi (Japan), DevFest Pescara (Italy), Helvetic Ruby (Switzerland), and Balkan Ruby (Bulgaria).

Videos of previous talks:

• DroidKaigi 2025: [REDACTED]
• Balkan Ruby 2025: [REDACTED]
• Helvetic Ruby 2025: [REDACTED]

GO EXPERIENCE: Backend Engineer at MonoBundle (モノバンドル株式会社), Tokyo — built Go APIs for Hokusai, an NFT infrastructure platform on Polygon (go-ethereum, GCP, Solidity). The APIs handled minting, transferring, and managing NFTs via smart contract interactions. Also built CI/CD pipelines. March 2022 – January 2023.

RUBY CORE CONTRIBUTIONS (the source of the “subtraction” framework):

• PR #319: 94 lines → 6 after Kou-san’s review (Ruby 3.3.1) [REDACTED]
• PR #346: 13 commits → 1 line change after 30 review comments [REDACTED]
• PR #1144: Ko1 said “the patch is too much” → reduced to String#scrub (Ruby 4.0) [REDACTED]

TRAVEL: Would appreciate travel sponsorship (travelling from [REDACTED], Japan).

^ back to index

53. The Journey to High-Durability Streaming: Building a Multi-Tiered Kafka Resilience SDK in Go

Abstract

Description

In high-throughput environments, standard retry logic is your first line of defense, but it’s rarely enough. What happens when a broker enters a “Gray Failure” state—where it is technically alive according to the control plane, but functionally useless to your producers?

This talk follows our journey of engineering a production-proven Kafka Resilience SDK in Go. We will explore how we moved beyond basic configurations to build a sophisticated, self-healing client. We’ll dive into how we strategically leveraged franz-go’s native Exponential Backoff and Adaptive Partitioner to “route around” degraded nodes, and how we architected a Multi-Tiered Fallback that automatically shunts data to a secondary cluster when the primary is unstable. Attendees will walk away with a practical blueprint for building high-availability streaming applications using modern Go ecosystems.

Notes

The Journey to Zero-Data-Loss: Building a Multi-Tiered Kafka Resilience SDK in Go

Abstract “Kafka is reliable… until it isn’t.” In high-throughput environments, standard retry logic is your first line of defense, but it’s rarely enough. What happens when a broker enters a “Gray Failure” state—where it is technically alive according to the control plane, but functionally useless to your producers? This talk follows our journey of engineering a production-proven Kafka Resilience SDK in Go. We will explore how we moved beyond basic configurations to build a sophisticated, self-healing client. We’ll dive into how we strategically leveraged franz-go’s native Exponential Backoff and Adaptive Partitioner to “route around” degraded nodes, and how we architected a Multi-Tiered Fallback that automatically shunts data to a secondary cluster when the primary is unstable. Attendees will walk away with a practical blueprint for building high-availability streaming applications using modern Go ecosystems.

The Problem: The Spectrum of Failure Reliability at scale requires preparing for “Gray Failures”—the “zombie” state where brokers maintain metadata sessions but fail to process events. We classify these into: Transient: Intermittent disruptions like leader re-elections. Gray Failure: Persistent degradation where the system appears “healthy” to monitors but “failed” to the application. Service Interruption: Total unavailability requiring a fallback to backup infrastructure.

The Solution: Orchestrating a Resilient SDK I will dive into the technical implementation of our SDK, focusing on how we orchestrated the high-performance features of franz-go to solve Tier-0 requirements: Leveraging Native Resilience: How we configured franz-go’s Exponential Backoff to survive transient blips and how we utilized the Adaptive Partitioner to monitor real-time latency and dynamically redistribute traffic away from “hot” or degraded partitions. The “Safety Net” Architecture: Beyond library features, I will explain how we built the Producer Data Fallback logic. This mechanism detects when the primary cluster is in an unstable state and automatically redirects traffic to a Secondary Kafka Cluster, ensuring zero data loss during major outages. Data Completeness: A look at the final fallback layer—sinking messages to S3 for offline processing when Kafka connectivity is entirely lost.

Verification: Chaos Engineering in Go A solution is only as good as its last test. I will share how we developed a Go-based load test frame integrated with chaos engineering to simulate broker failures and network partitions, verifying that our SDK maintains data integrity even when the primary cluster is under extreme stress.

Key Takeaways Mastering franz-go: How to effectively configure and extend modern Go libraries for mission-critical reliability. Solving Gray Failures: Practical strategies to detect and bypass partially degraded infrastructure in real-time. High-Availability Fallback: Designing a robust “Primary-to-Secondary” cluster fallback strategy within a Go SDK. Testing for Resilience: Insights into building Go-driven chaos-testing suites to validate your streaming logic.

^ back to index

54. The Local Brain: Building Fully Offline AI Systems with Go and Ollama

Abstract

Description

Most modern AI applications assume constant access to cloud-hosted language models. In many environments this is simply not acceptable. Financial institutions, government systems, and regulated industries often cannot send sensitive data outside their infrastructure.

What happens when AI must run completely offline?

This talk explores a practical architecture for building privacy-first AI systems where the entire pipeline runs locally.

Using Go as the backend orchestrator and Ollama for local model execution, we will build what I call a “Local Brain” architecture. The system runs a language model locally while the Go service manages data ingestion, retrieval, orchestration, and application logic.

Instead of relying on external APIs, the application interacts with a local inference runtime that keeps all data inside the organization’s infrastructure.

We will walk through a working example of an offline AI assistant designed for sensitive environments.

Topics covered include:

How to run and manage local LLMs using Ollama Designing a Go service that orchestrates local inference workflows Building a Retrieval Augmented Generation pipeline that runs entirely on local infrastructure Handling document ingestion, embeddings, and retrieval without cloud dependencies Operational considerations for running AI models in secure environments

The talk will include a live demonstration of a Go application interacting with a local LLM to answer questions over private documents without sending any data outside the machine.

The goal is to show that modern AI applications do not always require cloud models. In many cases, a carefully designed local architecture provides both privacy and performance.

Notes

Recordings of some of my previous conference talks:

React India 2025 [REDACTED]

React Kolkata [REDACTED]

I have also spoken at DevFests, CityJS World Series, and other international developer conferences and community meetups.

This talk is based on practical experimentation with local LLM infrastructure using Go as the orchestration layer and Ollama for local model execution. The session includes a live demonstration of a privacy-first AI workflow that runs entirely offline.

I have not presented this talk at other conferences yet.

No special assistance required. I will attend the conference in person.

^ back to index

55. The Lost Wakeup Bug: A Production Concurrency Failure and What sync.Cond Teaches Us

Abstract

Description

Many Go engineers rely on channels and mutexes for coordination. But under high concurrency, subtle race conditions can appear that aren’t caught by the race detector or tests. One such issue is the lost wakeup problem, when a goroutine misses a signal and sleeps forever.

In this talk, I’ll walk through a real production bug I encountered while building a resource pool. A seemingly correct design using sync.Mutex and channels led to a rare deadlock under load. The root cause was a classic lost-wakeup race - a signal was sent before the waiting goroutine actually started waiting.

We’ll dissect:

• why the bug occurs
• why channels alone don’t always model condition variables
• how sync.Cond works internally
• and how its atomic Wait() semantics prevent lost wakeups by ensuring a goroutine is on the wait list before releasing the lock.

Through step-by-step diagrams and code evolution, attendees will learn when to reach for sync.Cond, how to use it safely, and how to reason about coordination patterns in Go systems.

This talk is aimed at backend and systems engineers who write concurrent Go in production and want a deeper mental model beyond “channels everywhere”.

Notes

^ back to index

56. The Software Archaeologist: What Go Taught Me While Debugging Systems That Should Not Still Exist

Abstract

Description

Every engineer eventually encounters a system that feels like an ancient ruin.

The service has been running for years. It handles critical production traffic. Nobody fully understands why it works the way it does. The original authors are gone, the documentation is incomplete, and every change feels dangerous. Yet these systems keep running.

This talk explores the idea of software archaeology: the practical process of rediscovering how complex systems actually behave. Instead of treating legacy systems as technical debt, we approach them as artifacts that contain valuable design decisions hidden in the code.

Using Go as the lens, the talk walks through a set of techniques engineers can use to safely explore and understand systems that have grown beyond their original design.

Topics include:

How to reverse engineer the operational model of a Go service How to identify hidden invariants that keep systems stable How to build safe probes and experiments to understand behavior How to gradually evolve systems without rewriting them

Along the way we will examine real examples where small discoveries revealed the true reason a system behaved a certain way.

The surprising lesson is that many “legacy” systems are not poorly designed. They are simply misunderstood.

By learning how to read these systems like archaeologists, engineers gain a powerful skill: the ability to improve complex infrastructure without breaking the fragile things that keep it alive.

Notes

Recordings of some of my previous conference talks:

React India 2025 [REDACTED]

React Kolkata [REDACTED]

I have also spoken at DevFests, CityJS World Series, and other international developer conferences and community meetups.

This talk draws from practical experience working with long running production systems and infrastructure that evolved over several years. The session focuses on practical techniques engineers can use immediately when approaching unfamiliar or legacy systems.

I have not presented this specific talk at other conferences.

No special assistance required. I will attend the conference in person.

^ back to index

57. The things I find myself repeating about Go

Abstract

I’ve been a Go developer for going on 15 years. Over that time I’d written a lot of Go code, read a lot of Go code, and constantly tried to improve my own style to incorporate the best things I see in others’ code and to remove the worst parts of my own.

Seven years ago Peter Bourgon gave a talk entitled �Ways to do things� detailing his experiences building services in Go. This talk is my homage to Peter�s talk. I will discuss the techniques, patterns & tricks that I have found myself repeating as I have written Go in production for the last decade.

Description

The outline of this talk includes:

• Stylistic issues
• Use paragraphs to break up ideas
• Constants at the top; types in the middle, functions at the end
• Fewer files, fewer packages
• Divide packages by what their provide, divide files by what they import
• Naming is important
• Helpers to avoid negation
• Rather than writing a comment, name the function to make the comment unnecessary
• main.run pattern to make main.main less special.
• Keep to the left; use guard clauses, return early
• Initalise once and only once; use helpers to avoid the define then initialise idiom
• Writing fewer conditionals for more readable code
• Use switch rather than if/ else/ return
• Don�t repeat (your logic), write helpers.
• Replace loops with simple generic algos
• Never take or return two things of the same type and how to avoid it

And a conclusion which attempts to argue the affirmative that the Sapir-Whorf hypothesis does apply to Go code.

Notes

^ back to index

58. Transpiling Go to Rust and Others

Abstract

Description

Have you ever implemented the same logic twice because one component was written in Go and another in a different language? This is a common problem in polyglot    systems, and existing solutions — C bindings via FFI, IDL-based code generation, or transpilers like HAXE — each come with significant trade-offs: adoption   barriers, serialization overhead, or the need to learn an entirely new language.

  This talk introduces a different approach: using Go itself as the source language for cross-language transpilation. https://github.com/pdelewski/goany is not a   theoretical exercise — it is a working project that already transpiles Go code to five target languages. During this session, I will show practical examples of   transpiled code, including a C64 emulator and a GUI demo running in the browser, and walk through the design decisions behind building such a tool. But building    a transpiler is only half the challenge — the other half is deciding what to transpile.

  I will cover:

  - The problem: why reusing logic across language boundaries remains painful, and why existing approaches (FFI, Protobuf/gRPC, HAXE, FusionLang) fall short in   certain scenarios   - Why Go is a great fit: its small, well-defined spec, comprehensive standard library, and strong tooling make it an ideal transpilation source — unlike custom   languages, every goany program is a valid Go program   - Designing the subset — what to include and why: the guiding principle behind goany’s subset is to include only constructs that produce nearly one-to-one   correspondence between input and output in every target language. I will walk through the reasoning behind what made the cut (primitives, slices, structs,   multiple returns, methods, loops, conditionals) and what was deliberately left out (goroutines, generics, interfaces) with examples of how each decision affects    the generated code. The subset is intentionally a work in progress — it started minimal and is gradually expanding as new constructs prove they can be mapped   cleanly across all targets   - How goany works: a walkthrough of the transpiler architecture — parsing Go’s AST, mapping the chosen subset to target language constructs, and producing   readable output in C++, C#, Rust, JavaScript, and Java   - Live demos: a C64 emulator and a GUI application running in the browser via JavaScript transpilation, demonstrating that this focused subset is already   sufficient to build non-trivial, real-world applications   - Challenges: dealing with memory model differences, producing idiomatic output, and the ongoing tension between expanding the subset and maintaining clean   transpilation

  The key insight of this talk is that designing a transpiler subset is not about supporting as many features as possible — it is about finding the largest common    denominator across target languages, and evolving that denominator over time as you learn what works. Attendees will walk away with a concrete framework for   thinking about cross-language compatibility, practical knowledge of building tools on top of Go’s AST packages, and a new perspective on how Go’s deliberate   simplicity enables use cases that more complex languages cannot.

Notes

^ back to index

59. Understanding Escape Analysis in Go - How Variables Move Between Stack and Heap

Abstract

Description

As a seasoned Go developer responsible for developing and maintaining a registrar backend to handle connections with about 40 registries and about 1k req/min I have to make sure the system is always well handled and performant. In order to make sure of it, escape analysis is a key part in it that I had to consider in it.

• Why Escape Analysis Matters The Go compiler automatically decides where variables lives on the stack (fast, automatically freed) or heap (managed by GC, slower). While many developers never think about memory allocation, understanding escape analysis can be crucial for performance-sensitive code paths. Excess heap allocations increase garbage collection pressure and can slow down applications.

• What Escape Analysis Is Escape analysis is a static compiler optimization that analyzes whether a variable can safely be kept on the stack. If a variable’s address escapes the function scope for example because it is returned or stored for later use the compiler must allocate it on the heap.

• Code Walkthrough with Examples We’ll explore key patterns that force heap escapes or keep data on the stack:

1. Simple value return vs pointer return
2. Passing pointers and how this affects escape decisions
3. Why local pointers sometimes don’t escape Each example will include the -gcflags="-m" output to show the compiler’s reasoning.

• How to Inspect Escape Behavior in Your Code Attendees will learn how to use go build -gcflags="-m" to see escape analysis annotations. We’ll interpret compiler messages and explain how they map to code behavior.

• Practical Tips to Reduce Unnecessary Heap Allocations Beyond theory, the talk will cover actionable advice:

1. Prefer returning values instead of pointers when possible
2. Be mindful of interfaces and closures that may cause escapes
3. Understand allocations in hot paths and optimize where it matters

Notes

^ back to index

60. Understanding Optimization Algorithms Through Go

Abstract

Description

The Problem

Most developers use optimization libraries as black boxes. Python’s PuLP lets you write x + 2*y <= 30 and get an answer—but do you understand how the Simplex algorithm finds that answer? When the solver fails, can you debug it?

I couldn’t. So I implemented linear programming in Go, where nothing is hidden. The journey transformed my understanding of optimization algorithms.

What You’ll Learn

1. The Black Box Problem (3 min)

• What high-level libraries hide from you
• Why “it just works” becomes “why doesn’t it work?”
• Go’s philosophy: explicit is educational

2. Simplex Algorithm Step-by-Step (8 min)

• The math behind linear programming (visual explanation)
• Translating math to Go with gonum
• Live walkthrough: Factory optimization problem
  • Problem: Maximize ¥10,000x + ¥20,000y
  • Constraints as matrices (no operator magic)
  • Watching the algorithm iterate to solution (x=18, y=4)
• What each line of Go code actually computes

3. Learning Through Explicitness (5 min)

• Side-by-side: PuLP’s 5 lines vs Go’s 20 lines
• Why more code = more understanding
• Debugging intuition you can’t get from Python
• Hand-calculating one Simplex iteration (live demo)

4. Taking This Further (4 min)

• Applying this learning method to other algorithms
• gonum’s broader toolkit for numeric exploration
• Resources for your learning journey

Key Takeaways

1. Go’s explicitness transforms implementation into education
2. Understanding algorithms beats memorizing library APIs
3. The intuition you build transfers to any language

Why This Talk?

I documented my learning journey from “call the library” to “understand the math,” including hand-calculated Simplex iterations. This talk shares the educational approach that made optimization click for me—using Go as the teaching tool.

Notes

^ back to index

61. Value Canonicalization in Go

Abstract

Description

Main idea: The ‘unique’ package solves two related problems—redundant memory allocations and expensive O(N) string comparisons—by storing only one copy of each distinct value and returning handles that compare in O(1) time via pointer equality.

Questions this talk answers:

• Why is string comparison expensive? Go strings are compared byte-by-byte. Two identical 1MB strings require scanning all 1 million bytes. With ‘unique.Handle’, the same comparison is a single pointer check: 0.31 nanoseconds vs 1.3 milliseconds.

• How does it avoid memory leaks? The package uses weak pointers internally. When no handles reference a value, it becomes eligible for garbage collection automatically. No manual cleanup required.

• When should I use it? High duplication rate (>30% repeated values), frequent comparisons, or memory pressure from redundant strings. Poor fit: unique values, short-lived data, or forgetting to store handles (defeating the purpose).

• What’s the gotcha with pointer fields? Structs containing pointers compare pointer addresses, not pointed-to values. Two structs with ‘*string’ fields pointing to equal strings but different addresses produce different handles.

Attendees will understand when interning helps vs. hurts (with benchmarks showing the crossover points), learn the internal weak pointer mechanism, and see how ’net/netip.Addr’ uses ‘unique’ to efficiently represent IP addresses—the real-world case that motivated the package after a 10-year journey from Issue #5160.

Notes

blog: [REDACTED]

From a few 2025 events: Golab: [REDACTED] (videos are not online yet) Golang X Conf: [REDACTED] Gophercon India: [REDACTED] GopherCon Africa: [REDACTED] (videos are not online yet) Keynote of GopherCon LATAM (Portuguese): [REDACTED]

^ back to index

62. Weak Pointers in Go: Implementation Deep Dive

Abstract

Description

Main idea: Go’s weak pointer uses an 8-byte indirection object between the weak pointer and the target. The weak pointer holds a pointer to this indirection object (not to the target). When the target dies, the GC zeros the indirection object’s pointer field—but the indirection object itself survives. This is why ‘wp1 == wp2’ stays true after collection: both still point to the same indirection object.

Questions this talk answers:

• Why the indirection layer? Without it, you have a race: the GC wants to collect the object while user code reads the weak pointer. With indirection, the GC atomically zeros one pointer (in the indirection object), and user code atomically reads it. No races, no locks needed on the hot path.

• How does the handle table work? Creating a weak pointer for the same object twice must return equivalent weak pointers (same indirection object). The runtime maintains a table mapping objects to their indirection objects. This uses the object’s address as a key, with careful handling when objects move during GC.

• Why is generics required? Before Go 1.18, a type-safe weak pointer API would need one function per type or use ‘interface{}’ everywhere. Generics enable ‘weak.Pointer[T]’ where ‘Value()’ returns ‘*T’ without casts. The implementation uses unsafe internally but presents a safe API.

• How does the GC integration work? The GC must zero indirection objects for dead targets but not follow weak pointers as roots. This requires special handling in the mark phase: indirection objects are tracked separately, and their target pointers are processed in a second pass after determining liveness.

• What makes the equality guarantee possible? Indirection objects are never freed while any weak pointer references them. They form a secondary lifetime: the target can die, but the indirection object persists until all weak pointers to it are gone. This is tracked via reference counting on the indirection objects.

Attendees will understand the implementation well enough to read ‘src/runtime/weak.go’ themselves, know why each design decision was made (indirection for races, handle table for deduplication, generics for type safety), and appreciate how the equality guarantee—unique to Go—enables patterns impossible in Java or Python where weak references become incomparable after collection.

A possible adaptation for intermediate-level :

For an intermediate audience, the talk balances why weak pointers exist with how to use them effectively, without diving into runtime implementation details. I’d start with the 15-year history—why Go resisted, what changed, to give context for the design constraints. The core content would cover the two-method API (Make and Value), the mental model of the indirection layer (without implementation details), and the equality guarantee as a feature to rely on rather than a mechanism to understand. Practical patterns get significant time: building a WeakCache that shrinks under memory pressure, implementing canonical maps for deduplication, and the observer pattern without preventing cleanup. The talk would address common mistakes: checking Value() twice (the object could die between checks), forgetting that weak pointers don’t prevent collection (obvious but often misunderstood), and when not to use weak pointers (short-lived objects, low memory pressure). Attendees would leave able to implement weak-pointer-based caches and understand when weak pointers solve their problem vs. when a regular cache with eviction policy is simpler.

Notes

blog: [REDACTED]

From a few 2025 events: Golab: [REDACTED] (videos are not online yet) Golang X Conf: [REDACTED] Gophercon India: [REDACTED] GopherCon Africa: [REDACTED] (videos are not online yet) Keynote of GopherCon LATAM (Portuguese): [REDACTED]

^ back to index

63. What Really Happens When You Run 'go func()'

Abstract

Description

Go’s concurrency model is famously simple - write go fn() and you get concurrency. But behind that single keyword lies a sophisticated runtime scheduler responsible for managing millions of goroutines efficiently.

This talk explores what actually happens when a goroutine is launched and how the Go runtime schedules, executes, blocks, and resumes them. We’ll walk through the architecture of the Go scheduler using the M:P:G model, where goroutines (G) are scheduled onto operating system threads (M) through logical processors (P).

We’ll trace the lifecycle of a goroutine from its creation via runtime.newproc, through the per-P run queues, and into the scheduler loop (schedule() and findrunnable()).

Along the way we’ll examine how the runtime balances work across processors using work stealing, and how it handles goroutines that block on syscalls, network I/O via the netpoller, or synchronization primitives like channels.

We’ll also look at goroutine memory management, including their growable 2KB stacks, stack expansion via morestack, and how the runtime implements cooperative preemption introduced in Go 1.14.

By the end of the session, attendees will have a clear mental model of how Go’s runtime scheduler operates and how to use Go tooling (schedtrace, go tool trace, and pprof) to analyze and debug highly concurrent systems.

Notes

OUTLINE:

1. The Illusion of Simplicity

• The magic of go fn()
• Why runtime internals matter for high-concurrency systems

2. Goroutines Under the Hood

• The g struct
• 2KB growable stacks
• stack growth (morestack)

3. The M:P:G Scheduler Model G: goroutine M: OS thread P: processor context

M:N scheduling in Go

4. Lifecycle of a Goroutine

• go fn() → runtime.newproc
• Per-P run queues
• schedule() and findrunnable()
• Work stealing between Ps

5. What Happens When Goroutines Block

• Blocking syscalls
• netpoller for network I/O
• channel operations (sudog queues)
• parking/unparking goroutines

6. Observing the Scheduler

• GODEBUG=schedtrace
• go tool trace
• debugging real systems

7. Key Takeaways

• goroutines are cheap but not free
• scheduler behavior affects performance
• tooling reveals runtime behavior

PREVIOUS SPEAKING ENGAGEMENTS:

🇸🇬 Go Singapore Meetup (Sept 2021) 🇮🇹 GoLab 2022 🇺🇸 GoWest Conf 2022 🇮🇳 GopherCon India 2023 🇮🇳 GopherCon India 2025

^ back to index

64. When `(a, b int)` Breaks: A GoLand Support Diary

Abstract

Description

Abstract: We’ve all been there: you trigger a “Change Signature” refactoring, trusting the IDE to do the heavy lifting. You expect a clean, compiling result. But then - bam! - the tool “forgets” a type, and your code is suddenly a sea of red.

In this 20-minute deep dive, we’ll go behind the curtain of a real-world engineering challenge at JetBrains. We’ll dissect a specific case where Go’s elegant syntax - specifically grouped parameters like (a, b int)- collided with the complex logic of automated code transformation.

As a member of the GoLand QA and Support team, I’ll show you why what seems like a “small oversight” in refactoring is actually a fascinating puzzle of logic, syntax trees, and edge cases.

What we will explore:

• The Logic of Transformation: Why adding a single parameter can unexpectedly break the grouping of types (e.g., leaving variables untyped), and the algorithmic journey to solving it.
• The Support-Driven Flywheel: How “annoying” bug reports from the community directly shape the IDE roadmap and lead to core structural fixes in our latest releases.

This isn’t just a talk about a single bug fix. It’s a story about the relationship between Gophers and their everyday tools. You’ll leave with a new perspective on how your IDE “thinks” under the hood, and why your feedback is the secret ingredient in making Go tooling more reliable for everyone.

Notes

^ back to index

65. When Tests Become Slot Machines: Deterministic Concurrency with synctest

Abstract

Your concurrent test passed 47 times. Then it failed. You ran it again. It passed. Congratulations, you now have a slot machine.

This talk shows how synctest creates isolated “bubbles” where time is fake, goroutines can be observed at rest, and “this should not have happened” becomes testable.

Description

Main idea: The ’testing/synctest’ package creates isolated “bubbles” where time is fake and goroutines can be observed at rest. Inside a bubble, ’time.Sleep(1*time.Hour)’ completes in microseconds, and ‘synctest.Wait()’ returns only when all goroutines are “durably blocked”, waiting on channels, timers, or mutexes with no way to proceed without external input.

Questions this talk answers:

• Why can’t time.Sleep prove a negative? To test “nothing happens for 5 seconds,” you’d sleep 5 real seconds. But that doesn’t prove nothing happened, it proves nothing happened yet. And if you sleep too short, you get flaky failures. synctest solves this: fake time advances instantly, and ‘Wait()’ tells you when all goroutines have stabilized.

What is “durably blocked”? A goroutine is durably blocked when it’s waiting on something that won’t resolve without external action: a channel receive with no sender ready, a timer that hasn’t fired, a mutex held by another blocked goroutine. ‘synctest.Wait()’ returns when ALL bubble goroutines reach this state. This is deterministic—no timing assumptions needed.

How does fake time work? Inside a bubble, ’time.Now()’, ’time.Sleep()’, ’time.After()’, and ’time.Timer’ all use simulated time. The runtime advances this clock when goroutines are durably blocked on timers. A test can “sleep” for hours without burning wall-clock time.

What are the limitations? Real I/O (network, disk) involves goroutines outside the bubble—they won’t be tracked. Subtests create separate bubbles. Global goroutines (started before the bubble) aren’t isolated.

Attendees will know how to convert flaky tests to deterministic ones (with before/after examples), understand the “durably blocked” concept that makes it work, and recognize when synctest won’t help. Tests that took 20 minutes with sleep-based synchronization now run in milliseconds.

Beginner-level adaptation:

For a beginner audience, the talk would focus on the problem (flaky tests) and the solution (replace time.Sleep with
synctest.Wait) without diving into runtime mechanics. I’d start by showing a real flaky test that passes 9 times out of10, then fails mysteriously in CI—a pain point every Go developer recognizes.

The core message: time.Sleep(100*time.Millisecond) is a guess, synctest.Wait() is a guarantee. Code examples would show simple before/after transformations: replace sleep with Wait, wrap the test in synctest.Run, done. The talk would cover the three things to remember: time is fake inside the bubble, Wait returns when goroutines have nothing to do, and real I/O breaks the isolation. Attendees would leave able to convert their existing flaky concurrent tests to deterministic ones using a mechanical pattern.

Advanced-level adaptation:

For an advanced audience, the talk would explore how synctest’s bubble abstraction is implemented in the runtime and its edge cases. I’d examine how the runtime tracks goroutines belonging to a bubble, how fake time is implemented (the faketime clock, timer heap manipulation), and the precise definition of “durably blocked”, blocked on a channel with no ready sender/receiver, a mutex held by another durably blocked goroutine, or a timer in fake time.

The talk would cover subtle failure modes: why a for { select { default: } } loop hangs Wait forever (never durably blocked), howruntime.Gosched() differs from blocking, and why goroutines started before the bubble aren’t tracked. I’d also examine testing strategies for code that mixes real I/O with timers, how to structure tests when bubble isolation isn’t enough, and the implementation differences between synctest.Run and synctest.Test. Attendees would leave understanding the runtime machinery well enough to debug when Wait hangs unexpectedly and design testable concurrent APIs from the start.

Notes

blog: [REDACTED]

From a few 2025 events: Golab: [REDACTED] (videos are not online yet) Golang X Conf: [REDACTED] Gophercon India: [REDACTED] GopherCon Africa: [REDACTED] (videos are not online yet) Keynote of GopherCon LATAM (Portuguese): [REDACTED]

^ back to index

66. Why Go Hides Its Spinlocks

Abstract

Description

Main idea: A waiting goroutine can either spin (loop checking the lock, burning CPU) or park (yield to the scheduler, pay context switch overhead). Go’s ‘sync.Mutex’ already spins internally (up to 4 iterations) before parking. The runtime uses the “spinbit” design: only ONE goroutine can spin at a time, preventing thundering herd problems.

Questions this talk answers:

When does spinning beat parking? Spinning wins when the critical section is shorter than a context switch (~1-2 microseconds). For sub-100ns critical sections on multi-core systems with low contention, spinning avoids scheduler overhead entirely. For anything longer, parking wins because you’re just wasting cycles.

What does x86 PAUSE do? PAUSE is a hint that tells the CPU “I’m in a spin loop.” It reduces power consumption, avoids memory order violations on speculative execution, and prevents the spinning core from flooding the memory bus with lock reads. Without PAUSE, spin loops can actually slow down the lock holder.

How does sync.Mutex spin? The runtime’s ‘runtime_canSpin’ function checks: Are we on a multi-core machine? Have we spun fewer than 4 times? Is there an idle P available? Is the current goroutine’s run queue empty? If all conditions are met, the goroutine spins briefly before parking.

What’s the spinbit? A single bit in the mutex state that says “someone is already spinning.” When set, other waiters go directly to sleep. This prevents N goroutines from all spinning simultaneously—only one burns CPU while others wait efficiently.

Why no SpinMutex in the standard library? Pure spinlocks are almost never the right choice in Go. Goroutines are cooperatively scheduled; a spinning goroutine can prevent the lock holder from running on the same P. The adaptive approach in ‘sync.Mutex’ handles the common cases correctly.

Attendees will understand when Mutex spins vs. parks, why pure spinlocks usually hurt Go programs, and the rare scenarios (sub-100ns critical sections, known multi-core, low contention) where custom spinning might help.

A possible beginner-level adaptation:

For a beginner audience, the talk would focus on the intuition behind spinning vs. parking rather than hardware details. I’d use the analogy throughout: spinning is pacing by the door waiting for a package, parking is taking a nap and asking to be woken up. The key insight is that both have costs: spinning wastes energy, and napping takes time to wake up. The talk would cover why sync.Mutex is almost always the right choice (it already handles the trade-off internally), demonstrate what happens when you write a naive spin loop (CPU spikes, other goroutines starve), and show the one-liner check to see if lock contention is your problem (go tool pprof mutex profile). Attendees would leave understanding why they shouldn’t write their own spinlock and how to diagnose if sync.Mutex is a bottleneck in their application.

A possible advanced-level adaptation:

For an advanced audience, the talk would dive into the hardware and runtime implementation. We’d examine x86 PAUSE semantics (pipeline flush, memory-order implications, power reduction), how cache-coherence protocols (MESI) make naive spinning flood the memory bus, and the exact assembly Go generates for sync.Mutex.Lock. The talk would walk through runtime.lock2 and runtime_canSpin source code, explaining each heuristic: why 4 spin iterations, why check for idle Ps, why the run queue must be empty. We’d benchmark different spin strategies (exponential backoff, TTAS vs. TAS, ticket locks) and show when each wins. The spinbit design would get detailed treatment: how one bit prevents thundering herd, why it’s set/cleared atomically with the lock state. Attendees would leave able to read and modify src/runtime/lock_futex.go and make informed decisions about custom synchronization primitives for extreme performance scenarios.

Notes

blog: [REDACTED]

From a few 2025 events: Golab: [REDACTED] (videos are not online yet) Golang X Conf: [REDACTED] Gophercon India: [REDACTED] GopherCon Africa: [REDACTED] (videos are not online yet) Keynote of GopherCon LATAM (Portuguese): [REDACTED]

^ back to index

67. Yes, It Runs Doom: Building a WebAssembly VM in Go from scratch

Abstract

Description

In my journey to learn WebAssembly I’ve decided to build a VM from scratch in Go and pushed it far enough to run Doom. This talk is a systems-programming case study focused on runtime design in Go.

I’ll cover the Wasm runtime components (module, stack machine, call frames, control flow, linear memory), and how to make native function calls, and explain the implementation decisions that made the runtime practical. The goal is not to provide a full Wasm spec walkthrough, but to give a clear, concrete view of how a Wasm VM is built in Go.

Using Doom as a target changed the project significantly: it exposed missing runtime behaviors, invalid assumptions, and performance bottlenecks that toy modules never reveal. I’ll show how I approached debugging, and how Go’s built-in tooling (pprof, benchmarks) guided optimization in the hot path.

I’ll also highlight the Go-specific features, and design choices that made the VM easier to implement, like:

• Code reuse on numeric instructions thanks to union type constraints
• Enabling native function calls from VM by using reflections
• Using unsafe pointer casting for performance
• Manually unrolling loops for performance
• State serialization using encoding/gob
• Bit manipulation using math/bits

Notes

This talk is a Go systems-programming case study, not just a novelty demo. Doom is the hook, but the core value is a practical, implementation-first walkthrough of building a WebAssembly VM in Go: parsing, validation, execution, memory, host integration, debugging, and performance tuning. It’s useful Go developers even if they’ve never built a VM before.

I’ll keep the session tightly scoped for the extended format, with a clear arc (intro, architecture, runtime, real-world issues, profiling/optimization, lessons learned) and concrete takeaways attendees can apply to other systems-oriented Go projects.

I also have past experience as speaker, like the meetups of the CodeCon conference: [REDACTED] And also as speaker and organizer of a local meetup: [REDACTED]

^ back to index

68. Your Tests Pass, But Do They Work? Mutation Testing in Go

Abstract

Description

Continuous Integration (CI) has become a standard practice in modern software development - verifying that changes meet quality standards before code is merged. With the rise of generative AI accelerating the development cycle, CI has become even more critical. Go provides a rich set of tools for this: linters like go vet, unit tests, benchmarks, and fuzz testing via go test, making it straightforward to build a CI pipeline that maintains a baseline of code quality at low cost.

But how do we know we’re writing good tests? How can we tell whether our tests meaningfully verify behavior, or whether they simply increase coverage numbers? A test that calls a function and discards the result still contributes to coverage. You can achieve 100% coverage with zero assertions.

This session proposes mutation testing as an answer to this question. Mutation testing intentionally introduces small changes to your source code - flipping operators, removing branches, swapping conditions - and checks whether your tests catch the change. If they do, the mutant is “killed.” If they don’t, it “survived,” exposing a gap in your test suite.

Through this session, attendees will learn how mutation testing can be applied to evaluate and improve test quality, and how to implement it in Go by leveraging the go/ast package to generate mutants from source code and the go test -overlay flag to run mutated code in parallel without ever modifying original files.

Talk outline:

1. (3 min) CI in modern development

   Why CI has become the standard quality gate in team development. How generative AI is accelerating the development cycle and making CI even more essential as the checkpoint for automated quality assurance.

2. (4 min) Go’s testing ecosystem and the coverage trap

   Overview of Go’s built-in quality tools: go vet, go test, benchmarks, and fuzzing. Then I’ll demonstrate how coverage can be misleading - showing a 100% covered test with zero assertions, and how AI-generated tests can game coverage using patterns like t.Skip. This introduces Goodhart’s Law: when a measure becomes a target, it ceases to be a good measure.

3. (4 min) Mutation testing fundamentals

   What mutation testing is and how it works. I’ll explain the core concept of intentionally rewriting source code (flipping operators, removing branches, swapping conditions) and the evaluation model: if a test fails the mutant is KILLED (good), if it passes the mutant SURVIVED (bad).

4. (7 min) Implementing mutation testing in Go

   The main technical section. I’ll walk through how to parse Go source files into an AST, identify mutable nodes using ast.Inspect, and generate mutants with a CanMutate/Mutate pattern. Then I’ll explain how go test -overlay enables running mutated code without modifying original files, and why this makes parallel execution with goroutines safe. I’ll also cover incremental analysis for CI - running mutation tests only on changed files in a pull request.

5. (2 min) Trade-offs and wrap-up

   When mutation testing is worth the cost, how to handle equivalent mutants, and a reminder that mutation scores themselves are subject to the same Goodhart’s Law trap.

Notes

^ back to index

69. Zero Distance to Customer: Implementing Intelligent Business Agility with Value Flow, AI, and Hamoniq

Abstract

Description

Many organizations stop at surface-level Agility, optimizing individual team processes but struggling to scale true value. [REDACTED] addresses this challenge with a radically different paradigm shift: it aims for a natural and organic development where Artificial Intelligence permeates every organizational aspect. We are not talking about AI as a simple, isolated “tool,” but as connective tissue that supports and amplifies decision-making at every level of the company.

In this talk, we will explore how to rethink value structure by drawing inspiration from Haier’s revolutionary RenDanHeYi model. We will see how the concept of “Zero Distance” (the seamless connection between employee and customer needs) finds its ultimate expression exactly when AI eliminates cognitive and operational silos through fluid Value Flow management.

However, we won’t stop at theory. Using Hamoniq, we will demonstrate how this ubiquitous and natural integration of AI becomes an operational reality. We will analyze real-world case studies to show how artificial intelligence helps map, measure, and predictively optimize the value stream across the board, creating an ecosystem where teams operate as autonomous, highly outcome-focused micro-enterprises.

What you will take away from this session:

Mindset: Understand how [REDACTED] naturally integrates AI into the organizational DNA, moving beyond traditional Agile.

Inspiration: Learn how to adapt RenDanHeYi principles (micro-enterprises, zero distance) to revolutionize your Value Flow through data.

Pragmatism: Real-world case studies on enabling this transformation, using Hamoniq and AI as the central nervous system to measure and scale value.

Notes

^ back to index