Yeah it's hard to write weirdly complicated code in Go. Stick Java or C# in the hands of a team and before you know it you've got typed factory service factories and every abstraction known to man.
That line of thinking promotes workarounds over long-term solutions. If your team has people who are abusing tools (like types, abstractions etc), the solution is to teach them how to not do that. The solution is NOT to remove the tool itself! That is like saying that a drilling machine is easier to misuse so "only the hammer is a tool for teams". Ugh.
Go is awesome because of things it _can_ do (it has the speed of C and enough libraries to write full-blown webservices with it). Please don't encourage the whole marketing agenda of touting its shortcomings as advantages. It doesn't work. All it does is it turns people away from the language.
I was a C# developer writing all these abstractions like every other C# developer does. It's idiomatic C#. OOP exists, you're encouraged to use it to abstract and decouple code.
Even if you try and strip all that away, you'll never escape it because every library you depend on is written this way. For example, try understanding https://github.com/protobuf-net/protobuf-net like I once did. The cognitive load is huge.
This is C#, this is what having a huge toolset results in.
A simple language with simple code isn't a shortcoming. It's an advantage. Overly complex code is a shortcoming.
I liked writing heavily abstracted code in C#, that's what I used to do every day. But I never liked reading other people's code because without the intimate knowledge of the code it is a huge mental load. Onboarding new developers into a code base they are unfamiliar with is also very time consuming.
In Go I realised that the only abstraction you need is an interface. There's no "abstraction first" mentality like there is in C#. You can define interfaces at any point in time, whereas in C# you must define an interface first, and if you don't then you end up going the OOP route with more abstraction.
And because of this small toolset, reading other people's code is easy. It all looks the same.
Not by all, only by a subset of Go developers (until very recently I was one as well, maintained a moderate-size webservice). I specifically said "some Go developers" in my comment because that is what happens (at GopherCons, meetups and so on).
I don't really have a lot of C# experience, but I have read the same story about C++ from lot of people. I think you will agree that abstractions are not a problem, abuse is. Now, I have worked on a C# project for a very short time where I have seen the problems you described. But I do not follow the thinking that a tool was abused and hence its the tool's fault. That is silly.
I was a Go developer for ~4 years where I struggled because I had to constantly spend mental effort trying to ignore the people in the Go community who, instead of focusing on what Go does well, spent all their time (in GopherCon, meetups and so on) rationalizing missing features from Go. Here I was - with this nice language that let me write webservices which are efficient and do not carry a heavy runtime (CLR, JVM etc). But it is severely missing features that can help you be more productive when programming. After all that, listening to people say "its feature, not a defect" just makes you lose all hope that things will get any better.
A better approach is what (thankfully) some folks from the Go team take. You will find blogs from the core team where it is explained that Generics aren't missing because they are outright bad. They are missing because the Go team had not yet[1] figured out how to do it the right way (TM). _That_ is fine, it is the truth.
Finally, you say that it just isn't possible to avoid writing complex code with a powerful language. Well, I have heard that as well, from the same people. But it isn't true, I have worked on a C++ project where I was careful to keep things simple[2] and had quite a few developers on the team (with only college-level C++ experience, most of them Go devs) contribute to the project without much trouble.
But hey, maybe it is personal preference then. I would rather use powerful tooling and put cognitive effort into keeping things simple - rather than using something else and feeling limited by it all the time.
[1] now they have, for the most parts [2] for example, it would use templates but avoid nesting more than one level, and so on. You get the idea.
In Go it's quite difficult to make idiomatic overly complex code. If someone is making something really complex in Go I can easily see what they're trying to do and suggest an easier more idiomatic way of doing it.
In C# trying to understand some overly complex abstraction is a task in itself. Then trying to simplify it in a way that pleases everyone else who is of the mindset that these abstractions are good is another challenge. Most Go developers are of the opinion that there is only 1 or 2 idiomatic ways to solve most problems. But in C# there's so many more because of the more advanced language.
I'm not trying to justify the shortcomings of Go either. From day 1 of learning Go I was craving for generics and I read people saying "you don't need generics, just use interface{} and type switch.". It's ugly and it's one of the worst parts of Go, I absolutely hate seeing interface{} in a function.
But in the context of working in a team I've worked on sizeable projects in Go and bringing new devs of various skill levels onto the project has been a breeze. The code they write is the same as the code I write because it almost has to be, there's not many ways they can stray from the path laid out ahead.
But that's exactly where Go projects end up at. Reading any 1-4 Go lines is easy. Trying to mentally decode a function of 70 lines almost never is. It is verbose as hell. And then you are like "a-ha! this goes through those two collections, filters one of them, maps the other and then combines the results through that algorithm". But you lost 20 minutes until you got to that conclusion.
Compare this with OCaml or Elixir for example where such a function would literally be 10-15 lines.
(It's not an unique disadvantage to Go, mind you, but we're discussing it currently. Other languages have the same problem, e.g. C# and Java.)
Just because Go lacks many forms of abstraction, doesn't mean complex code will not be created with it. Quite the opposite. It's lack of expressiveness will encourage "frameworks", elaborate encodings, code generation and various productivity aids. Look at what the lack of generics has done to the Kubernetes code base:
"The core team replaced a compile-time language feature that was missing (Generics) with their home-built runtime system"
https://medium.com/@arschles/go-experience-report-generics-i...
No. What you see in K8S is the exception rather than the norm in Go - but is the norm in other languages.
I suggest that is because not many large applications have yet been built in Go and it is still relatively young. If Go was used more sparingly as a "domain-specific language for concurrent network services", then I might be inclined to agree with you, but it seems to be marketed and promoted as a general purpose language.