Go: a fresh reintroduction after Rust's allure

Published: 2026-08-24

The past year, I’ve been on what I’ve been calling a “Rust bender”. Obsessed with its performance guarantees, ownership model, and zero-cost abstractions, I found myself enacting the “rewrite everything in Rust” mantra. But after what seems like forever surrounding myself in an ecosystem dominated by complexity, I found myself nostalgic for a simpler maybe more innocent time; nostalgic for writing in Go.

Here’s why I added Go back into my tool-belt and why you might want to consider adding it to yours (if you haven’t yet)!


A case for simplicity

Go has become my go-to for projects where I need speed without complexity. Whether it’s fast compile times, minimalist syntax, or its dead simple approach to concurrency with goroutines, Go has got your back. Puzzling about Rust’s memory management types, lifetimes, and build tooling, I realized one of Go’s key advantages not just simplicity, it how it’s** so efficiently simple. The project that got me writing in Go again reminded me of this principle.

For my homelab, I like to maintain multiple focused Kubernetes clusters. Over time, the amount of scripts I was working with was starting to become a maintenance nightmare, and I knew consolidating them into a unified CLI would ease the pain. This collection of scripts did a few things:

  • Check that kubectl and talosctl contexts were in sync.
  • Check that certain environment variables were available in the shell (i.e. Talos node IP’s) and inject them from configuration files if necessary.
  • Add production flags and guardrails to prevent running anything meant for development clusters from running against production clusters.

Doing this in Rust did not seem justifiable; I just needed what was essentially a glorified bash script. So I made the leap and wrote it in Go.

Here’s what stood out to me during the process:

  • Configuration-driven logic: Loading configuration files into structs was as easy as it could get using only the standard library.
  • Easy handling of system calls: Calling kubectl and talosctl was also super easy using standard library tools for forwarding command I/O.
  • Performance without the pain: Rust’s abstractions are fantastic, but that really only matters when memory management is key to the program. My project was not that. However, Go still allowed me to have similar guarantees like type checking, built-in testing, and portability via a statically compiled binary without the hassle.

Why Go won this time

I felt a little guilty about it being “too easy”. Almost everything I needed was provided by the standard library, and statically compiling the end result was as easy as changing a single environment variable. But in the end, I knew Go was the right choice for the scope of my project. Go’s design philosophy shines by being opinionated in a way that limits your possible choices. And by limiting your choices, Go silently leads to reaching solutions faster. Its m.o. is about getting things done instead of being clever.

Don’t abandon a language just because it’s not the “coolest.” Rust is amazing, but Go’s strengths are different, and sometimes exactly what you need. I’m still going to be writing in Rust, it itches a scratch that’s hard to pin down. But I appreciate I have reacquainted myself with a tool for smaller scopes.

Do you have a cool idea? I love helping bring complex visions to life.

Say hi or follow me here: