Generic Methods

This is the headline, and it is a real language change: a method declaration may now declare its own type parameters.

Before 1.27, type parameters could only appear on a function or on the type itself. If you wanted a generic helper that logically belonged to a type, your only option was a package-level function:

// Go 1.26 and earlier: the helper lives in the package namespace,
// even though it only makes sense for *Rand.
func N[Int intType](r *rand.Rand, n Int) Int

Now it can live where it belongs. math/rand/v2 is the standard library’s own example — it gained a generic method alongside the existing generic function:

// Go 1.27
func (r *Rand) N[Int intType](n Int) Int

Which means this now compiles:

r := rand.New(rand.NewPCG(1, 2))

var d time.Duration = r.N(time.Second)  // method, inferred as time.Duration
var i int32         = r.N(int32(100))   // same method, different instantiation

The practical effect is that you can stop writing pkg.DoThing(x, ...) for operations that are conceptually x.DoThing(...). Anywhere you have a container, a client, or a builder that needed a package-level generic helper, that helper can now be a method.

Two limits worth knowing before you plan a refactor around it:

• Interfaces cannot declare type parameters on their methods, and an interface method cannot be satisfied by a generic method. So this does not give you generic interfaces through the back door; the method set of an interface is still fully concrete.
• It is a method type parameter, distinct from the receiver’s. func (c *Cache[K, V]) MapTo[T any](...) has three type parameters in play, two from the receiver and one from the method.

If you have been writing the awkward package-level workarounds I described in how Golang generics minimize the amount of code you need to write, this is the release where a lot of that gets to move inside the type.

Two smaller language changes shipped alongside it. A key in a struct literal may now be any valid field selector, not just a top-level field name — which makes literals for structs with embedded types far less irritating. And function type inference is generalised to every context where a generic function is assigned to, or converted to, a matching function type, so a class of “cannot infer” errors simply disappears.

encoding/json/v2

The JSON rewrite is in, as two packages:

• encoding/json/v2 — the high-level API you already know, redesigned.
• encoding/json/jsontext — lower-level syntactic processing, with an Encoder and Decoder that work in terms of Token and Value and hold a state machine guaranteeing the JSON is valid.

The v2 entry points take variadic options:

import "encoding/json/v2"

b, err := json.Marshal(v,
    json.Deterministic(true),          // stable map ordering
    json.OmitZeroStructFields(true),
)

err = json.Unmarshal(data, &v,
    json.RejectUnknownMembers(true),   // strict decoding, no silent drops
)

Alongside Marshal and Unmarshal there are MarshalWrite / UnmarshalRead for an io.Writer / io.Reader, and MarshalEncode / UnmarshalDecode for driving a jsontext.Encoder / Decoder directly. That last pair is what you want for streaming, and it is a much better story than v1’s json.Decoder ever was.

The defaults are stricter, which is the whole point. v2 rejects invalid UTF-8 in strings and rejects duplicate names within an object — both of which v1 quietly accepted. That is more interoperable and it closes a genuine class of parser-differential bugs.

RejectUnknownMembers(true) deserves a callout for anyone writing an API. v1’s default of silently discarding unknown fields is how a typo in a client’s request body turns into a field that is quietly zero, and then into a support ticket. Making that an error at the boundary is the same instinct as the sentinel errors in error handling in Go: fail where the information is, not three layers down.

encoding/json v1 is not going anywhere, and it gained a matching set of options with names that tell you exactly what they are for — CallMethodsWithLegacySemantics, OmitEmptyWithLegacySemantics, FormatDurationAsNano, ParseTimeWithLooseRFC3339 and friends. That is the migration path: move to v2, and where behaviour differs in a way you depend on, opt back into the v1 semantics explicitly rather than discovering the difference in production.

One thing to be deliberate about: v2’s stricter parsing is a behaviour change at your HTTP boundary. A client that has been sending duplicate keys or malformed UTF-8 and getting away with it will start getting errors. That is correct, and it is still worth knowing before you flip it on a live service. Point a load test at it first — the setup in an easy way to load test your web apps is enough to see whether real traffic trips the new rules.

A uuid Package

There is now a uuid package in the standard library. The whole API is small enough to quote:

type UUID [16]byte

func New() UUID                        // the recommended default
func NewV4() UUID                      // random
func NewV7() UUID                      // time-ordered
func Parse(string) (UUID, error)
func MustParse(string) UUID
func Nil() UUID
func Max() UUID

func (UUID) String() string
func (UUID) Compare(UUID) int
func (UUID) MarshalText() ([]byte, error)
func (UUID) AppendText([]byte) ([]byte, error)
func (*UUID) UnmarshalText([]byte) error

NewV7 is the one to reach for when the UUID is a database key. Version 7 is time-ordered, so generated values sort roughly by creation time — which keeps B-tree index inserts near the right-hand edge instead of scattering them across the whole index the way v4 does. If you have ever watched write throughput degrade on a table with a random-UUID primary key, that is the problem v7 exists to solve.

Compare returning an int means it drops straight into slices.SortFunc, and the TextMarshaler / TextUnmarshaler implementation means it round-trips through JSON and database/sql without a wrapper type.

The obvious question: does this kill github.com/google/uuid? Not immediately — plenty of code depends on its wider surface. But for the common case of “I need a v4 or v7 UUID, and I need to parse one”, that is now a dependency you can delete.

Goroutine Leak Profiles, Generally Available

The goroutineleak profile, experimental in 1.26, is now GA in runtime/pprof and exposed at /debug/pprof/goroutineleak.

It reports goroutines blocked on a concurrency primitive that cannot possibly become unblocked. The detection is clever: it piggybacks on the garbage collector. If goroutine G is blocked on primitive P, and P is unreachable from any runnable goroutine — or from any goroutine those could unblock — then nothing can ever signal P, so G is leaked.

import _ "net/http/pprof"

// then:
//   go tool pprof http://localhost:6060/debug/pprof/goroutineleak

The reachability trick is also the limitation, and the release notes say so plainly: leaks caused by blocking on a primitive that is still reachable through a global, or through a runnable goroutine’s locals, will not be detected. It catches a large class, not all of them.

Still, this is the first tool that turns “we think we have a goroutine leak somewhere” into a list. The failure modes it finds are exactly the ones from worker pools in Go with errgroup — a worker blocked forever on a send to a channel nobody is reading — and the ones a missing <-ctx.Done() produces, which I wrote about in understanding Golang context.

Free Performance

The compiler now emits calls to size-specialised allocation routines, cutting the cost of small allocations (under 80 bytes) by up to 30%. The release notes are honest about what that means end to end: roughly 1% on allocation-heavy programs, and about 60 KB more binary, regardless of workload.

One percent for a recompile is a good trade. If it causes you trouble, GOEXPERIMENT=nosizespecializedmalloc turns it off at build time — but note that escape hatch is expected to be removed in Go 1.28, so treat it as a window to file a bug, not a setting to keep.

Smaller Things Worth Knowing

That last one is quietly excellent. It is the failure mode where your code builds on your machine and breaks on a builder pinned to an older Go — the same class of problem I hit deploying this blog, where a template function that did not exist in the CI toolchain failed a build that was green locally.

Two for Later

crypto/mldsa implements ML-DSA, the post-quantum signature scheme standardised as FIPS 204, with the three parameter sets MLDSA44(), MLDSA65() and MLDSA87(). Unless you have a compliance requirement you will not touch it this year, but it being in the standard library is what makes migration a normal task rather than a project.

simd is an experimental package behind GOEXPERIMENT=simd, providing portable, vector-size-agnostic SIMD types like Int8s and Float32s that use hardware instructions where available. Experimental means experimental — but portable SIMD in Go is a genuinely interesting direction.

Should You Upgrade?

Yes, and the calculus is unusually simple:

• The Go 1 compatibility promise holds; almost everything compiles unchanged.
• You get ~1% on allocation-heavy code for a recompile.
• goroutineleak is worth the upgrade on its own for any service running long-lived goroutines.
• Generic methods and JSON v2 are opt-in. Nothing forces you to rewrite anything.

The only change that needs a moment’s thought is JSON v2’s stricter parsing, and only if you adopt it at a public boundary. Everything else is additive.

Conclusion

Generic methods close a gap that has been awkward since generics landed in 1.18, and they will quietly improve a lot of library APIs over the next year. JSON v2 is the rarer thing: a second attempt at a core package that gets to fix the defaults, with an explicit escape hatch back to the old behaviour. And a uuid package removes a dependency from nearly every service I have written.

Not bad for a release the notes describe as “mostly implementation”.

One Invariant, Everything Follows From It

Prompt caching is a prefix match. Any change anywhere in the prefix invalidates everything after it.

That is the whole model. The cache key is derived from the exact bytes of your rendered prompt up to each breakpoint. One byte different at position N — a timestamp, a reordered JSON key, an extra tool in the list — and every cached position at or after N is gone.

The render order matters and is fixed:

tools  →  system  →  messages

Tools render first, at position zero. That has a consequence people discover the expensive way: change the tool list and you have invalidated everything, system prompt and entire conversation included. More on that below.

What It Costs

Two numbers govern whether caching pays:

• A cache read costs about 0.1× the base input price.
• A cache write costs 1.25× for the 5-minute TTL, 2× for the 1-hour TTL.

So with the default 5-minute TTL, two requests already break even: 1.25 + 0.1 = 1.35 against 2.0 uncached. By the third request you are well ahead. With the 1-hour TTL you need three requests to break even, because the write costs double.

Which is why the TTL question is not “how long do I want this cached” but “how far apart do requests sharing this prefix start”:

The subtlety in row one: a read refreshes the entry at no extra cost, and the lifetime is measured from the start of the request. A four-minute generation leaves about one minute for the next request to begin before a five-minute entry expires. For a chat endpoint under steady load, the 5-minute TTL is the right answer and the 1-hour TTL just doubles your write bill.

Making It Work in Go

The syntax is a CacheControl on the last block of whatever you want cached. Because tools render before system, a marker on the final system block caches both:

params := anthropic.MessageNewParams{
    Model:     "claude-opus-5",
    MaxTokens: 16000,
    Tools:     tools, // deterministic order — see below
    System: []anthropic.TextBlockParam{{
        Text:         systemPrompt,
        CacheControl: anthropic.NewCacheControlEphemeralParam(), // 5-minute default
    }},
    Messages: messages,
}

For the 1-hour TTL:

CacheControl: anthropic.CacheControlEphemeralParam{
    TTL: anthropic.CacheControlEphemeralTTLTTL1h,
},

There is also a top-level CacheControl on MessageNewParams that automatically places a breakpoint on the last cacheable block and moves it forward as the conversation grows. For multi-turn chat that is the right default — no marker bookkeeping, and the growing history caches incrementally.

The robust combination for anything agentic: one explicit breakpoint at the end of the static system prefix, so the expensive shared part has a guaranteed read point no matter what happens later in messages, plus top-level automatic caching for the growing tail.

You get four breakpoints per request, so there is no need to be frugal — place them at genuine stability boundaries.

Where Automatic Caching Is the Wrong Tool

Automatic placement puts the breakpoint at the very end of your prompt. When the prompt ends with something unique per request — a retrieved document, the user’s actual question — that is a pure surcharge: every request writes a new cache entry that nothing will ever read.

The signature is unmistakable once you know it: cache_creation_input_tokens is non-zero on every single request, while cache_read_input_tokens never covers the shared prefix.

The fix is an explicit marker at the end of the shared portion:

Messages: []anthropic.MessageParam{
    anthropic.NewUserMessage(
        anthropic.TextBlockParam{
            Text:         sharedContext, // few-shot examples, retrieved docs
            CacheControl: anthropic.NewCacheControlEphemeralParam(),
        },
        anthropic.NewTextBlock(userQuestion), // no marker — differs every time
    ),
},

Same rule, restated: put the breakpoint where the prompt stops being shared, not where the prompt ends.

The Minimum Prefix, Which Is Not Monotonic

A prompt shorter than the model’s minimum will not cache — no error, no warning, cache_creation_input_tokens simply comes back zero. And the minimum does not move in the direction you would guess as models get newer:

A 3,000-token system prompt caches on Opus 5 and Opus 4.8, and silently does not on Opus 4.6 or Haiku 4.5. If you switched models and your cache hit rate fell off a cliff, this is the first thing to check — and it cuts the other way too: moving to Opus 5 halves the Opus 4.8 minimum, so prompts that were previously too short start caching with no code change at all.

Silent Invalidators

This is the part worth committing to memory, because every one of these is code that looks perfectly reasonable in review.

The Go-specific ones deserve emphasis. Map iteration order in Go is deliberately randomised, so this is not a cache bug that appears under load — it appears on every request, and it is invisible because the rendered prompt is semantically identical each time:

// Bad: iteration order is randomised, so the bytes differ every run.
for name, def := range h.tools {
    tools = append(tools, def)
}

// Good: deterministic.
names := slices.Sorted(maps.Keys(h.tools))
for _, name := range names {
    tools = append(tools, h.tools[name])
}

Sorting keys is a one-line fix that most Go LLM code needs and almost none has.

Injecting Dynamic Context Without Breaking Everything

The usual reason a system prompt has a timestamp in it is that the model genuinely needs to know the date, or the user’s plan tier, or the current mode. The instinct is to template it into the system prompt. Don’t — that is the front of the prefix, and it invalidates everything behind it.

Put dynamic context after the cached history instead. On the newest models there is a first-class channel for this: a system-role message appended to messages, rather than an edit to the top-level system field.

// The top-level system prompt stays byte-identical and stays cached.
// The operator instruction goes after the history, invalidating nothing before it.
messages = append(messages, userTurn)
messages = append(messages, anthropic.MessageParam{
    Role: anthropic.MessageParamRoleSystem,
    Content: []anthropic.ContentBlockParamUnion{
        anthropic.NewTextBlock("Terse mode enabled — keep responses under 40 words."),
    },
})

A message at turn five invalidates nothing before turn five. That is the whole trick.

Two constraints: it must follow a user message and be either the last entry or followed by an assistant turn — it cannot be messages[0], so use the top-level system for the initial prompt. And support is model-dependent; unsupported models return a 400 saying the system role is not supported, so catch that and fall back to putting the instruction in a user turn.

Three Rules That Beat Marker Placement

Fix these before you fiddle with breakpoints.

Freeze the system prompt. No dates, no user names, no modes. It is the front of the prefix and everything downstream depends on it not moving.

Never change tools or model mid-conversation. Tools render at position zero, so adding, removing or reordering one invalidates the entire cache. Caches are also model-scoped, so switching models mid-conversation starts from cold. If you need “modes”, do not swap the tool set — pass the mode as message content.

Forked calls must reuse the parent’s exact prefix. Summarisation passes, sub-agents and side computations usually build their own request. If that fork rebuilds system, tools or model with any difference at all, it misses the parent’s cache completely. Copy them verbatim and append the fork-specific content at the end.

That last one is also the argument against a “cheap model for the easy stuff” cascade, at least as a first move. Caches are per model, so routing between two models forfeits cache reuse across them. Measure the capable model at lower effort before you build the cascade — it is often cheaper and simpler, and it keeps one cache namespace.

Verifying It, Forever

Every response carries the accounting (the same Usage struct I said to log from day one in calling an LLM from Go):

InputTokens is the uncached remainder only — not the prompt size. Total prompt = all three added together. If an agent ran for an hour and InputTokens reads 4K, the rest came from cache; check the sum, not the one field.

In a healthy multi-turn loop you should see, on each request:

• CacheReadInputTokens — the whole prior prefix, growing turn over turn.
• CacheCreationInputTokens — roughly the last assistant turn plus the new input. Small.
• InputTokens — just the tail past the last breakpoint.

If CacheCreationInputTokens is instead close to the full conversation size every time, the prefix is being rewritten upstream of your breakpoint. Go find the timestamp.

And then keep checking. The expensive failure here is never the bad first implementation — it is the regression. Caching works the day you write it, then six weeks later somebody adds a dynamic field to the system prompt or a tool list that stopped being sorted, and every request misses. Nothing fails. Nothing pages. You find out from finance.

So make it a standing assertion, not a one-time look:

func TestSystemPromptStaysCacheable(t *testing.T) {
    // Two identical requests: the second must read from cache.
    first := callModel(t, ctx, fixture)
    if first.Usage.CacheCreationInputTokens == 0 {
        t.Fatalf("nothing was cached: prompt may be under the model minimum")
    }

    second := callModel(t, ctx, fixture)
    if second.Usage.CacheReadInputTokens == 0 {
        t.Errorf("cache miss on an identical prompt — a silent invalidator crept in")
    }
}

That test costs a few cents to run and catches a regression that otherwise runs for months. Put it behind a build tag so it only runs when you mean it — the same treatment I gave integration tests in how to test database interactions in Golang. Better still, put a monitor on the ratio of CacheReadInputTokens to total input tokens and alert when it drops.

Checklist

• Frozen system prompt: no dates, IDs, names or conditional sections.
• Deterministic tool list, sorted by name, identical across users.
• One explicit breakpoint at the end of the static prefix; automatic caching for the tail.
• Breakpoint at the end of the shared portion, not the end of the prompt.
• 5-minute TTL under continuous traffic; 1-hour only for 5–60 minute gaps.
• Prompt above the model’s minimum, which changes between models.
• Dynamic context appended after the history, never templated into the system prompt.
• Forks copy the parent’s system, tools and model verbatim.
• A test or monitor on the usage fields, checked on every change to prompt assembly.

Conclusion

Prompt caching is the rare optimisation with no quality tradeoff: identical output, roughly a tenth of the input cost, and lower latency as a bonus. It is also unusually fragile, because it hinges on byte-exact prefixes and fails completely silently. Treat the prompt-building path the way you would treat a cache key anywhere else in your system — deterministic, stable, and covered by a test — and it mostly takes care of itself.

Go was created at Google to solve real-world problems—fast builds, simple deployment, and effortless concurrency—without sacrificing developer happiness. Let’s dive into nine reasons why you should use Golang in 2025 and beyond.

Quick Snapshot: Benefits at a Glance

1. Native Concurrency Model

Go’s goroutines and channels deliver lightweight concurrency without complex thread management. Spawning 100 000 goroutines is commonplace:

func main() {
    wg := sync.WaitGroup{}
    for i := 0; i < 1e5; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            fmt.Println(id)
        }(i)
    }
    wg.Wait()
}

Compare that with traditional threads and locks and the why use Golang answer becomes evident—parallelism is baked into the language.

2. Blazing-Fast Compilation & Execution

Go produces native machine code and compiles large projects in seconds. Faster feedback loops boost productivity, and Go’s runtime performance rivals (and often exceeds) higher-level languages like Python or Node.js.

3. Pragmatic, Readable Syntax

Go deliberately avoids generics-for-everything, implicit magic, and hidden control flow. The result is code that looks similar across companies, which means reading unfamiliar Go is easy.

4. A Batteries-Included Standard Library

Need an HTTP server, JSON encoder, or RSA crypto? It’s already in stdlib. With fewer third-party dependencies, your supply-chain attack surface shrinks.

5. Static Binaries & Effortless Deployment

go build outputs a single, statically linked binary. Drop it in a container scratch image (~10 MB) or onto a bare server—no JVM, no interpreter.

GOOS=linux GOARCH=amd64 go build -ldflags "-s -w" -o app

6. First-Class Tooling Out-of-the-Box

Formatting (go fmt), linting (go vet), profiling (pprof), testing, and coverage are all standard. This uniform toolchain answers why use Golang for teams who value consistency.

7. Memory Safety & Predictable GC

Go’s garbage collector has reached <1 ms 95th percentile pause times while retaining simplicity. With escape analysis and value semantics, many allocations disappear at compile time.

8. Vibrant Ecosystem & Community

Frameworks like Gin, Echo, and Fiber make web development painless; gRPC and Protocol Buffers have first-class support; and cloud providers ship Go SDKs on day one.

9. Proven in Production by Industry Leaders

Google (of course), Netflix, Uber, Cloudflare, Stripe, and many others run latency-critical systems in Go. That track record signals Go’s staying power.

When Not to Use Go

While this article focuses on why to use Golang, balanced engineering requires knowing its limits:

• No generics for higher-kinded types (though basic generics landed in Go 1.18).
• Runtime lacks a mature GUI library.
• Manual error handling (if err != nil) can feel verbose.

If your workload is numerical heavy-compute with tight SIMD requirements or requires sophisticated metaprogramming, Rust or C++ may fit better.

Conclusion

So why use Golang? Because it delivers a rare combination of developer ergonomics, runtime efficiency, and operational simplicity. From microservices to CLI tools, Go empowers teams to ship reliable software—fast.

Ready to give Go a try? Install it, go mod init, and discover firsthand why thousands of engineers choose Golang every day.

If that convinced you, here is where I would start: understanding Golang context for concurrency you can cancel, error handling in Go for the idiom that trips up most newcomers, and one of the easiest ways to host your Go web app for getting the result online. For what the language has picked up lately, see exciting features coming in Go 1.25.

Understanding Time in Go

The Go language approaches time handling with its characteristic blend of simplicity and practicality. The time package centers around three key types:

• time.Time - Represents a specific moment in time
• time.Duration - Represents the elapsed time between two points
• time.Location - Represents a time zone

What makes Go’s implementation particularly useful is its handling of monotonic time, which ensures consistent time measurements even when system clocks change.

Working with Current Time

Let’s start with some basic operations:

package main

import (
    "fmt"
    "time"
)

func main() {
    // Get the current time
    now := time.Now()
    fmt.Println("Current time:", now)
    
    // Format the time using the reference time constant
    // Mon Jan 2 15:04:05 MST 2006
    fmt.Println("Formatted time:", now.Format("2006-01-02 15:04:05"))
    
    // Get individual components
    fmt.Printf("Year: %d, Month: %s, Day: %d\n", 
        now.Year(), now.Month(), now.Day())
    
    // Get Unix timestamp (seconds since January 1, 1970 UTC)
    fmt.Println("Unix timestamp:", now.Unix())
}

While most programming languages use arbitrary format strings like “YYYY-MM-DD”, Go uses a specific reference time: January 2, 2006 at 15:04:05 (or 01/02 03:04:05PM ‘06 -0700). This approach eliminates ambiguity and is easier to remember once you realize the pattern: 01/02 03:04:05PM ‘06.

Time Parsing and Time Zones

One of Go’s strengths is its handling of time zones and time parsing. Let’s see how to work with different formats and time zones:

package main

import (
    "fmt"
    "time"
)

func main() {
    // Parse a time string
    timeStr := "2025-06-09T21:47:00+02:00"
    t, err := time.Parse(time.RFC3339, timeStr)
    if err != nil {
        fmt.Println("Error parsing time:", err)
        return
    }
    fmt.Println("Parsed time:", t)
    
    // Convert to different timezone
    utc := t.UTC()
    fmt.Println("UTC time:", utc)
    
    // Load a specific location
    loc, err := time.LoadLocation("America/New_York")
    if err != nil {
        fmt.Println("Error loading location:", err)
        return
    }
    
    // Convert time to the new location
    nyTime := t.In(loc)
    fmt.Println("New York time:", nyTime)
}

A common source of bugs is assuming all times are UTC. In a distributed system, always be explicit about time zones when communicating timestamps between services.

Measuring Time and Performance

Go’s time package shines when measuring code performance:

package main

import (
    "fmt"
    "time"
)

func someExpensiveOperation() {
    // Simulate work
    time.Sleep(100 * time.Millisecond)
}

func main() {
    start := time.Now()
    someExpensiveOperation()
    elapsed := time.Since(start)
    
    fmt.Printf("Operation took %s\n", elapsed)
    // Alternatively with the same result
    fmt.Printf("Operation took %s\n", time.Now().Sub(start))
}

The time.Since() function is a convenient shorthand for time.Now().Sub(start), making benchmarking code cleaner.

Working with Durations

The time.Duration type is a nanosecond-precision interval that offers intuitive operations:

package main

import (
    "fmt"
    "time"
)

func main() {
    // Create durations using typed constants
    second := 1 * time.Second
    minute := 1 * time.Minute
    hour := 1 * time.Hour
    
    // Arithmetic with durations
    total := second + 30*minute + 2*hour
    fmt.Printf("Total duration: %v (%s)\n", total, total)
    
    // Parsing durations from strings
    d, err := time.ParseDuration("1h30m15s")
    if err != nil {
        fmt.Println("Error parsing duration:", err)
        return
    }
    fmt.Printf("Parsed duration: %v\n", d)
    
    // Converting durations
    fmt.Printf("In seconds: %.2f\n", d.Seconds())
    fmt.Printf("In minutes: %.2f\n", d.Minutes())
    fmt.Printf("In hours: %.2f\n", d.Hours())
}

Note that time.Duration has a maximum range of approximately 290 years. For longer time periods, you’ll need to use time.Time instead.

Timers and Tickers

For scheduling operations, Go provides timers and tickers:

package main

import (
    "fmt"
    "time"
)

func main() {
    // Create a timer that will fire once after 2 seconds
    timer := time.NewTimer(2 * time.Second)
    fmt.Println("Timer started at", time.Now().Format("15:04:05"))
    
    // Wait for the timer to fire
    <-timer.C
    fmt.Println("Timer fired at", time.Now().Format("15:04:05"))
    
    // Create a ticker that fires every second
    ticker := time.NewTicker(1 * time.Second)
    counter := 0
    
    // Process ticker events for 5 seconds
    for {
        <-ticker.C
        counter++
        fmt.Println("Tick", counter, "at", time.Now().Format("15:04:05"))
        
        if counter >= 5 {
            ticker.Stop()
            break
        }
    }
    
    fmt.Println("Ticker stopped")
}

A common mistake is forgetting to stop tickers when they’re no longer needed, which can lead to goroutine leaks.

Performance Tips and Best Practices

After working with Go’s time package across multiple production systems, I’ve identified several best practices:

1. Avoid frequent calls to time.Now() in tight loops, as it involves a system call.

2. Use monotonic time for duration measurements. Go handles this automatically when you call time.Now(), but be aware that serializing and deserializing a time.Time loses the monotonic component.

3. Be consistent with time zones, especially when storing times in databases. Either standardize on UTC for storage or be explicit about the time zone.

4. For repeated timer operations, use time.Ticker instead of repeatedly creating new timers.

5. When parsing user input, prefer to use explicit formats with time.Parse rather than magic formatting functions.

Here’s an example of a common anti-pattern and how to fix it:

// Anti-pattern - creating many timers
func antiPattern() {
    for i := 0; i < 1000; i++ {
        timer := time.NewTimer(time.Second)
        <-timer.C
        doSomething()
    }
}

// Better approach - reuse a single timer
func betterApproach() {
    timer := time.NewTimer(time.Second)
    for i := 0; i < 1000; i++ {
        <-timer.C
        doSomething()
        timer.Reset(time.Second)
    }
    timer.Stop()
}

Conclusion

Go’s time package provides an intuitive API for handling all aspects of time in your applications. From simple date formatting to sophisticated time measurements, it offers a consistent approach that aligns with Go’s philosophy of simplicity and practicality.

By understanding how Go approaches time handling, you can write more efficient and reliable code, avoid common pitfalls, and leverage the full power of Go’s time primitives.

See also: understanding Golang context for deadlines and timeouts, and mastering Golang for loops for the iteration patterns these examples lean on.

How do you handle time operations in your Go applications? Have you encountered any challenging time-related bugs? Share your experiences in the comments below!

Profile-guided optimization

One of the most significant additions in Go 1.25 is the stabilization of profile-guided optimization (PGO). After being introduced as an experimental feature in Go 1.20 and improved in subsequent releases, PGO is finally becoming a stable feature in Go 1.25.

Profile-guided optimization allows the compiler to optimize code based on runtime behavior profiles. By analyzing how your application actually runs in production, the compiler can make more intelligent optimization decisions.

Here’s how you can use it:

// First, run your application with profiling enabled
go build -pgo=off myapp.go
./myapp -cpuprofile=profile.pprof

// Then compile with PGO
go build -pgo=profile.pprof myapp.go

The benefits are substantial - benchmarks have shown performance improvements of 2-7% for real-world applications, with some hot paths seeing even greater gains.

Improved Garbage Collection

Go 1.25 continues the work on improving the garbage collector’s performance. The new version brings lower latency and better memory management, particularly for applications with large heaps.

The improvements focus on reducing GC pause times and making them more predictable, which is crucial for applications requiring consistent performance.

Enhanced Toolchain Security

Security gets a boost in Go 1.25 with improvements to the toolchain. The go command now includes better verification of module authenticity and additional checks to prevent supply chain attacks.

Better Error Handling

Error handling in Go has been incrementally improving, and Go 1.25 continues this trend with enhancements to the errors package. The improvements make it easier to wrap, unwrap, and inspect errors in a more structured way.

One of the key improvements is the addition of new functions to the errors package that provide more flexibility when working with error chains. Let’s look at some examples of how these new features can be used.

Enhanced Error Wrapping

Go 1.25 introduces a more powerful way to wrap errors with additional context while preserving the original error information:

package main

import (
    "errors"
    "fmt"
)

func main() {
    err := processFile("config.json")
    if err != nil {
        fmt.Println(err)
        // Output: failed to process config.json: file not found
        
        // Check if it's a specific error type
        if errors.Is(err, ErrNotFound) {
            fmt.Println("The file was not found, please check the path")
        }
        
        // Get additional context from the error
        var fileErr *FileError
        if errors.As(err, &fileErr) {
            fmt.Printf("Error occurred with file: %s\n", fileErr.Filename)
        }
    }
}

// ErrNotFound is a sentinel error
var ErrNotFound = errors.New("file not found")

// FileError is a custom error type with additional context
type FileError struct {
    Filename string
    Err      error
}

func (e *FileError) Error() string {
    return fmt.Sprintf("failed to process %s: %v", e.Filename, e.Err)
}

func (e *FileError) Unwrap() error {
    return e.Err
}

func processFile(filename string) error {
    // Simulate a file not found error
    return &FileError{
        Filename: filename,
        Err:      ErrNotFound,
    }
}

New Error Grouping

Go 1.25 introduces a new way to handle multiple errors together, which is particularly useful for concurrent operations:

package main

import (
    "errors"
    "fmt"
    "sync"
)

func main() {
    // Process multiple files concurrently
    filenames := []string{"config.json", "data.csv", "settings.yaml"}
    
    // Create a new error group
    var errGroup errors.ErrorGroup
    
    // Use a wait group to wait for all goroutines
    var wg sync.WaitGroup
    
    for _, filename := range filenames {
        wg.Add(1)
        
        go func(filename string) {
            defer wg.Done()
            
            // Process the file
            err := processFile(filename)
            if err != nil {
                // Add the error to the group
                errGroup.Add(err)
            }
        }(filename)
    }
    
    // Wait for all goroutines to complete
    wg.Wait()
    
    // Check if any errors occurred
    if err := errGroup.Err(); err != nil {
        fmt.Println("Errors occurred during processing:")
        fmt.Println(err)
        
        // We can also iterate through individual errors
        errGroup.Range(func(err error) bool {
            fmt.Printf("- %v\n", err)
            return true // continue iteration
        })
    }
}

Improved Error Formatting

Go 1.25 also improves how errors are formatted, making it easier to get meaningful information when debugging:

package main

import (
    "errors"
    "fmt"
)

func main() {
    err := deepFunction()
    
    // Print the error with detailed formatting
    fmt.Printf("%+v\n", err)
    // Output includes the error message and stack trace
    
    // Get a simplified view
    fmt.Printf("%v\n", err)
    // Output: level3: level2: level1: base error
}

func deepFunction() error {
    return fmt.Errorf("level3: %w", middleFunction())
}

func middleFunction() error {
    return fmt.Errorf("level2: %w", baseFunction())
}

func baseFunction() error {
    return fmt.Errorf("level1: %w", errors.New("base error"))
}

These improvements make error handling in Go more robust and expressive, while still maintaining the simplicity and explicitness that Go is known for.

Conclusion

Go 1.25 represents another solid step forward for the language, focusing on performance, security, and developer experience. The stable release of profile-guided optimization is particularly exciting, as it allows for more intelligent performance optimizations based on real-world usage patterns.

As always, Go maintains its commitment to backward compatibility, so you can upgrade with confidence knowing your existing code will continue to work.

Stay tuned for the official release, and in the meantime, you can try out the beta versions to get a head start on these exciting new features.

Update: two releases on, Go 1.27 turned out to be the bigger deal — it adds generic methods to the language and lands JSON v2 and a uuid package in the standard library. See what’s new in Go 1.27.

If you are still weighing Go up rather than upgrading it, why use Golang makes the wider case. And two additions from recent releases that changed how I write everyday code: structured logging with log/slog and the per-iteration loop variables covered in mastering Golang for loops.

Early hints is a special HTTP header that is sent before the web server sends the final HTTP response to the client. At this moment it’s supported only by Chrome browser. As soon as the browser requests a page, server immediately returns 103 early hints header. In the meantime, a server will generate a usual HTTP response. This helps us utilize in maximum the loading time by letting browser know what resources it should preload while waiting for the final response from a server.

Enough theory, let’s write some code :)

First, I’m going to create an index.html with some dummy structure. Also, I will load bootsrap frontend framework to simulate some heavy css and js references during page load.

<html>
  <head>
    <title>Hello!</title>
    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.2.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-Zenh87qX5JnK2Jl0vWa8Ck2rdkQ2Bzep5IDxbcnCeuOxjzrPF/et3URy9Bv1WTRi" crossorigin="anonymous">
  </head>
  <body>
  <div class="p-2 bg-success">
    <h1 class="text-white">Hello!</h1>
  </div>
  <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.2.2/dist/js/bootstrap.bundle.min.js" integrity="sha384-OERcA2EqjJCMA+/3y+gxIOqMEjwtxJY7qPCqsdltbNJuaOe923+mo//f6V8Qbsw3" crossorigin="anonymous"></script>
  </body>
</html>

Now we need to serve it. Let’s create a server.

//go:embed index.html
var index string // embeded index.html

func main() {
	log.Println("Starting server...")
    // Handler for the page without early hints.
	http.HandleFunc("/1", noHintsHandler)
    // Handler for the page with early hints
	http.HandleFunc("/2", withHintsHandler)
	if err := http.ListenAndServe(":8082", nil); err != nil {
		log.Fatal(err)
	}
}

func noHintsHandler(w http.ResponseWriter, r *http.Request) {
	t := template.New("")
	t, err := t.Parse(index)
	if err != nil {
		log.Println(err)
	}
	t.Execute(w, nil)
}

func withHintsHandler(w http.ResponseWriter, r *http.Request) {
    // Adding headers with preload information for bootstrap.min.css and bootstrap.bundle.min.js
	w.Header().Add("Link", "<https://cdn.jsdelivr.net/npm/bootstrap@5.2.2/dist/css/bootstrap.min.css>; rel=preload; as=style")
	w.Header().Add("Link", "<https://cdn.jsdelivr.net/npm/bootstrap@5.2.2/dist/js/bootstrap.bundle.min.js>; rel=preload; as=script")
    // Sending 103 status code.
	w.WriteHeader(http.StatusEarlyHints)

    t := template.New("")
	t, err := t.Parse(index)
	if err != nil {
		log.Println(err)
	}
    // Sending 200 status code.
	w.WriteHeader(http.StatusOK)
	t.Execute(w, nil)
}

Now it’s time to see our pages in action! Run our server go run main.go, open the page without early hints http://localhost:8082/1 in Chrome, open inspector, go to Lighthouse tab and click on “Analyze page load” button. And this is what we can see: It takes a while until bootstrap resources got loaded by a browser. As result, FCP (First Contentful Paint) is 1492,8ms.

Now, let’s do the same for the page with the early hints http://localhost:8082/2 And this is a result: As you can see, the page loaded much faster now. Bootstrap dependencies (bootstrap.min.css and bootstrap.bundle.min.js) were preloaded in the beginning and FCP now is 437,8ms. More than 3 times faster, quite an impressive result!

However, it does not mean that you have to preload absolutely all resources now. Just try to experiment with these things, see how it affects your page performance and decide for yourself the right balance.

You can find the source code here.

If you want to measure the difference on your own service rather than take my numbers for it, an easy way to load test your web apps shows the setup I use. And for the wins that happen before the request even reaches your handler, have a look at how to make Nginx cache cookie aware.

In our web application, we have multiple resolvers that execute some sql queries and return data in different types. Obviously, we want to prevent the database overloading by caching the same responses.

    // MyExampleType1 type to serve example response 1.
    type MyExampleType1 struct {}
    // MyExampleType2 type to serve example response 2.
    type MyExampleType2 struct {}

    // MyCachedResolver1 checks if there are any cached data by specific key.
    // If nothing in cache, queries the database and adds result to the redis cache.
    func MyCachedResolver1(redisClient *redis.Client) ([]MyExampleType1, error) {
      key := "resolver_result"
	  value, found := redisClient.Get(ctx, key)
	  if !found {
		value, err := FetchSomethingHeavyFromDB()
		if err != nil {
			return nil, err
		}

		valueJson, err := json.Marshal(value)
		if err != nil {
			return nil, err
		}
		redisClient.Set(context.Background(), key, valueJson, time.Hour*12)
		return value, nil
	  }

	  var val []MyExampleType1
	  err := json.Unmarshal([]byte(value.(string)), &val)
	  if err != nil {
		return nil, err
	  }
	  return val, nil
    }

    // MyCachedResolver2 checks if there are any cached data by specific key.
    // If nothing in cache, queries the database and adds result to the redis cache.
    func MyCachedResolver2(redisClient *redis.Client) ([]MyExampleType2, error) {
      key := "resolver_result_2"
	  value, found := redisClient.Get(ctx, key)
	  if !found {
		value, err := FetchSomethingEvenMoreHeavierFromDB()
		if err != nil {
			return nil, err
		}

		valueJson, err := json.Marshal(value)
		if err != nil {
			return nil, err
		}
		redisClient.Set(context.Background(), key, valueJson, time.Hour*12)
		return value, nil
	  }

	  var val []MyExampleType2
	  err := json.Unmarshal([]byte(value.(string)), &val)
	  if err != nil {
		return nil, err
	  }
	  return val, nil
    }

As you can see, there is some repetitive code that should be written due to the different types MyExampleType1 and MyExampleType2.

Now, let’s see how we can improve this situation by using generics. I’m going to write a function WithCache() which will be responsible for setting and getting data to/from redis cache.

    // WithCache adds exec function result into the redis cache.
    // Pay attention to "T any" that allows us to pass any type to this function.
    func WithCache[T any](redisClient *redis.Client, ctx context.Context, key string, exec func() (T, error), ttl time.Duration) (T, error) {
    	value, found := redisClient.Get(ctx, key)
    	var result T
    	if !found {
            // exec() is a function that should be executed to fetch needed data.
    		value, err := exec()
    		if err != nil {
    			return result, err
    		}
    		jsonValue, err := json.Marshal(value)
    		if err != nil {
    			return result, err
    		}
    		redisClient.Set(ctx, key, jsonValue, ttl)
    		return value, nil
    	}
    	var val T
    	err := json.Unmarshal([]byte(value.(string)), &val)
    	if err != nil {
    		return result, err
    	}
    	return val, nil
    }

After that our resolvers could be refactored into this:

     func MyCachedResolver1(redisClient *redis.Client) ([]MyExampleType1, error) {
       key := "resolver_result_1"
       return WithCache[[]MyExampleType1](redisClient, context.Background(), key, func() ([]MyExampleType1, error) {
		 return FetchSomethingHeavyFromDB()
	   }, time.Hour*12)
     }

     func MyCachedResolver2(redisClient *redis.Client) ([]MyExampleType2, error) {
       key := "resolver_result_2"
       return WithCache[[]MyExampleType2](redisClient, context.Background(), key, func() ([]MyExampleType2, error) {
		 return FetchSomethingEvenMoreHeavierFromDB()
	   }, time.Hour*12)
     }

Now it looks much better and clearer!

The caching code this example refactors is the one from Ristretto — the most performant concurrent cache library for Go, if you want the full context. For another place where a little type machinery removes a lot of duplication, see implementing enums in Golang. And since Go 1.27 a method can carry its own type parameters, which removes the package-level helper this article works around — what’s new in Go 1.27.

Ristretto is a fast, concurrent cache library built with a focus on performance and correctness.

This library was created by the Dgraph team as a contention-free cache for the Dgraph database.

Let’s dive into the practical example. We are going to build a simple application that gets a list of users from the database. In the first iteration, there will be no caching layer at all. In the second iteration, we will add a Ristretto caching and compare execution time.

Below, you can see that I defined a repository package with the Repository interface and with InMemoryRepository implementation:

package repository

import "fmt"

// Repository interface to handle users data.
type Repository interface {
	GetUsers() map[int]string
}

type InMemoryRepository struct{}

// NewInMemoryRepository constructs and returns InMemoryRepository.
func NewInMemoryRepository() *InMemoryRepository {
	return &InMemoryRepository{}
}

// GetUsers returns 50000 dummy users from the in-memory repository.
func (r *InMemoryRepository) GetUsers() map[int]string {
	users := make(map[int]string)
	for i:=1; i <= 50000; i++ {
		users[i] = fmt.Sprintf("User %d", i)
	}

	return users
}

Next, we are going to call a GetUsers() method 100 times to simulate calling of the same function from several places in the real-world applications:

package main

import (
	"fmt"
	"github.com/alexsergivan/blog-examples/ristretto/repository"
)

func main() {
	for i:=0; i<100; i ++ {
		UsersGetter(repository.NewInMemoryRepository())
	}
}

func UsersGetter(repository repository.Repository) {
	repository.GetUsers()
}

Let’s measure how much time it takes to execute it with time go run main.go:

1.46s user
0.34s system
106% cpu
1.686 total

Next, we are going to add a caching layer to our application.

Don’t forget to get the Ristretto library:

  go get github.com/dgraph-io/ristretto

Inside repository package we inject Ristretto cache:

package repository

import (
	"fmt"
	"github.com/dgraph-io/ristretto"
	"time"
)

type InMemoryRepository struct{
	cache        *ristretto.Cache
}

// NewInMemoryRepository constructs and returns InMemoryRepository.
func NewInMemoryRepository(ristrettoCache *ristretto.Cache) *InMemoryRepository {
	return &InMemoryRepository{
		cache: ristrettoCache,
	}
}

// GetUsers returns 50000 dummy users from the in-memory repository.
func (r *InMemoryRepository) GetUsers() map[int]string {
	key := "users"
	value, found := r.cache.Get(key)
    // If the users data not cached yet, get it from the repository.
	if !found {
		users := make(map[int]string)
		for i:=1; i <= 50000; i++ {
			users[i] = fmt.Sprintf("User %d", i)
		}
        // Adds data to the cache for 1h.
		r.cache.SetWithTTL(key, users, 1, 1*time.Hour)
		time.Sleep(10 * time.Millisecond)
		return users
	}
	return value.(map[int]string)
}

Next, inside the main() function we initiate a new Ristretto cache and pass it to the InMemoryRepository:

  package main

import (
	"github.com/alexsergivan/blog-examples/ristretto/repository"
	"github.com/dgraph-io/ristretto"
)

func main() {
	ristrettoCache, _ := ristretto.NewCache(&ristretto.Config{
		NumCounters: 1e7,     // Num keys to track frequency of (10M).
		MaxCost:     1 << 30, // Maximum cost of cache (1GB).
		BufferItems: 64,      // Number of keys per Get buffer.
	})

	for i:=0; i<100; i ++ {
		UsersGetter(repository.NewInMemoryRepository(ristrettoCache))
	}
}

func UsersGetter(repository repository.Repository) {
	repository.GetUsers()
}

Let’s check how much time it takes to perform the same action:

0.29s user
0.26s system
147% cpu
0.377 total

As you can notice, the total time is 4 times less than in the example without caching layer.

Despite a silly example, I hope you got an idea of how to integrate the Ristretto caching into your application and how it could improve overall performance.

The complete source code you can find here.

Ristretto is safe for concurrent use, which is exactly the problem a plain map does not solve — see concurrent map writing and reading in Go if you want the failure mode in detail. I also refactored this caching layer with generics in how Golang generics minimize the amount of code you need to write. For a cache with a very different failure mode — one that costs you money rather than latency when it silently stops working — see prompt caching.

When you develop web applications, it’s crucial to have a testing strategy. Nobody argues about the importance of unit, functional, and integration testing. Nevertheless, very often developers forget to test how their application works under high load. Even, when we have a “green light” from all our testing stages, including manual testing, better to not release it to production, until you load test it. Otherwise, nobody can guarantee, that application will work properly when 50 users will use it simultaneously.

In this article I’m going to load test our web application from the previous article.

For that, we are going to use a K6 tool, written in Go, and uses JavaScript for scripting.

k6 is a developer-centric, free and open-source load testing tool built for making performance testing a productive and enjoyable experience.

Let’s install this tool:

brew install k6

If you have different from the macOS operating system, please read about others ways to install here.

Next, we create a loadtests folder in the root of our project and inside we add a test.js file, where we are going to write our load tests scenarios:

import { sleep } from 'k6';
import http from 'k6/http';
import { check } from 'k6';
import { Rate } from 'k6/metrics';

export let errorRate = new Rate('errors');

export let options = {
    // Here we define our scenarios.
    scenarios: {
        sign_in_page_test: {
            executor: 'constant-vus',
            duration: '1m',
            vus: 100, // amount of the virtual users
            tags: { test_type: 'signInPage' },
            exec: 'signInPage',
        },
    },
    // List of thresholds.
    thresholds: {
        http_req_duration: ['avg<500'], // avg response times must be below 0.5s
        errors: ['rate<0.1'], // <10% errors
    },
};

export function signInPage() {
    const res = http.get(getDomain() + '/user/signin');
    // Here we check the response status.
    const result = check(res, {
        'status is 200': (r) => r.status == 200,
    });
    // If it's different from 200, add info to the errorRate.
    errorRate.add(!result);
    sleep(3)
}

// Gets the domain from the environment variables.
function getDomain() {
    return __ENV.DOMAIN;
}

Above, we have declared a scenario to load test /user/signin page with 100 virtual users who continuously accessing our page in parallel.

To run this load test, we need to execute this command in the terminal:

k6 run --env DOMAIN="http://localhost:8777" ./loadtests/test.js

After some time we will see this results output:

As you could notice, all our defined thresholds were satisfied. So far so good!

Now, let’s see how we can integrate load testing to the Gitlab CI pipeline. Fortunately, it’s easy to do :)

Inside .gitlab-ci.yml we need to add this:

stages:
  - loadtest

loadtesting:
  stage: loadtest
  image:
    name: loadimpact/k6:latest
    entrypoint: [ '' ]
  variables:
    DOMAIN: '[your-testing-domain-here]'  
  script:
    - echo "executing K6 load tests in k6 container..."
    - k6 run --env DOMAIN=${DOMAIN} ./loadtests/test.js

That was it! I’ve described just an idea how you can easily integrate the load testing in your development routine. In the real-world situations you might create more complex load testing scenarios, which will help you find weak points of your application and prevent unexpected downtimes.

I wish you happy coding and no pagerduty calls during the night!😉

Once you can measure, you have something to optimise against. Two places I usually look first: 103 Early Hints in Go for front-end latency, and Ristretto caching for the expensive calls behind it. It is also the right tool to prove your graceful shutdown really does keep errors at zero during a deploy.

Let’s imagine a situation when you want to do an A/B test on your website, where 50% of users should see new headline text on the page. Other 50% of visitors will continue see the old page. In this case, all your server-side manipulation about splitting users to different versions will be ignored by nginx cache (of course, if you have it).

It happens because nginx, by default, has this configuration:

proxy_cache_key $scheme$proxy_host$request_uri;

So, it will use the same cache key for all users, who requests a page with the same url.

Luckily, nginx allows us easily to customize proxy_cache_key! What we need to do, it’s just to add a specific cookie to this key:

proxy_cache_key $scheme$proxy_host$request_uri$cookie_MY_COOKIE_NAME;

And that’s it! After this, if userA has MY_COOKIE_NAME=A and userB has MY_COOKIE_NAME=B they will receive different versions of page by the same url.

If you need more complex behaviour, where you won’t use hardcoded cookie name in your nginx config, you can do something like this:

if ($http_cookie ~* "ab_(.*?)=([\w-]+)" ) {
  set $abcookie $1$2;
}

proxy_cache_key $scheme$proxy_host$request_uri$abcookie; 

As you can see, you can use $http_cookie and generate proxy_cache_key based on specific cookie patterns. In this concrete example we check if http cookies contains cookie with regex pattern ab_(.*?)=([\w-]+) and if this cookie exists, we generate new variable for proxy_cache_key`.

Caching at the proxy is only one layer. For the one inside your Go process, see Ristretto — the most performant concurrent cache library for Go, and for shaving latency off the browser side, 103 Early Hints in Go.