Picking A Language In 2025

Choosing a programming language for 2025 isn’t just a technical decision—it’s a long-term bet on ecosystem maturity, tooling, and how much time a developer will spend becoming “good” rather than merely productive. The core tension driving the discussion is that the speaker’s current work depends on lots of asynchronous, multi-service workflows (aggregating Twitch chat, recording and decoding audio via Whisper, then combining results into a final voice output), and that requirement doesn’t obviously map to where many newer languages are investing their design effort.

Go remains the default because it delivers exactly the kind of runtime behavior that makes these pipelines feel effortless: goroutines and green-thread scheduling make “do two things at once, then come back” straightforward. The tradeoff is emotional and philosophical. Go is described as full of “foot guns” and shallow depth—easy to learn quickly, but hard to become deeply excellent at because it lacks the richer language mechanics that invite mastery. Rust, by contrast, offers depth and capability, but the speaker reports a sustained lack of joy and growing frustration, even after multiple years using it. The result is an “emotional crisis” about whether to stick with Go’s productivity or switch to a language that offers deeper metaprogramming and a more rewarding path to expertise.

That’s where Zig enters the shortlist. Zig’s compile-time metaprogramming (“comp time”) is framed as a compelling middle ground: it stays within Zig rather than forcing developers into a separate macro language. The idea is that compile-time execution can generate code—effectively producing specialized functions based on reflection-like logic—without the conceptual split found in other systems. Odin and Elixir are also mentioned as having metaprogramming potential, with Odin highlighted for its professional examples (including an “embergen” project) and Elixir noted for metaprogramming generally.

But the conversation repeatedly returns to timing and risk. Becoming proficient takes far longer than learning syntax, and better programmers face a bigger burden: they must invent or discover the “great ways” to do things in a language before the community has fully settled best practices. Meanwhile, the language landscape is moving quickly, so picking now can mean doing extra work that might be obsolete in a decade—especially if tooling, adoption, or standard-library support for web/service integration lags behind.

The discussion also critiques “overselling” as a pattern that can lead to widely adopted but flawed languages—an outcome associated with C++. In contrast, Odin and Zig are praised for a more restrained posture: slower, more careful maturation rather than pushing adoption prematurely.

Ultimately, the speaker’s decision criteria narrow to two things: (1) whether a candidate language can handle the web-service aggregation workload as smoothly as Go, and (2) whether metaprogramming is strong enough to support long-term, serious development. The proposed next step is practical experimentation—spending time building small projects (like a tower defense in Zig) and then testing Odin, Zig, and potentially J (in beta) to see which environment feels most capable and enjoyable. The “best” language would be one that enables the speaker’s preferred style of vector/multicore-oriented computation without forcing an awkward paradigm shift, and that can be used confidently for the next ten years.