(Don't) Leave No Trace • The Applied Go Weekly Newsletter 2025-07-06
Your weekly source of Go news, tips, and projects
(Don't) Leave No Trace
Hi ,
Logs and traces are nice and useful ... until they start filling your disks. It would be much better to capture only the meaningful parts. Flight recorders do this: They collect flight data in a continuous loop, overwriting old data. Dashcams do the same to deal with limited capacity (and in some countries also to comply with the law). Some dashcams save the last couple of minutes of recordings to an extra file if they detect a car crash. Wildlife cams only record a scene when they detect motion.
With Go 1.25, you can collect traces like a dashcam or wildlife cam: Start, stop, and collect trace output programmatically through timing or on a specific event. The new FlightRecorder type makes this possible—more in the Spotlight below.
Like a good wine, Go gets only better over time, steadily and modestly(*)
I love all those seemingly small but highly effective changes that come with each Go release, don't you, too?
(*) Well, unlike aging wine, Go made two comparatively big advancements: modules and type parameters. But as the saying goes, the exception proves the rule.
Featured articles
Go is 80/20 language
The Pareto principle says 80% of a result can be achieved with 20% of the effort (while the remaining 20% of the result require 80% of the effort). The Go language design seems to have embraced this principle, according to Krzysztof Kowalczyk.
How to manage configuration settings in Go web applications – Alex Edwards
Alex Edwards lists the three main ways of getting configuration settings into your code (flags, environment variables, and configuration files) and discusses how to actually get a config value to where it shall be used.
The art of benchmarking and profiling
Performance analysis typically includes two main steps: benchmarking the overall performance and finding bottlenecks through profiling. Shubham Biswas illustrates both steps with a trie structure as an example.
Podcast corner
Cup o' Go: 🛠️ Can we fix it? No we can't! 🧭 Plus, exclusive behind-the-scenes look at Go West Conf.
Miriah Peterson & Derrick Laird join Jonathan and Shay to have a chat about the Go West conference (whose name spawned the important question: Pet Shop Boys or Village People?)
Fallthrough: SIMD & Go
Single Instruction, Multiple Data (SIMD, pronounced "simdee") is a type of parallel computing designed to process multiple data points simultaneously. Now, parallelism isn't concurrency, so how could Go, a language built for concurrency, make use of SIMD architectures? Clément Jean has explored the use of Go with SIMD (example) and talks to Matt and Angela about when to use SIMD and how SIMD and Go go together.
No Silver Bullet: AMA #1: Clean Architecture, Learning, Event-Driven, Go
In the 10th episode of No Silver Bullet, Robert and Miłosz answer questions from the community before taking a summer break.
Spotlight: Don't leave no trace: capture the context of significant events with trace.FlightRecorder (new in Go 1.25)
When you need to capture information about activity in your application right before a certain event, capturing a trace seems the way to go. But collecting (and digging through) loads of trace output for inspecting a few seconds of activity isn't fun. It would be much better to record only the last few seconds of activity and drop the rest, to save space and energy.
In Go 1.25, the new type FlightRecorder makes this possible (and easy to implement). FlightRecorder puts a sliding window over the execution trace produced by the runtime. At predefined events, the application can call FlightRecorder.WriteTo() to snapshot the current window and write it to an io.Writer.
Implementation is quite straightforward. Assume you have a long-running process, such as a Web server, and you want to occasionally collect a trace output from certain events.
- Create a
FlightRecorderconfiguration (if the default window size settings don't suit) - Create a new
FlightRecorderobject - Define mechanisms to call the methods
Start()to start tracingStop()to stop tracingWriteTo()to capture the current trace window to a file
A minimal implementation could look like this:
At startup, Create and start the flight recorder:
cfg := trace.FlightRecorderConfig{
MinAge: 5 * time.Second,
}
// Create and start the flight recorder
fr := trace.NewFlightRecorder(cfg)
if err := fr.Start(); err != nil {
log.Fatalf("Failed to start flight recorder: %v", err)
}
defer fr.Stop()
// ... continue with running the app
At certain interesting events, add code to call WriteTo(). Or, if you would like to trigger trace output manually, have your code react to a Unix signal like SIGUSR1 to trigger a call to WriteTo:
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGUSR1, syscall.SIGTERM, syscall.SIGINT)
for {
sig := <-sigChan
switch sig {
case syscall.SIGUSR1:
fmt.Println("Received SIGUSR1, saving trace...")
if err := saveTrace(fr); err != nil { // see below
log.Printf("Failed to save trace: %v", err)
} else {
fmt.Println("Trace saved to 'trace.out'")
}
case syscall.SIGTERM, syscall.SIGINT:
fmt.Println("Received termination signal, shutting down...")
close(stopWorkload)
wg.Wait()
return
}
}
}
And saveTrace() would then test if the flight recorder is running, and if so, capture the current trace window to trace.out:
func saveTrace(fr *trace.FlightRecorder) error {
if !fr.Enabled() {
return fmt.Errorf("flight recorder is not enabled")
}
file, err := os.Create("trace.out")
if err != nil {
return fmt.Errorf("failed to create trace file: %w", err)
}
defer file.Close()
n, err := fr.WriteTo(file)
if err != nil {
return fmt.Errorf("failed to write trace data: %w", err)
}
fmt.Printf("Wrote %d bytes to trace.out\n", n)
return nil
}
That's a convenient way of tracing your code when needed without needlessly spooling out megabytes of trace information just to capture a few bytes of interest.
The full code is avaialble in the Go Playground, but note that this time, the code isn't useful inside the playground. Copy it to your machine and run it (with Go1.25rc1 or later!), then you can send a USR1 signal to the process with...
kill -s USR1 <pid>
...where <pid> is the PID the app prints out at the start, and inspect the trace with...
go tool trace trace.out
...but ensure to use Go 1.25 RC1 or later here as well, or you'd get an "unsupported trace version: go 1.25" error message.
Now, whenever you need to inspect a trace of the recent activities, fire a USR1 at the app and see what's going on inside.
Quote of the Week: Bugs For A Lifetime
Give someone state and they'll have a bug one day, but teach them how to represent state in two separate locations that have to be kept in sync and they'll have bugs for a lifetime.
More articles, videos, talks
Go Cookbook - Practical Go Code Snippets and Examples
A cookbook with 222 code snippets collected over the years. (Repo here
The Evolution of Caching Libraries in Go - Otter
From the author of Otter.
(Ab)using channels to implement a 3D pipe game
"Fantastic. Horrible. Fantorrible. Horritastic. Words fail me." – /u/jerf
Google Single Sign-On with Keycloak (Keycloak 26.2.0) | by codewithaddy | Jun, 2025 | Medium
Adding authentication to an app may seem like a daunting task, but the author learned that integrating Google SSO into a Go project is not that hard with Keycloak, an open source identity and access management solution.
An optimization and debugging story with Go and DTrace
A debugger lets you step through the code and inspect data thorougly, but if you want to observe running code, DTrace might come in handy.
A Zero-Sized Bug Hunt in golang.org/x/sync – Fillmore Labs Blog
The second part of The Perils of Pointers in the Land of the Zero-Sized Type – Fillmore Labs Blog
Gist of Go: Semaphores
Anton Zhiyanov diligently works on his new interactive book "Gist of Go: Concurrency." Here is the latest chapter, introducing semaphores.
Flags for discoverable test config in Go
Did you know you can specify custom flags for go test? The flags package works for tests like it does for any other Go binary; you only need to know where to set up and parse the flags.
No Silver Bullet: AMA #1: Clean Architecture, Learning, Event-Driven, Go
In their 10th episode, Robert and Miłosz
Projects
Libraries
GitHub - inkyblackness/imgui-go: Go wrapper library for "Dear ImGui" (https://github.com/ocornut/imgui)
The author of this package is a long-time user of the archived inkyblackness/imgui-go that they forked to make some updates necessary for their project.
GitHub - pardnchiu/go-cron: A lightweight Golang scheduler supporting standard cron expressions, custom descriptors, and custom intervals. Easy to use for writing scheduling with Golang.
A Cron-like scheduler package optimized for minimal resource usage and package size.
Tools and applications
Union Station by hopfenherrscher
A game built with Ebitengine: Build train routes to connect cities on a low budget. Source code here
Ahaana Ravishankor
Arinay Dhar built a site based on PocketBase for a musician friend to present her songs.(Source code here)
GitHub - zserge/pennybase: Poor man's Backend-as-a-Service (BaaS), similar to Firebase/Supabase/Pocketbase
Definitely not for production: A backend-as-a-service in ~750 lines of code with no dependencies and no database.
Lox
Lox generates an LR(1), dependency-free parser with type safe actions and artifacts.
Why Grog? | Grog Docs
If you plan to create multi-languge monrepos and Bazel feels overkill to learn and use, Grog could be the "minimalist's Bazel" your're looking for.
GitHub - BobdaProgrammer/doWM: A beautiful window manager for x11
A tiling X11 window manager built entirely in Go (which isn't quite the norm... the only other Go-based WM I know is FyneDesk).
Completely unrelated to Go
Running and storing 3+ million LLM AI requests without spending $100,000
What would you do if you plan to summarize more than three million documents (code, in this particular instance) without spending a fortune? Ben E.C. Boyter found a solution by combining a Mac mini, Ollama, and home-harvested solar power into a low-budget code summarizer.
You can use fzf to review git commits
How do you review Git commits? Julia Evans discovered that fzf, alias Fuzzy Finder, makes a great ad-hoc Git commit review tool.
That boolean should probably be something else
Booleans are a quick and easy means to flag some condition—but there are situations where a boolean is a suboptimal choice.
Happy coding! ʕ◔ϖ◔ʔ
Questions or feedback? Drop me a line. I'd love to hear from you.
Best from Munich, Christoph
Not a subscriber yet?
If you read this newsletter issue online, or if someone forwarded the newsletter to you, subscribe for regular updates to get every new issue earlier than the online version, and more reliable than an occasional forwarding.
Find the subscription form at the end of this page.
How I can help
If you're looking for more useful content around Go, here are some ways I can help you become a better Gopher (or a Gopher at all):
On AppliedGo.net, I blog about Go projects, algorithms and data structures in Go, and other fun stuff.
Or visit the AppliedGo.com blog and learn about language specifics, Go updates, and programming-related stuff.
My AppliedGo YouTube channel hosts quick tip and crash course videos that help you get more productive and creative with Go.
Enroll in my Go course for developers that stands out for its intense use of animated graphics for explaining abstract concepts in an intuitive way. Numerous short and concise lectures allow you to schedule your learning flow as you like.
Christoph Berger IT Products and Services
Dachauer Straße 29
Bergkirchen
Germany