[ilovecaching]

I've been using Go modules, and I really like them. It's obvious they really paid a lot of attention to backwards compatibility. Being able to vendor using mod is really awesome, as well as see all your transitive dependancies automatically. It's very goish to focus on minimizing your dependancies and actually think about what you're pulling in. I'm not yet sure how I feel about the v2+ stuff. Having a separate module for breaking changes is something I think I'll have to try more to form an opinion on, but I dislike the idea of embedding the version in the name instead of using the mod file.

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.

[jrockway]

It does not put modules in GOPATH, at least not where you'd normally find them. Pre-modules github.com/foo/bar would be in $GOPATH/src/github.com/foo/bar. Now they are in $GOPATH/pkg/mod/... (... being based on the URL with some handling for versions and characters that don't work well in filesystems, I don't know the exact details).

The main problems I've had with go modules are fast-and-loose upstreams that happily rewrite history. go mod detects this and stops the world, and you have to manually edit go.sum.

I also feel like "go get github.com/foo/bar" doesn't always get me the latest version. You see that there was a commit 1 hour ago, but then "go get" adds a version like 20181130-93874837 to your dependencies. I assume they know what they're doing? But I'm probably wrong.

[SamWhited]

> The main problems I've had with go modules are fast-and-loose upstreams that happily rewrite history. go mod detects this and stops the world, and you have to manually edit go.sum.

This is really irritating. I have the same problem with TLS: every time a malicious actor tries to manipulate my connection and steal my cookies I get an error page and can't do online banking anymore!

Sarcasm aside: this is not a problem with Go modules. This is a problem with the libraries you're using and you should avoid those projects until they get their act together.

[kasey_junk]

Internal libraries are a huge pain to build now. I don’t need the rigor of semantic versioning for this, it just gets in the way. My act is together, I have tests that confirm my libraries work, I have a idempotent versioning system that is automatic (git sha) and if something gets merged to master that is my stamp of approval that it works.

Between the versioning behavior and trying to figure out how to document transitive dependencies correctly go mod has made my life as a maintainer harder.

[knownunown]

It sounds like the replace syntax might help here. It allows you to forgo semver+version control and depend on modules on your local disk. https://github.com/golang/go/wiki/Modules#can-i-work-entirel...

[dragonwriter]

From the point of view of someone considering what to use, it's often of fairly minimal significance if a problem comes from the language ecosystem or from the language technology.

[sagichmal]

These two things are not comparable.

[Thaxll]

This prevent things like Nodejs package hijacking. I think it's a pretty big deal tbh.

[dastx]

> The main problems I've had with go modules are fast-and-loose upstreams that happily rewrite history. go mod detects this and stops the world, and you have to manually edit go.sum.

This exists in other package management systems. At least, it did when I used composer and came across the same issue some 3/4 years back. I think it's one of those issues that are quite rare and in well maintained packages are even less likely.

[wvh]

Go gets the latest tag (if there are tags in the repo). You can force `go get` to check out a commit by branch or concrete hash with respectively @branchname or @commithash123. That's sometimes necessary when maintainers are lazy taggers.

[ilovecaching]

That's what I meant, pkg is definitely in GOPATH. It's annoying because I can't put my code in src anymore, which is where I've been organizing it for years, but I still have to keep GOPATH around for bin and pkg.

[fhs]

What the blog post neglected to mention is that you can force module usage, even inside $GOPATH, by setting the environment variable GO111MODULE=on. I have a go command wrapper script called vgo that sets GO111MODULE=on, which I use when I want to use modules inside $GOPATH. More info here: https://github.com/golang/go/wiki/Modules

[grogenaut]

You don't really need bin anymore, run go install or go build with a output target. I'm doing platform independent stuff anyway so I have a json file in my projects that describes what execs I want to release and where they are in go and what the filename will be when done. I then create shim scripts for all platforms (in my multi-platform distro), or could easily just make 3 different "distributions". Yes I know this isn't using the tools idiomatically or whatever but I've found it more useful since I work with people who are on multiple platforms.

[jrockway]

Fair enough. I clarified because the days of editing code in some dependency of yours are over; it's not easily exposed for that purpose (but you can do it ;).

[shabbyrobe]

Which is, of course, totally unacceptable. This is a critical use case for doing deep-dive debugging or for code exploration. Fortunately for us there is the wonderfully named "gohack", which does easily expose your deps for editing (though not as easily as before): https://github.com/rogpeppe/gohack

[wiiittttt]

I think "go get" will only grab the latest tag. If that commit an hour doens't have a new tag, it won't see anything to update.

[krferriter]

I use go modules to avoid having to work out of $GOPATH (~/go). When I work on projects or components I have them all separate in different directories in different locations on the filesystem. Next they should put pulled git dependencies under ~/cache/go or something, not in a top level $HOME directory.