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

A backend engineer with six years of Java and Kotlin experience, plus recent Rust work, is learning Go in 2026 because many target teams use Go in production. The engineer finds Go's simplicity, built-in concurrency via goroutines and channels, and lack of class hierarchies appealing, though error handling feels repetitive. A series of posts will document the learning process, focusing on production-grade services.

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. 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. 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. 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. 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. 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: go test habitsIf 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.