Being new to Go and coming mostly from Java, for my projects I have been placing source files in multiple sub-packages. For example:
myproject
├── subpkg1
│ ├── ...
│ └── y.go
├── subpkg2
│ ├── ...
│ └── z.go
├── ...
└── x.go
This is problematic, however, as in order for a sub-packages to interface with another sub-package, the latter must export some functions, types, etc., even if those members are considered internal for the overall project. If this project is some sort of library, then internal functionality is exposed to user code as long as the user imports (following the above example) myproject/subpkg1.
Is the above method considered acceptable despite the described drawback? If not, what is the idiomatic way of organizing (large) projects?
Apart from the way I described above, I have seen two other approaches:
Put every thing in one big package. This way is simple, but then you might end up with hundreds to thousands of identifiers (exported and non-exported) in one namespace.
The encoding/binary standard package (and maybe others) employs the interesting technique of using a dummy variable with an irrelevant value to introduce a new namespace (specifically I am referring to the binary.BigEndian and binary.LittleEndian variables). Is this considered a good practice?
Related questions/articles I have already read but do not answer my question: