> Capitalization also restricts visiblity to two levels (package and completely public). I frequently want file-private identifiers for functions and constants,

> Capitalization also restricts visiblity to two levels (package and completely public). I frequently want file-private identifiers for functions and constants, but there isn’t even a nice way for Go to introduce such a thing now. To me this is more of an issue with not understanding some of the conventions the language pushes you towards. An example of this common stylistic mistake is when some repos will have a `lib` package with a large number of utility functions spread across different files. It runs into the author's issue of function and constant collisions. The solution is to group together utility functions into many small packages, which has the added benefit of changing the code at the call site from something like this: lib.NewUUID() To something terse like this: uuid.New() I've found that Go has lots of these sorts of nudges — dependency cycles generating a compiler error, for example — where the language enforces good style and organization. However, if the Go compiler is going to enforce these rules, maybe it could be more helpful by suggesting the design tweaks that would help to avoid them, rather than forcing developers new to Golang to go through a kind of trial and error process.