In Go it’s trivia to start a goroutine, but, as I’m fond of saying, do you know when that goroutine will stop? How will it stop it? How will you know when it has stopped?

This is a talk about a solution I find myself rewriting on pretty much every backend Go service I work on. Even in a microservice shop, the requirement to set up a bunch of parallel goroutines is ubiquitous.

This is a story about concurrency vs parallelism, the places where it exists today in the std lib and where it does not, the patterns that evolve from that statement, and an introduction to the group type, an idea which has evolved since the Juju days a decade ago of William Reade’s Manifold, through Peter Bourgon’s “How I do things” talk, and through many of my own iterations.

Generic methods would allow us to write chaining APIs. This is particularly important for functional iterator patterns, which currently have to stretch over multiple lines, or be awkwardly nested. It would also allow us to properly attach generic code to the type it belongs to. An example is func N[T constraints.Integer](n N) N in package rand: It makes it easier to choose a random time.Duration, for example. But it should really be a method on *rand.Rand.

So no one really contests that it would be useful to have this feature. Even the Go team largely agrees. But the omission was intentional. The reasons for it stretch all the way back, to even before Go’s first open source release. In fact, it might be the reason we even got generics at all.

I walk through the uses of this feature, the reasons adding generics took so long and how they lead to this omission.

At Grab, our Go monorepo powers over 600 microservices and centralises shared libraries, but frequently used commands like go list and go get created significant bottlenecks. These commands overwhelmed our GitLab servers, leading to frustrated developers, disrupted CI pipelines, and constant fire-fighting by the GitLab team. To address this, we implemented Athens, a private Go module proxy, combined with GOVCS environment variable configurations and fallback network mode. This approach offloaded dependency-fetching requests from GitLab, drastically reduced server load, and improved dependency-fetching speeds for developers.

In this talk, we’ll explain how using a private Go module proxy enhances security, ensures module availability (think “left-pad” incident), and avoids the downsides of vendoring. Attendees will gain insights into setting up private proxies, using Athens in secure or offline environments, and scaling dependency management in large monorepos. Learn how we improved productivity and reliability at Grab, and discover how your organisation can do the same.

The evolution of GenAI applications brings with it the challenge of developing testing methods that can effectively evaluate the complexity and subtlety of responses generated by advanced artificial intelligences.

The proposal to use an LLM as a Validator Agent represents a promising approach, paving the way towards a new era of software development and evaluation in the field of artificial intelligence. Over time, we hope to see more innovations that allow us to overcome the current challenges and maximize the potential of these transformative technologies.

This proposal involves defining detailed validation criteria and using an LLM as an “Evaluator” to determine if the responses meet the specified requirements. This approach can be applied to validate answers to specific questions, drawing on both general knowledge and especialised information. By incorporating detailed instructions and examples, an Evaluator can provide accurate and justified evaluations, offering clarity on why a response is considered correct or incorrect.

In this session we’ll leverage langchaingo to interact with LLMs, and Testcontainers Go to provision the runtime dependencies to use RAG.

Working with mocks is a lot like working out: if you don’t know what you’re doing then you’ll either a) don’t get the results you want or b) hurt yourself. And in the worst case, you’ll get both and be unhappy with the results and swear off mocking as a useless practice.

This talk will show some common pitfalls of using mocks (updating a lot of mocks to return the new correct value, mocking out the same complex thing again and again, elaborate setups to exercise a piece of business logic, and more) and how you can constrain how you work with mocks to make them work for you and make your test suite something you’ll love to maintain.

No matter where you are on the spectrum of “mock everything to don’t mock at all,” you’ll get more confidence in your test suite, make it simpler to maintain, and very likely faster to run by being intentional in how you design your test suite and work with mocks.

We’ve been building a brand-new, Prometheus-compatible query engine from the ground up for Grafana Mimir in Go.

Our new query engine has been designed to deliver an improved user experience and vastly improved performance: our benchmarks show queries running up to 80% faster and with 70% lower peak memory consumption than Prometheus’ default engine, and our real-world testing shows similar results.

As we’ve been building the engine, we’ve learnt a number of Go performance lessons the hard way, including why using byte slices can sometimes be preferable to strings, the benefits and costs of memory pooling and the surprisingly large impact of function pointers. And we’ve seen the complexity (and bugs!) these things can introduce too, and developed a number of techniques to help combat this.

In this fast-paced interactive keynote, we will Go from the incredibly small to as far as our imaginations can take us.

By the end you will have shared a true ‘out of the box’ experience.