Showing Posts From

Software engineering

Go and Rust Are Winning. Here's Why 2025 Was the Tipping Point.

Ten years ago, if you told a hiring manager your primary language was Go or Rust, you would have gotten a polite nod and a question about whether you also knew Java. Today those same hiring managers are posting roles that specifically require Rust or Go experience and struggling to fill them. Something fundamental shifted, and 2025 was the year it became undeniable. The Numbers First Stack Overflow's developer surveys have tracked Rust as the most admired language for years running — a streak that continued through 2025. But admiration and adoption are different things, and for most of Rust's life the gap between the two was the main story. That gap closed meaningfully over the past twelve months. Go's trajectory is different but equally significant. It quietly became the lingua franca of cloud-native infrastructure — Kubernetes, Docker, Terraform, Prometheus, and most of the CNCF project catalog are written in Go. In 2025, Go crossed a threshold where it stopped being "the language Google uses for its tools" and became the default choice for new backend services at a broad range of companies, from startups to enterprises. What Changed for Rust Rust's turning point was not a single moment but several things arriving at once. The US government got involved in an unusually direct way. The NSA, CISA, and a coalition of cybersecurity agencies published guidance explicitly naming memory-unsafe languages as a systemic risk and recommending migration toward memory-safe alternatives — with Rust named repeatedly as the leading systems-programming option. When federal agencies start writing technical language recommendations, industries that sell to the government pay attention, and then everyone else starts paying attention too. Rust's presence in the Linux kernel went from experimental to structural. The initial Rust support merged in kernel 6.1 was cautious and limited, but by 2025 multiple subsystems had Rust drivers in mainline, and the kernel development community's conversation shifted from "should Rust be here?" to "how do we grow the Rust contributor base?" That's a significant change in posture. Microsoft's investment became visible. The Windows team has been rewriting core system components in Rust for years, and in 2025 more of that work became public. When the company responsible for the world's most widely deployed operating system starts treating Rust as a load-bearing part of its platform strategy, the language's legitimacy in systems programming is established. Android crossed 21% of new code being written in Rust, and Google reported a corresponding drop in memory safety vulnerabilities in those components. The security case for Rust stopped being theoretical. What Changed for Go Go's story in 2025 was less dramatic than Rust's but arguably more economically significant. Generics, which landed in Go 1.18, had a rough first reception — the implementation was slow and the community was divided about whether Go needed them at all. By 2025, the generics implementation had matured enough that idiomatic generic code became possible without the performance penalties that made early adopters skeptical. That resolved the biggest open technical complaint about the language. Go 1.22 and 1.23 shipped range-over functions and improved the toolchain in ways that made large codebases more manageable. The language's compile times and deployment story — a single static binary, trivial to containerize — continued to make it the pragmatic choice for teams who need to ship and operate services at scale. The clearest signal of Go's mainstream status: it became the default language for new services at companies that are not primarily software companies. Banks, retailers, healthcare companies building internal platforms — these organizations picked Go because it was learnable, because the toolchain was sane, and because the ecosystem of libraries for the things they actually needed (HTTP services, database access, cloud SDKs) was excellent. They're Not Competing With Each Other The framing of "Go vs Rust" misses the point. They occupy genuinely different spaces. Rust is for when you need control over memory layout, when you're writing something that touches hardware or runs in constrained environments, when correctness guarantees matter more than development speed, or when you're extending an existing systems codebase (OS, browser, embedded firmware). Go is for when you're building networked services, when team velocity matters, when you want straightforward concurrency that doesn't require understanding memory ownership semantics, and when you need something you can hire for. The interesting question isn't which one wins — they're both winning, in different domains. The interesting question is what they're displacing, and the answer is increasingly: C++ in systems programming (Rust), and Java/Python in backend services (Go). Both of those are genuinely significant disruptions to ecosystems that have been stable for twenty years. What It Means for Developers If you're early in your career, learning one of these languages is no longer a speculative bet on the future — it's meeting the market where it already is. If you're a senior engineer who has avoided both because your current stack is working fine, the window for that posture is narrowing. The infrastructure being written today in Go and Rust is what you'll be maintaining and extending in five years. Neither language is without friction. Rust's learning curve around the borrow checker remains genuinely steep, and no amount of improved tooling fully eliminates the hours you'll spend fighting the compiler until the mental model clicks. Go's simplicity is real but it also means you'll write more boilerplate than in more expressive languages, and the error handling story is still something people argue about. But both languages are mature, well-tooled, well-documented, and backed by organizations with serious long-term commitments to them. The risk calculus that made them speculative bets in 2015 doesn't apply in 2025. They're infrastructure now.