I was wondering the same. It's usually a game of "find the actual behaviour" among a sea of interfaces, frameworks and so forth. Go, I can see the argument for.
Golang is quite bad when trying to find an implementation for an interface, because it is quite easy to accidentally implement an interface even if you're not intending to. This also makes it much harder on the IDE to index everything.
I have looked at many production java codebases. I agree that some things can be complex, but that is typically a feature of a framework (java has many configuration heavy frameworks) and not the code aspects. But I haven't seen any production code that is complex simply because it is production java.
I've seen an internal Java-based web application (a digitization of some business processes involving what used to be paper forms) in which nested elements in a web page corresponded with subclasses in Java. Way high up in the hierarchy, it had `HTML`, `CSS`, and `JavaScript` classes, each of which eventually descended from a `Document` class.
It was impossible to properly trace any behavior through. Every method zigged and zagged through the inheritance hierarchy multiple times as you traced deeper. And so:
> It is (no matter how verbose or clunky) still easy to read and understand.
The sentiment is taken well, but it's just not true. Credit your fellow engineers for the positive experience, not any particular language.
But what they're referring to is that none of the code in that is hard to understand... unlike in C/C++. This is like of like the same idea behind Go. You make the language simple and straight forward and even though there may be a LOT of code the code will be be easy to understand.
And I would add that Go is obviously easier than Java here by design, but anyone could write a horribly over-abstracted Hello World or Fizz Buzz in any language given the motivation.
> And I would add that Go is obviously easier than Java here by design
Nothing in golang makes it easier to understand compared to Java by design, and the opposite is actually true (e.g. no proper enums, no records, no pattern matching, etc.) make it more verbose and harder to get to the underlying logic.
That being said, you should see some of my employer's golang code with their web framework that they wrote and the 80+ line stack traces.
