After spending five years as a JavaScript developer building both frontend and backend systems, I spent the last year transitioning to Go for server-side code. During that time I couldn't help but notice the differences between syntax, fundamentals, practices, and runtime environments between the languages and the effects they had on actual runtime performance and developer productivity.

For years in Go, I’ve used many different logging libraries, from logrus to zap. After the release of slog into Go standard library, I immediately embraced it. It’s clever design made it so versatile and easy to use, and has already accumulated an enormous amount of libraries in the ecosystem.

Go offers an exceptional language and an impressive ecosystem of tools. However, it presents a notable challenge when integrating with C code via cgo. While building and distributing pure Go binaries across various platforms is straightforward — often requiring just a few parameter adjustments — the process becomes considerably more complex when C dependencies are introduced.

Go binary size SVG treemap

Preventing data races with mutexes may sound easy, but dealing with race conditions is a whole other matter. Let's learn how to handle these beasts!

Everything comes at a cost — and observability is no exception. When we add metrics, logging, or distributed tracing to our applications, it helps us understand what’s going on with performance and key UX metrics like success rate and latency. But what’s the cost?

Lately I’ve been finding myself writing a bit of Go, and I’ve picked up various fun “layout secrets” that help inform how I write code to minimize hidden allocations, and generally be kind to the optimizer. This article is a series of notes on the topic.

This post is about Go implementation details, so they can probably break you at any time if you rely on it. On the other hand, Hyrum’s law is a bitch, so taking your chances may not be that bad. After all, they’re probably never going to be able to properly clean up the mess people made with //go:linkname with runtime symbols…

As with many of my other posts, I’ll assume a basic familiarity with being able to read assembly. I’m using x86 for this post, but it’s worth looking at my RISC-V post for a refresher.

Netpoll is a high-performance non-blocking I/O networking framework, which focused on RPC scenarios, developed by ByteDance.

Go 1.25 is scheduled for release in August, so it's a good time to explore what's new. The official release notes are pretty dry, so I prepared an interactive version with lots of examples showing what has changed and what the new behavior is.