While the article raises some valid critiques, it often overlooks the fundamental tradeoffs that make Go successful in its niche. Go’s simplicity is not a flaw but a deliberate choice, enabling rapid onboarding and maintainable code for large teams. Its explicit error handling may seem verbose but ensures clarity and avoids hidden surprises common in exception-heavy languages. The complaints about ecosystem isolation and tooling ignore the fact that Go provides powerful built-in tools like pprof and dlv, which are better suited for Go’s runtime than general-purpose alternatives. Go isn’t trying to be Rust or Python—it’s a pragmatic tool for scalable, performant systems.

▲ euroderf 7 months ago | parent [-]

This. And there is one technique that would help in this.

Too often I see code like "xyz := pkg1.SomeFunc(a, b, c)" that makes xyz's type non-evident, especially when interfaces are involved.

Please write Go code like

  var xyz pkg2.SomeType

  xyz = pkg1.SomeFunc(a, b, c)

My 0.02€, YMMV.

▲

maleldil 7 months ago | parent | next [-]

I don't get it. Why not use a code editor that shows the inferred type on hover?

▲

spirit-sparrow 7 months ago | parent | prev [-]

That should not be an issue, unless the code is written in notepad. As for interfaces, a better approach is to return struct and accept interface in your functions wherever it is possible.

	▲	linhns 7 months ago \| parent [-]
		Sometimes it's better to to return interfaces, like contract style programming.