Go’s Big Mistake

Summary of the Video (Tech Concepts + Product/Language Analysis)

Personal Context / Motivation

• The speaker has long used Go for systems and CLI-oriented work (claiming they built a large concurrent Doom project in Go).
• They describe Go as historically simple and consistent, emphasizing:
  • A single formatter
  • Uniform code structure
  • “Only one way” to write code This reduced cognitive overhead and made Go feel predictable.

Major Change Discussed: Go 1.27 Generics on Method Receivers

• The video highlights a new capability: generics now work on method receivers (previously restricted to free functions).
• The speaker uses an example of a generic Result-like pattern that:
  • Holds a value plus an error
  • Includes an “is okay” check when error == nil
  • Supports chaining operations such as:
    • “read → convert/stringify → parse → unwrap”
  • Propagates errors during parsing if the input can’t be parsed.

They argue:

• The resulting style can look nice
• But it may also undermine Go’s long-standing “one way” philosophy.

Critique: Go’s “One Way” Becomes Fragmented

• The speaker predicts that adding these kinds of features (generics and other constructs) will cause more divergent codebases.
• Result: Go could become less uniform, requiring developers to learn additional “layers” and abstractions per project.

Example critique:

• They claim it’s difficult to create a single highly generic “convert” function that works for any arity of function arguments.
• They contrast this with TypeScript, where such flexibility is described as “very easy”.
• Overall implication: Go’s generics may feel less powerful/ergonomic than in languages with more flexible generic function signatures.

Revisiting Go’s Historical Stance on Error Handling

The speaker contrasts Go’s explicit style with “fancy” alternatives, such as:

• Exceptions / try-catch approaches
• Rust-like syntactic sugar

They acknowledge Go once had a major wart:

• Error handling verbosity (often many lines are spent on error handling rather than core logic)

But they value what Go achieved:

• It remained explicit and consistent: every operation that might fail forces handling.
• Their claim: Go chose to keep this model rather than add more ergonomic error-handling mechanisms—helping preserve uniformity.

Additional Critique: Iterators and “Hidden Cost”

• The speaker argues new iterator features can hide what’s actually happening.
• This conflicts with what they previously enjoyed about Go: being able to clearly reason about the cost/behavior of control flow.

Overall Thesis: Go Is “Going in the Wrong Direction”

• They reference a “very good article” with a similar premise: “Go’s evolving in the wrong direction.”
• Their conclusion:
  • If you want a more complex or fancy type system, don’t use Go—use a language that already excels at that.
  • They characterize Go’s trajectory as a “Rust-light / TypeScript-like” worst-of-both-worlds outcome:
    • More features get added
    • But Go may not surpass the ecosystems it resembles

Proposed Alternative: Odin as the “Spiritual Successor”

The speaker says their interest has shifted to Odin, describing it as a better fit because it offers:

• Directory/package-level shared types (instead of file-level modules)
• Explicit overloading and support for polymorphism, including parametric polymorphism
• More control over allocations/memory
• A language aimed at games/graphics and C-like straightforward programming

They argue Odin better matches the idea of a language with a defined purpose, similar to how Go used to feel.

Non-Technical / Engagement

• The video ends with the speaker asking for viewer input (“opinions”) and prompting likes/subscribes.
• The speaker identifies as The Primagen.

Main Speakers / Sources

• Main speaker: The Primagen (author/speaker of the video)
• Referenced source (not fully shown): Go’s evolving in the wrong direction (a “very good article”)