I feel this way... very often.

* Init functions

* Top-level variables being shared between all files in a package

* For-loop sharing (fixed in 1.22 [0])

* ldflags (this is more of build behavior, but it took me a while to figure out how some variables were being set [1]. Note: Go does embed some data by default, but an app I was working on introduced more metadata)

* Go build directives prevent IDEs/linters from analyzing a file at all. E.g. if you edit a linux-only file on macOS, you get _zero_ help.

I dunno, there are a lot of other weird, confusing things that Go does. It is less than most other languages, though.

[0] https://go.dev/wiki/LoopvarExperiment

[1] https://www.digitalocean.com/community/tutorials/using-ldfla...

Needing to cast nil to a type was weird. C/C++/Java/Python don't do that.

They also take on the weird Java-ish culture that everything is better if it's written in Go.

They also had this weird take on the C++ vtable, so they eschewed anything class like to keep everything statically linked for speed.

It also took them a long time to figure out their loop variable syntax was broken. So ... hrm.

C++ and Java do make you cast null/nullptr, if you need to resolve an ambiguous overload based on pointer type.

You're misunderstanding what I'm saying. How the language works is relatively simple. Understanding what's going on when problems arise isn't.

* "how is my Cobra command being registered when I'm not calling any code?" -> "oh, there's an init function that registers the command when imported"

* "why is this variable not working?" -> "oh, it's that for loop thing again"

* "why does the result of my unit tests depend on the order of test execution?" -> "oh, we have 150 Cobra commands in one package with variables shared between _all_ of those commands"

* "how is this variable being set?" -> "oh, we have to call go build with a monstrous ldflags argument

* "why is CI not passing for this oneliner when this looked fine locally?" -> "oh, it's a linux-only file so the IDE isn't even showing me simple syntax errors"

I like to read language references (not just Go's, for example I have also fully read the ECMAScript standard as a part of my research in the past) and yet I will never say I can remember everything from those references. "Documented" isn't same as "easy to remember or recall".

I looked around for something like CppQuiz or its Rust analogue, where you're presented puzzling "Why would anybody do that?" fragments and asked what happens -- something that's often extremely difficult. If I had found one of those for Golang I could maybe see whether there are people who just ace the quiz first time.

But what I found were the sort of softball "Is Go Awesome, Brilliant, Cool or all of the above?" type questions, or maybe some easy syntax that you'd see in day 1. So I have no evidence whether in fact many, some or even a few Go programmers have this deep comprehensive understanding.