Apologies, but I don't think you can accuse the golang authors of not putting enough thought into the project. Especially the package structure. This is actual

Apologies, but I don't think you can accuse the golang authors of not putting enough thought into the project. Especially the package structure. This is actually one of the major boons of go. They are solving problems you haven't considered. They set out to first solve the dependency problem. Someone commented that for every byte of C++ code being compiled in their large framework, the compiler was processing many kilobytes. This lead to many-hour compile times on large compute clusters. In go, when a package is compiled it only needs to consider the contents of its imports (and not the imports of those imports, if you follow). It's very beneficial to only pull in what you need, since that will be one of the factors which heavily affects your compile time. Lastly, as a personal preference, I really don't like "using namespace"-like directives. Go has a really nice property that for any given symbol you can find where it was defined by looking in the current file. This makes it great when working on unfamiliar projects or for people learning go.