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.

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.

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.