4 ms·

kind of hard for someone to prove a negative - feel free to find some Go code that meets that definition.

shepherdjerred 2y ago
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 https://go.dev/wiki/LoopvarExperiment [1] https://www.digitalocean.com/community/tutorials/using-ldflags-to-set-version-information-for-go-applications https://www.digitalocean.com/community/tutorials/using-ldfla...
- bb88 2y ago
  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.
  - commodoreboxer 2y ago
    C++ and Java do make you cast null/nullptr, if you need to resolve an ambiguous overload based on pointer type.
- funny_falcon 2y ago
  First three are clearly documented in language reference, which could be read in several hours (at least before generics were introduced).
  - lifthrasiir 2y ago
    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".
  - shepherdjerred 2y ago
    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"
tialaramex 2y ago
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.

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 https://go.dev/wiki/LoopvarExperiment [1] https://www.digitalocean.com/community/tutorials/using-ldflags-to-set-version-information-for-go-applications https://www.digitalocean.com/community/tutorials/using-ldfla...

bb88 2y ago
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.
- commodoreboxer 2y ago
  C++ and Java do make you cast null/nullptr, if you need to resolve an ambiguous overload based on pointer type.
funny_falcon 2y ago
First three are clearly documented in language reference, which could be read in several hours (at least before generics were introduced).
- lifthrasiir 2y ago
  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".
- shepherdjerred 2y ago
  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"

tialaramex 2y ago

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.