I found the Go module (aka package) system subtle to understand, but it seems to work well. The subtlety being that what you name when you write "import" is not

I found the Go module (aka package) system subtle to understand, but it seems to work well. The subtlety being that what you name when you write "import" is not a module, but a directory on the filesystem (under a known root). Actual module names that act as the namespace for a module's public identifiers do not have to be the same as (or derived from) the import path; that is just the convention. For example, importing "utils" could conceivably bring in bobsfunkystuff.SomeFunc with there being no such module as utils and hence utils.SomeFunc. It's also my understanding that there are no "submodules" in Go. If you want what's in the import path "foo/bar", importing "foo" is unrelated. In fact, there might not be anything in "foo", making it an invalid import path, despite "foo/bar" being a valid one. And then there's the stuff with being able to directly import code from github, code.google.com, etc, but that dovetails in to the same mechanism after downloading.