Why I'm Learning Go in 2026 (A Java/Kotlin/Rust Engineer's Take)

Why I'm Learning Go in 2026 (A Java/Kotlin/Rust Engineer's Take)

I've spent the better part of six years writing Java and Kotlin in production — FinTech systems, logistics platforms, EdTech backends. Somewhere in the last year I also went deep on Rust, building an AI gateway and a RAG server from scratch. So the obvious question is: why pick up another language?

Short answer: because every team I want to work for in 2026 is either already running Go in production, or wishes they were.

This post kicks off a series where I document learning Go properly — not "hello world and a for loop" learning, but the kind that ends with a real, production-grade service. If you're a backend engineer coming from the JVM world (or from Rust, or anywhere else) and curious whether Go is worth the detour, this series is for you.

The Itch That Started This

Most of my recent work has been in Rust, and I love it — the type system catches entire categories of bugs before they ship, and the performance ceiling is hard to beat. But Rust also makes you pay for that safety in compile times, borrow-checker fights, and a learning curve that scares away a chunk of teams who'd otherwise want those benefits.

Go takes a different bet: give up some of that compile-time rigor, and in exchange get a language so simple you can read a stranger's codebase on day one. After enough job descriptions and system design conversations mentioning Go in the same breath as "we need to move fast and onboard people quickly," I stopped arguing with the trend and decided to just learn it properly.

What Go Actually Optimizes For

Coming from Java and Kotlin, the first thing that struck me wasn't a feature — it was an absence. No class hierarchies to design upfront. No generics-heavy abstractions to reach for by default. No build tool wars (Maven vs Gradle vs whatever). Go's design philosophy is almost stubbornly opinionated: there's one way to format code (gofmt decides, not you), one way to manage dependencies (Go modules), and a standard library that already does most of what you'd otherwise reach for a framework to do.

A quick side-by-side of what's missing compared to the JVM world tells you a lot about Go's priorities:

JVM World	Go World
Class inheritance	Composition + interfaces
Checked/unchecked exceptions	Explicit error return values
Threads + thread pools	Goroutines + channels
Maven/Gradle build config	go.mod, almost no config
Annotations for DI, validation, etc.	Plain functions, explicit wiring

None of this means Go is "Java but simpler" — it's a genuinely different way of thinking about structuring a backend service. The interface system in particular is going to get its own post, because it inverts how I'm used to designing for abstraction.

Concurrency Was the Real Hook

If I'm honest, goroutines are why I stopped procrastinating on this. In Java, concurrency means thinking about thread pools, ExecutorService, and increasingly, virtual threads if you're on a recent JDK. In Go, concurrency is baked into the language itself:

func main() {
    results := make(chan string)

    go fetchFromService("orders", results)
    go fetchFromService("payments", results)
    go fetchFromService("inventory", results)

    for i := 0; i < 3; i++ {
        fmt.Println(<-results)
    }
}

func fetchFromService(name string, results chan<- string) {
    // simulate a network call
    time.Sleep(100 * time.Millisecond)
    results <- fmt.Sprintf("%s: done", name)
}

Three goroutines, a channel to coordinate them, no thread pool configuration, no Future<T> wrapping. That's the entire concurrency model for a huge percentage of real-world backend use cases. I'll go deeper into goroutines and channels — including where they bite you — in part 3.

Where I Think Go Will Push Back

I don't want this series to read like a sales pitch, so here's what's already bothering me a few weeks in:

Error handling feels repetitive. Coming from exceptions, writing if err != nil { return err } after every single call feels almost aggressively manual. I know there are good reasons for it (explicit control flow, no hidden stack unwinding), but my fingers haven't agreed yet.

No generics-first mindset (still adjusting). Generics arrived in Go 1.18, but the standard library and most idiomatic code still leans on interfaces and any in ways that feel like a step back from Kotlin's type system or Rust's traits.

Smaller batteries-included story for some things. No built-in ORM, no Spring-style dependency injection container, no Rocket/Axum-style ergonomic web framework baked into std (though Gin and Echo close that gap fast).

I expect most of these complaints to soften as I get further in — they usually do.

What This Series Will Actually Build

Rather than a string of disconnected toy examples, this series builds toward one real artifact: a production-grade Go backend service, the same way I approached rust-ai-gateway and BlazeRAG. Here's the planned route:

• Part 2 — Go's type system: structs, interfaces, and composition over inheritance
• Part 3 — Goroutines and channels, and where naive concurrency breaks
• Part 4 — Error handling patterns that don't make your code unreadable
• Part 5 — Building a real REST API with Gin
• Part 6 — Testing: table-driven tests, benchmarks, and go test habits
• Part 7 — Turning all of it into a production-grade service, ready to ship

If you're also coming from Java, Kotlin, or Rust and weighing whether Go is worth the time, follow along — I'll be honest about what's genuinely better, what's just different, and what I still miss from the languages I came from.

What's been your experience picking up Go from a JVM or Rust background? I'd genuinely like to know what surprised you, good or bad.