For those that aren't aware, one of the big changes in February's upcoming Go 1.24 release is the new go tool command, and tool directive in the go.mod to manage any tools your project uses. I'm incredibly excited about this, and in my opinion, this is one of the best changes we've had in recent years in the ecosystem as a whole.

At Oodle's inception, we faced a common dilemma: choosing the right technology stack to get started. With a small team proficient in Go and a big vision, we needed a language that could handle everything from application development to infrastructure management. After careful consideration, we chose Go, and it has proven to be our Swiss Army knife for modern development. Here's why.

Go 1.24 has arrived with many improvements, but one of the most interesting changes is the introduction of a Swiss Table-based map implementation. This update improves performance for map operations, making Go even more efficient.

In this blog post, we’ll explore what the Swiss Table implementation is, why it matters, and how it can impact your Go programs.

Any company using Kubernetes eventually starts looking into developing their custom controllers. After all, what’s not to like about being able to provision resources with declarative configuration: Control loops are fun, and Kubebuilder makes it extremely easy to get started with writing Kubernetes controllers. Next thing you know, customers in production are relying on the buggy controller you developed without understanding how to design idiomatic APIs and building reliable controllers.

Low barrier to entry combined with good intentions and the “illusion of working implementation1” is not a recipe for success while developing production-grade controllers. I’ve seen the real-world consequences of controllers developed without adequate understanding of Kubernetes and the controller machinery at multiple large companies. We went back to the drawing board and rewritten nascent controller implementations a few times to observe which mistakes people new to controller development make.

I recently built something interesting and want to share it with you: introducing OpenDAL as a native Go binding.

TLDR; I'll show you a feasible way to build native Go bindings from Rust and C components with the magic power of purego and libffi behinds.

Just like any other dynamically growable container structure, Go slices come with a few gotchas. I don’t always remember all the rules I need to be aware of. So this is an attempt to list some of the most common mistakes I’ve made at least once.

sturdyc eliminates cache stampedes and can minimize data source load in high-throughput systems through features such as request coalescing and asynchronous refreshes. It combines the speed of in-memory caching with granular control over data freshness. At its core, sturdyc provides non-blocking reads and sharded writes for minimal lock contention. The xxhash algorithm is used for efficient key distribution.

A General-purpose Task-parallel Programming Framework for Go, inspired by taskflow-cpp, with Go's native capabilities and simplicity, suitable for complex dependency management in concurrent tasks.

EasyCache is a high-performance, in-memory caching library for Go, supporting multiple eviction policies like FIFO, LRU, LFU, and TTL-based expiration. It is thread-safe, lightweight, and provides built-in metrics.

View the HTTP and HTTPS requests made by any linux program by running httptap -- <command>.

Batching is a well-known optimization technique. You see it everywhere: batch inserts in databases, MGET/MSET in Redis, various bulk APIs. The benefits are clear — it’s faster, cheaper, and less rate-limited. These benefits usually come at the cost of slightly more complex code and some boilerplate.

I recently joined a project where the codebase was written in Go. While the codebase had numerous issues, one stood out: the server restarted unexpectedly and frequently. After examining the server logs, I discovered the culprit—panic-induced crashes in Goroutines. The underlying issue was that the codebase didn’t handle panic recovery in all the Goroutines it started.