I do think it's kind of odd that it decides to put packages in GOPATH, but disallows you from coexisting go mod projects in GOPATH. I organize all my code for all my languages using the go repo as dir. I've had to maintain a separate tree for go mod which is not ideal.

After using Go dep and mod, I felt that dep was the super straightforward and obvious way to do it. It's how I would have done it. Go mod is much more Goish, it's opinionated and based on a philosophy that fits with the language. It Gives me hope that if they do add generics they will make them uniquely Go as well.

I used to be annoyed that I had to put every go project into a dir 7-8 layers below that e.g ~/work/go/src/github.com/joshklein/project/cmd/hello_world.go, but now I can have ~/work/go_hello/src/main.go. Right?

I understand this isn’t the main point, but frankly it’s the thing I care the most about.

For a commercial entity shipping software which may include upstream components, it's important to have options for maintaining (and versioning) in-house forks of upstream components. This becomes a problem when you fork v1.2.3 from upstream and want to internally release your fixes, but now your internal 1.2.4 and upstream's 1.2.4 both have the same number but diverge in content.

I like the Debian solution to this, which permits freeform textual suffixes, so that in the hypothetical scenario above, you can release v1.2.3bigco1, v1.2.3bigco2, with the final number indicating the version of the patchset being applied onto the upstream release; then it's also clear what to do when you rebase your fork because you've maintained the integrity of the upstream version.

Looks up where? GOPATH? The tree below the current file? The current directory? What's the "current module", anyway? Where is that stored?

"go: downloading rsc.io/sampler v1.3.0"

Downloading from where? Github? From what repository? The page for "go get" now talks about "module-aware" mode, but doesn't make it clear how that works.

This is the usual headache with dependency systems. There's some specific directory layout required, and you have to know what it is. This article needs to be more explicit about that. Otherwise you end up depending on lore and monkey copying.

  replace pkg => ../../pkg

> go mod init creates a new module, initializing the go.mod file that describes it.

> go build, go test, and other package-building commands add new dependencies to go.mod as needed.

> go list -m all prints the current module’s dependencies.

> go get changes the required version of a dependency (or adds a new dependency).

> go mod tidy removes unused dependencies.

And you can use some sugar to declare exact versions you want.

I was coincidentally converting my Go project to use Go modules yesterday. I depended on a Google API which was originally retrieved via 'Go get', corresponded to docs and worked fine as this pulled from HEAD. `go mod` did not work out of the box, as it required the latest semantic version (v.0.2.0) of my this Google API import. This version, however, is behind documentation and broke my code.

I understand I can require a specific commit in the go.mod file, but the strings for specific commit seem cryptic. Where can I look up the version hash that matches the doc site?

I haven't felt the need for them.

At what point do they become necessary? Which pain-points should I be on the lookout for?

Realize this is a tooling issue and not necessarily a language one, but do feel like they should be mentioning this. It makes working with modules pretty painful. (we are doing it but man do I miss simple refactors / usages etc..)

This thing apparently doesn't solve my problem. `go mod tidy` simply removes a dependency from a module, but that dependency is still cached in a big arcane directory at $GOPATH/src/mod. Why?

I think we all should be using something like Nix for dependency management that solves all problems, but that is so hard to setup!

- There's a duplicated section starting with: "Note that our module now depends on both rsc.io/quote and rsc.io/quote/v3:"

- In the example of upgrading a major version, Hello was renamed to HelloV3, but the caller isn't renamed. It should be "quoteV3.HelloV3".

other than that it works like a charm, here's a tutorial i wrote: https://getstream.io/blog/go-1-11-rocket-tutorial/

I am baffled to why Go has not figured this out and are presenting recent developments as some kind of breakthroughs - they are not.

To me, and I'm not trying to be disrespectful here, because of the shortcomings it has, Go is in the experimental/keep an eye on bucket. It does some things really, really well but it's far from the panacea most developers that use it think it is.

yes

But yes, with modules you don't need to do this anymore.

go mod init github.com/joshklien/my-go-project

That said, mod allows you to put your project anywhere but in the GOPATH, so the answer to your question is yes. The path is virtualized in the mod file.

Go also allows freeform textual suffixes, it just needs a `+` in there: v1.2.3+bigco1, v1.2.3+bigco2.

The nice thing about not doing what debian does is that there is consistency. Freeform usually means diverging opinions, which is not the Go way.

https://github.com/golang/go/wiki/Modules#when-should-i-use-...

But if you have an internal version that's used in lots of modules, it's probably better to use an import path under your own organization, to avoid confusion.

Given that the import paths are URL-ish, I personally find it fairly obvious where things are coming from - far more so than any other language/dependency manager I've worked with. That's something unchanged with go modules vs GOPATH.

No you don't. If it supposedly works, why would you care where these modules end up in when they are downloaded? There's currently no indication that you need to be aware at all of whatever directory layout the module system needs, as it takes care of it automatically.

Finally, the article does actually mention where the modules are downloaded:

> ... the downloaded modules are cached locally (in $GOPATH/pkg/mod)

The article uses "current module" like you might use "current git repository"; it's the module containing the directory that you are currently `cd`ed to. Just as git identifies the repo by looking for `.git` in successive parent directories, go identifies the module by looking for `go.mod` in successive parent directories.

> > "go: downloading rsc.io/sampler v1.3.0"

> Downloading from where? Github? From what repository?

From the same place that non-module-aware `go get` downloads it. The only difference on the "remote side" of that from old `go get` is that it grabs the `v1.3.0` git tag, instead of git HEAD; if you don't specify a version it grabs the most recent `vSEMVER` git tag instead of git HEAD.

> > "the go command automatically looks up the module containing that package"

> Looks up where? GOPATH? The tree below the current file? The current directory?

Looks it up on the network, à la `go get`. Exceptions:

- The `replace` directive in your `go.mod` can manually override where it looks up a specific package.

- Telling Go `-mod=vendor` will have it look up all depended-upon modules in `vendor/`, rather than via the normal mechanisms; you can create the `vendor/` directory with `go mod vendor`.

It doesn't use the network every time; a module cache lives in `${GOPATH:-${HOME}/go}/pkg/mod/`; but you don't need to know that any more than you need to know that a build cache lives in `${GOCACHE:-${HOME}/.cache/go-build}`.

> There's some specific directory layout required, and you have to know what it is.

Not really, the only requirement is that you have a `go.mod` file that identifies a package name for the directory that it's in. So that if I have github.com/lukeshu/foo, it just needs a `go.mod` saying

    module github.com/lukeshu/foo

> This article needs to be more explicit about that.

Does it, though? It's a blog-post, not the "normal" documentation. The full docs are much more explicit and nitty-gritty than a high-level blog post.

[0] https://github.com/Microsoft/vscode-go/wiki/Go-modules-suppo...

[1] https://github.com/golang/go/issues/24661

If you're using vim-go, HEAD has now gopls support. I believe vscode also added recently support for gopls.

Other than, I agree that it broke all other tools, but most of them are migrated to use the go/packages package so it'll be better going forward.

This issue is tracking compatibility of common tools https://github.com/golang/go/issues/24661

If you have a disk space problem, Nix would seem to be the opposite of the solution to that. One of the ways Nix does its magic is to chew through disk space a lot more freely than most distros do.

And sadly, to use. Nix is a great idea but it could do a lot to help itself out if it ever wants to become more than niche:

1. Use a more approachable package definition language; Starlark (https://github.com/google/starlark-go) or Lua would probably be great choices.

2. Make it reasonable to figure out what the "type" of a package dependency is so we can figure out how to use it and/or find its source code

3. Document package definitions. We document source code in typed languages; Nix expression language is untyped and generally less readable--why not document it?

4. Nix tools have a `--help` flag that only ever errors with "cannot find manpage". This is just user-hostile.

5. Using almost-JSON for the derivation syntax, but then providing a "pretty printer" that keeps everything on one line but with a few more space characters.

6. Horrible build output--everything for every build step (megabytes of useless gcc warnings) gets dumped to the screen. Contrast that with Bazel and company which only print errors.

Plus a long tail of other things I'm forgetting.

> Go me, and I'm not trying to be disrespectful here, because of the shortcomings it has, Go is in the experimental/keep an eye on bucket. It does some things really, really well but it's far from the panacea most developers that use it think it is.

Go is definitely a production-ready language, and indeed it powers much of the most important software that has been written since it went 1.0 (particularly in the Cloud and DevOps spaces). It's not perfect, but it's really, really good and improving steadily.

But go mod is great, and it is very different than cargo, pip, npm, etc. I don't think they are claiming it's a spiritual revolution, but it solves the problems people who needed traditional package versioning where having in an elegant and Goish way.

Go is also far from experimental. It has areas where it could be better, but it's a panacea compared to writing Java in an IDE with Maven for a living.