[treyd]

> It’s not exactly pushing google’s ad agenda.

Maybe not their ad agenda, but certainly one of their agendas. Specifically, the agenda they have to get young, inexperienced developers prepared for specifically the software development practices they employ internally.

It was directly stated that "Go is not for clever developers" and that their target is recent graduates with limited experience. It punishes you for trying to think about what you're building and to design sophisticated software, relying more on brute force. It doesn't encourage you to reach higher.

[hn_throw2025]

I don’t know where you are on your career journey, but having worked with countless clients, business domains, and projects as a freelancer I value readability over everything else.

If you’re working on a greenfield project in a team of one then I suppose it’s great to get in an expressive mood and emit your code poetry from those fingertips.

It’s very different to inherit a quirky puzzle and reverse engineer a mental model from there.

[kennywinker]

> Go is not for clever developers

What “clever” code is required to write a BBS-over-IP? 99.99% of code isn’t clever and shouldn’t be clever.

> It punishes you for trying to think about what you're building and to design sophisticated software, relying more on brute force.

Can you give an example of this? I have not written much go, so i am unable to think of a case where golang encourages brute force over sophistication?

[treyd]

FOSS projects have their constraints on time and usually not talent, like for-profit teams often are, so they should want the code they write to go farther.

They've explicitly stated that they wanted to discourage building abstractions, since "abstractions are hard to learn".

Concretely, this is evident in how channels and goroutines both poorly compose together, in part a result of the unsophisticated type system. It's difficult to build very generic libraries that can be leveraged as force multipliers, like the tokio-tower ecosystem does. You can do it, but it comes at performance costs or involves relying on codegen.

Google's Bazel build systems are designed around reasoning about and checking-in generated code, but the standard go tooling doesn't do this well and git workflows also don't really grapple with it well. This aspect of the design is very clearly an example of internal Google processes leaking out.