Go is a very hard language to work on as a team. It does not push a lot of conventions on you, and when it does, they just seem weird and anachronistic.

Even the original k8s codebase was notoriously horrible in Go, and that was "from the source".

Ironically, HashiCorp has a better Go codebase, and that's where I picked best practices from, not from Google.

The problem with Go is that the Googlers fail to challenge some of the design decisions. The giants of computer science working on it at the company cannot be questioned, and that just leads to a broken feedback process.

As someone said, Go is the new C, skipping decades of new language design concepts.

> The problem with Go is that the Googlers fail to challenge some of the design decisions. The giants of computer science working on it at the company cannot be questioned, and that just leads to a broken feedback process.

Well, they can be questioned but they're not very receptive to it, so most people don't bother. During my time at Alphabet I didn't see much use of Go anyways, other than in glue tooling (including a horrific large-scale incident due to non-obvious behaviour of Go code in such a glue tool).

The original k8s codebase was Java, then rewritten in Go by Java developers. K8s is not a good example of Go, and it has nothing to do with the size of the project.

> As someone said, Go is the new C, skipping decades of new language design concepts.

Well, some are doomed to repeat their errors.

In fact C was even crappy for it's own time.

What are you even talking about? Plenty of languages were around then and C dominated all of them because it let people write great software.

I am sure a few old HNer will tell you, C dominated because of UNIX, and the rest is history.

I am old, and that is not the case (although Unix was one of the reasons).