Python Is Easy. Go Is Simple. Simple != Easy

Advocates of Go and Python clash over whether “simple” or “easy” languages lead to better long‑term software. Go is praised for uniform style, fast compilation, static binaries, and suitability for large, multi‑team projects, but criticized for verbosity, manual error handling, weak abstractions, and null‑related footguns. Python is lauded for its rich ecosystem, quick ramp‑up, and expressive syntax, yet many point to fragile dependency management, performance limits, and increasing complexity as its popularity and feature set have grown.

Go’s boilerplate, error handling, and verbosity

  • Many find Go’s boilerplate (especially if err != nil) tedious and visually noisy; others see it as explicit, predictable, and easy to skim.
  • Error handling is debated: proponents prefer explicit returns over exceptions; critics note Go doesn’t force checking errors and can silently continue with bad data.
  • Tools like go vet, linters, and ErrCheck are recommended to catch unchecked errors, but skeptics argue relying on tools plus boilerplate is fragile.
  • defer is appreciated but function-scoped behavior makes patterns like “defer in a loop” awkward; some wish it were block-scoped.

Go’s simplicity vs expressiveness

  • Supporters argue Go is “simple, not easy”: limited features, fast compiles, stable BC, and uniform style across codebases.
  • Critics say the simplicity is overdone: missing sum types, robust enums, non-nullable types, ergonomic error propagation, and richer stdlib lead to verbose, error-prone patterns (multiple bespoke min, filter, etc.).
  • Generics and recent stdlib additions (e.g., slices, maps, min/max) improve things but arrived late.

Go in large projects and teams

  • Advocates claim Go scales well for big, long-lived, multi-team codebases: code “looks the same,” performance is “good enough,” and static typing with simple concurrency is a win.
  • Counterexamples: large Go codebases can be deeply abstracted with interfaces and tiny methods, becoming Java-like “onion layers.” Overuse of interface{} and unsafe tricks can cause non-local breakage.
  • Some report million-LOC Go systems as nightmares; others say any million-LOC project is painful regardless of language.

Python’s ease and ecosystem vs fundamentals

  • Python is praised for low entry barrier, concise syntax, rich libraries (especially for ML/data), and productivity for scripts and small/medium apps.
  • Criticisms include: packaging and deployment friction, runtime incompatibilities across versions, performance, dynamic typing/duck typing issues, monkey patching, and “tacked-on” typing.
  • Some argue tools like mypy and virtualenv mitigate many issues; others say core problems (nullability, lack of sum types, speed) remain.

Simple vs easy, and alternatives

  • The “Simple vs Easy” dichotomy (via Rich Hickey) is repeatedly invoked: Go aims for simplicity; Python for ease; Clojure and FP languages are suggested as “simple” in a deeper sense but have steeper learning curves and weaker ecosystems.
  • Several conclude language choice should prioritize runtime, tooling, and ecosystem over purity of language design.