[bredov]

So that is the point. Go design doesn't allow these complexities, so there will be no confusion when one should use them and when not. This somewhat limiting, of course, but turns out it's not the end of the world, benefits may outweigh the limitations. If you really need those, C++ is always available to you.

edit: missed a word

[camus2]

> Go design doesn't allow these complexities,

Go allows a wide range of complex metaprogramming through reflection, struct tags, ... to say that Go is void of that kind of garbage is lying.

Go also has a bunch of weird rules regarding type conversion and assertion, its type system isn't covariant... Go has its share of problems, so much that go maintainers themselves keep on introducing type unsafe API in their own std lib. Go has a type system problem, period.

Finally all platforms supported by Go aren't first class. Windows doesn't support Go plugins or Go shared libs AFAIK for instance.

[bredov]

It certainly has problems, no sane person would seriously argue that it is literally and objectively perfect. Reflection is complex, unsafe library is a hack, that's exactly what is stated in the official description of both libraries and both recommended to be avoided if possible. No one tries to say opposite.

Yet, code in Go tends to be easy to read, uniform, very well suited to work on in a team. No megabytes size of code style is required, in most cases there would be no problem to understand code written by other person because of how simple the language is.

[danaliv]

> code in Go tends to be easy to read, uniform, very well suited to work on in a team

This was not my experience working on a moderately sized Go codebase. In fact, it was one of the messiest agglomerations I've ever had the displeasure of working with (and I worked at Twitter when it was still a monorail). Everyday code that is simple in most other languages was a drawn-out mess in Go. The type system was an obstacle to be worked around. Metaprogramming (via go generate) was a joke.

That's just my experience. Others' may differ.

[kjksf]

That statement would be more credible if you identified that unholy mess of Go code so that we could form independent opinion.

Or if you showed a few examples of "code that is simple in most other languages was a drawn-out mess in Go" or how Go's "type system was an obstacle to be worked around" when compared to type system of other mainstream languages like C++/Java/C#.

As it stands, you're in a minority. The consensus is that Go codebases are among the most readable.

[vertex-four]

Go codebases are readable in that you can figure out what a given line is doing - but when 3 out of 4 lines of code are duplicated error handling, it's difficult to figure out what the "success case" of even relatively simple functions is.

[camus2]

> As it stands, you're in a minority. The consensus is that Go codebases are among the most readable.

Your statement is as unsubstantiated as his. But at least the parent doesn't feel as arrogant claiming he represents the majority. Go doesn't magically makes code more readable than any other language. It's just something some gophers like to think since they often start projects from scratch.

[eropple]

> The consensus is that Go codebases are among the most readable.

Among who--other gonuts/gonads/gophers? In my neck of the woods a Go application over a few thousand lines is already a yellow flag and a Go application, period, requires defending the choice over TypeScript or Java. (Difference being, of course, I'm not holding up my experiences as objective.)

[kasey_junk]

I find the statements about the type system very credible. I've been programming go full time for nearly 3 years and not a single day goes by that I'm not bitten by it.

As far as whether go makes it easier or harder to make easy to manage code bases I don't know that it matters one way or another. I've written bad code in other languages and go. I will say, I've never seen a large go code base, and I suspect if I did it would suffer very much from things that people complain about with the go language.

[justicezyx]

> This somewhat limiting, of course, but turns out it's not the end of the world, benefits may outweigh the limitations.

The situation is not really benefit vs. limitations. The style guide is put as general guide. It's a proven way of writing code inside google that most people agree and think is acceptable.

It's about taking a common ground on how to use a language, rather than finding a sweet spot of trading-off. Benefit vs limitations is part of the equation, but it's put in a context that only makes sense inside Google.

Therefore it's not self-evident that the benefit vs limitation argument automatically applies to general use cases outside of Google.

Or, I do not like people use Google or any other large organization's approach to automatically prove that those rules makes sense in different settings.