Concurrency patterns, performance trade-offs, and Go code you can reason about.
18 published entries
These series give this subject an intentional reading order.
A practical reading order for concurrency in Go: how work starts, moves, stops, and stays bounded.
See the 11-part reading order →After compile-time instrumentation with otelc and the three instrumentation paths comparison, you have spans and metrics leaving your service. The next decision is what happens to that telemetry before it reaches your backend.
Go now has three complementary paths to OpenTelemetry telemetry:
OpenTelemetry Go Compile-Time Instrumentation v1 lets you swap go build for otelc go build and get traces, metrics, and log correlation with zero source changes. No wrappers, no SDK init, no agent at startup. A SIG formed by Alibaba and Datadog, with maintainers from Cabify. Vendor-neutral, stable.
Goroutines are cheap. Channels are simple. The hard part is choosing which pattern fits the problem you actually have — and knowing, when you outgrow it, what comes next.
Every goroutine you spawn is a promise that something will eventually stop. If you don’t control when that happens, you leak intention: your program keeps doing work nobody asked for, long after the caller moved on.
Goroutines and async/await solve the same problem. They start from opposite assumptions about who you trust: the runtime, or your future self. Everything else about Go and C# concurrency flows from those two starting positions.
That line sat in the FAQ like a monument. It wasn’t a “not yet.” It was a “never.” And for years, every time someone opened an issue asking for type parameters on methods, that quote was the mic drop that ended the conversation.
Sometimes, the hard part of concurrent programming is not making things run in parallel. The hard part is keeping the flow of data understandable.
While the standard Worker Pool pattern is powerful, Go’s flexibility allows for alternative approaches to concurrent task processing. This article explores the Shared Semaphore method and discusses the use of third-party libraries for managing concurrency in Go applications.
The Worker Pool pattern is a fundamental concurrency design in Go that efficiently manages a pool of worker goroutines to process tasks from a shared queue. This pattern excels at handling a large number of independent tasks concurrently while maintaining precise control over system resources and performance.
The introduction to the Generator pattern covered the mechanics: a function returns a receive-only channel, a goroutine sends values, the caller ranges over them. This article is the next step — two applications where generators earn their keep: generating test data for a web service, and composing generators into a streaming pipeline.
The Generator pattern in Go is a powerful concurrency pattern used to create functions that produce a sequence of values. It leverages Go’s goroutines and channels to generate data asynchronously, providing an elegant way to work with streams of data or implement iterators.
In our previous article, we explored the fundamentals of the Producer-Consumer pattern in Go. Today, we’ll take it a step further by examining more practical scenarios and introducing buffered channels - a powerful feature that can significantly improve your concurrent applications.
The Producer-Consumer pattern is a fundamental concurrency pattern in Go that elegantly separates the production of data from its consumption. By using channels as intermediaries, this pattern creates a robust foundation for concurrent data processing.
Before delving into the main topic, I want to express my respect for the original post’s intent. My response aims to provide slight corrections that can benefit readers seeking accurate information. In the spirit of shared learning, I intend to contribute constructively rather than criticize. <br />Clarifications and alternative viewpoints can foster a deeper understanding of complex concepts. Let’s continue engaging in open discussions, embracing diverse insights as we collectively refine our knowledge.
This is a simple example of how to use goroutines to parallelize a merge sort algorithm. We compare the performance of a simple merge sort algorithm with a parallel merge sort algorithm that uses goroutines.
This is a simple example of why goroutines might be overkill for some tasks and less efficient than a simple function.
In this article, I will present the different steps that led me to optimize the deployment of services in golang using docker.