As a result of reading this, I wound up thinking about my different feelings about packaging in Go and Python. In the process I realized that it came down to a relatively fundamental difference in what packaging needs in compiled languages versus interpreted languages.

Let me put it this way:

In compiled languages you only need outside packages at build time.

The great problem of packaging in interpreted languages is that your program needs whatever packages it depends on to be around and findable at runtime. This drastically complicates packaging and system design, because you and/or the person you're sending your program to may have no system permissions or not want to install the package system-wide, then on shared machines the program may get run by someone other than the person who set it up. Even if you do have system permissions, there may be multiple package management systems in action.

Or in short, a program in an interpreted language that uses packages is almost certainly not a self-contained entity. This is certainly true of Python, which has created a moderate disincentive to using packages (and in fact all modularity) in my Python programs.

This is not a problem in Go. Go only needs the packages at build time and it's perfectly happy to have you pile them up along side the rest of the source code. After everything is compiled and bound together into a binary you wind up with a single object that you can easily pass around. This is just the same in pretty much any compiled language, of course. In a compiled language you have to go out of your way to not allow 'outside' code packages to be part of the source tree (or general build environment) or to remain as external dependencies after the program has been compiled. Really, this is pretty fundamental to what compiling code and linking a binary does.

(You can create external dependencies with compiled languages; that's what shared libraries are. But generally static libraries and static linking is easier.)

The practical upshot is that Python packaging gives me heartburn, especially as a sysadmin, and Go packaging leaves me indifferent (and may leave me enthused if I ever actually manage to write a Go program).

PS: yes, packages in compiled languages can throw this advantage away. There are any number of libraries and so on for C (and C++) that really insist on being installed as system-wide shared libraries and then being used that way in the build process for programs. There are even a few that can't be built as usable static libraries even if you try hard.