Leaving Google

Go’s Origins and Unexpected Success

• Commenters note that Go’s creators initially seemed to hope mainly to influence other languages, not to dominate; the modest tone is read as humility, not self‑denigration.
• Compared with internal or niche languages (Hack, Flow, various Google‑internal ones), Go is seen as “unreasonably successful,” far beyond typical corporate‑born languages.
• Early adoption was considered risky both technically and because of fear Google might kill it, given its history of deprecating products.

Ian’s Departure and Go Project Changes

• The key puzzle in the blog post is the line that Google, Go, and the programming environment have changed, making the author “no longer a good fit.”
• Commenters widely infer some mix of performance‑ladder pressure, management demands, and shifting priorities (especially toward AI), but specifics remain intentionally unstated.
• There is concern that losing original core people (also noting leadership changes in the Go team) could weaken Go’s “core ethos,” though others say strong but less‑visible leadership remains.

Perceived Cultural Shift at Google

• Many describe a long decline from an engineer‑driven, experimental “early Google” to a process‑heavy, cost‑cutting, MBA‑driven corporation.
• Examples cited: shrinking perks, less autonomy, real quotas for low ratings, pressure to move work to lower‑cost regions, and an expectation that senior ICs work on AI to show “enough impact.”
• Several ex‑employees say high‑level engineers now leave out of frustration rather than for new opportunities. Others push back, noting some benefits (e.g., parental leave) improved.

Management, Strategy, and Middle‑Layer Critique

• A recurring thread is frustration with upper‑middle management: unclear or content‑free “strategies,” political turf‑wars, treating engineers as fungible “resources,” and reassignments misaligned with skills.
• A linked critique from another ex‑Googler about the org housing Go, Dart, Flutter, and Firebase is seen as thematically similar.
• Some argue people leave “situations,” not just direct managers, but many still see weak management and loss of vision as central.

Go’s Current Role and Use Cases

• Despite “hype” fading, commenters see Go as a stable, boring, high‑utility language: especially strong for network services, CLIs, Kubernetes tooling, and cloud/serverless workloads.
• Strengths cited: fast compilation, static binaries, simple spec, excellent standard library, goroutines/channels, built‑in testing and profiling, gofmt‑enforced consistency, and relatively low dependency sprawl.
• Comparisons:
  • Versus Node.js: much better raw performance, types and tooling; Node favored for JS familiarity and ecosystem.
  • Versus Rust: Go is simpler and faster to work with; Rust offers more safety but more complexity (borrow checker, async coloring).
  • Versus C#/Java/Python: Go seen as a “more robust Python” or leaner alternative to OO stacks, especially for backend services.

Tooling, Compilers, and Spec Design

• The existence of two compilers (gc and gccgo) is praised as a way to force spec clarity when behaviors diverged.
• GCC Go is described as niche (unsupported generics, mainly for unusual architectures); many expect it to fade without new maintainers.

Personal and Community Impact

• Multiple commenters recount positive interactions with the author: fast, thoughtful reviews; politeness; and hands‑on involvement even in routine code review.
• Several say the language and its community were significantly shaped by this style of engagement and worry Go will feel more “corporate” without it.