To some, explicitly placing keywords like "public", "private", "protected" all throughout your code is ugly. Go gives an explicitly defined coding style; all Go will look roughly similar, and it will never be ambiguous if an identifier is exported or not.
> To some, explicitly placing keywords like "public", "private", "protected" all throughout your code is ugly.
I dunno; maybe it's "ugly," but it's also explicit, and easy to see. Assigning meaning solely to subtle presentational differences can make code hard to read, and increase the likelihood of mistakes (as well as confusing beginners).
[It's a similar problem to Python's significant whitespace.]
Unfortunately it's all this sort of "cute idea" that makes Go seem rather half-baked. It's like they designed the language in a brainstorming session in a bar, mixing ideas from a bunch of people without strong editorial control, and then just released the result without actually understanding the repercussions of many of their decisions. [I'm not saying they're all bad, it just feels like there was a lot more brainstorming than vetting...]
Unfortunately it's all this sort of "cute idea" that makes Go seem rather half-baked. It's like they designed the language in a brainstorming session in a bar, mixing ideas from a bunch of people without strong editorial control, and then just released the result without actually understanding the repercussions of many of their decisions.
This is as far from the truth as I can imagine.
Yes, "subtle presentational differences" can make code hard to read, but in this case it doesn't. When I reference another package I know that all exported variables begin with a capital letter. When I'm writing a package I know whether I'm calling a function that's "private" or "public" without having to look it up.
It's one of some of the Go Authors' favourite ideas in use in Go, and I wish people would stop armchairing about the effect some language feature has without trying it.
The likelihood of mistakes is not really increased, because they will be caught at compile time, or you'll end up with an exported function you didn't realise you wanted.
A confused beginner should be able to understand this concept within seconds. And it's prominently mentioned in the Go tutorials.
> I dunno; maybe it's "ugly," but it's also explicit, and easy to see. Assigning meaning solely to subtle presentational differences can make code hard to read, and increase the likelihood of mistakes (as well as confusing beginners).
I typically disagree when people say, "Well you haven't tried Go yet, so maybe you should," but this is one of the few cases where I agree. The exported/unexported syntax is weird to look at, but once you start using it, you quickly realize it to be amazing.
One of the key things about using a capital letter to indicate export/unexport is that you know if a function or a method is exported at the call site. That is, the export information isn't just in the function declaration, but in the name itself.
And trust me, it is not hard to read. It's not that hard to imagine that your eyes are quickly trained to see the export information.
> [It's a similar problem to Python's significant whitespace.]
No, that's not a problem for anyone who knows how to not mix tabs and spaces.
> and then just released the result without actually understanding the repercussions of many of their decisions
What's ironic is that you're criticizing a feature that they kept because of how it worked in the real world.
