With non-opinionated languages nothing is stopping you from structuring your code the same way.
Some people stated how hard go makes it when you try to have project that utilizes different languages. Another issue is when you try to use a fork of one of library.
Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies.
With Go, I can do `go build $project` from anywhere and get a releasable binary in the working directory. I can do `import "$oldproject/$package"` in my new project and start using it immediately. I can use `godef` to jump around all of the Go code installed on my system and quickly drill down all the way to the Go builtins if I need to. I can use `guru` to see all references to a definition across all of the Go packages installed on my system. The list goes on. And I can do all of that from a favorite text editor (and not a huge slow IDE). I never felt so liberated in any other programming environment, and I've used quite a few.
> Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies.
Go binaries have only the standard system libraries for dependencies - for all practical purposes they can be considered static. Or you mean something else?
> Some people stated how hard go makes it when you try to have project that utilizes different languages.
I've used links successfully, but maybe my scenarios were not complex enough?
> Another issue is when you try to use a fork of one of library.
Vendor support since 1.6 made this a nonissue; it's now trivial to use forked versions of libraries.
A fork of a library is either identical to the original, or a new library. And you could argue (or rather: I do), that it is a good thing that you need to explicitly specify which one you intend to use.
As I said, being opinionated is great if the opinion matches yours otherwise you might end up fighting it on every step.