Tag: performance

This runnable tour makes Go 1.27 easier to evaluate than a release-note inventory. Generic methods and broader type inference get the headline, while smaller changes to allocations, goroutine diagnostics, JSON v2, testing, cryptography, and the standard library show how much of a language release is really about removing daily friction. The examples are especially good at exposing limits: generic methods cannot satisfy interfaces, and portable SIMD is still experimental rather than a blanket invitation to rewrite hot loops.

The tension is Go's old strength: every new capability spends from a deliberately small complexity budget. Generic methods can make reusable APIs more expressive, but an example that requires a generic translation before its ordinary meaning is clear has already raised the reading cost. The better standard is not whether Go can absorb another feature. It is whether the feature makes production code easier to understand after the novelty fades. Runtime and tooling improvements often clear that bar more quietly than syntax does.

This belongs in the queue because database performance is often where application assumptions meet physical reality. Indexes, query plans, and access patterns are product concerns when latency becomes user-visible.

It is also a reminder that "the database is slow" is rarely a useful diagnosis. The question is what the query asked the database to do.