| >But the "magic" in this case is that properties can be methods. Once you know that how is it any different than methods? It's different because you have to apply that general knowledge in every single case when reading code that you are not familiar with. In Go or Java, the information on whether a.x is a constant time variable access or a function call of arbitrary complexity is available at the call site. You don't have to look it up. It's one less thing to do when reading code. And when you do have to look up what an expression means, how straightforward is it? Consider this expression: f(x)
In Go f(x) means whatever the function f does, and f is exactly one function in the current package.f(x) in C++ (and to a slightly lesser degree in Java, C# or Swift) is one of a set of functions called f. Knowing which one actually gets called requires knowledge of tens of pages of name lookup rules plus knowledge of possibly large swaths of the codebase. It is often claimed that languages more powerful than Go just have a steeper learning curve. But it's not true. Even if you know all the name lookup rules of your favorite language (do you?), you still have to apply them every single time you read unfamiliar code. In my view it's pretty simple. If you have to read a lot of unfamiliar code all the time then Go is great. If you can know both a more powerful language and your codebase inside out, then Go will be frustrating for its lack of abstraction features. |