> With non-opinionated languages nothing is stopping you from structuring your code the same way. With Go, I can do `go build $project` from anywhere and get a

> With non-opinionated languages nothing is stopping you from structuring your code the same way. 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.