5 ms·

If $GOPATH was your biggest complaint, now may be a good time to give it another look. As of 1.11, there's an experimental feature called go modules that lets

If $GOPATH was your biggest complaint, now may be a good time to give it another look. As of 1.11, there's an experimental feature called go modules that lets you avoid using GOPATH. I believe it's going to be non-experimental starting in 1.12.

freedomben 8y ago
That's terrific news! GOPATH and the file system conventions are horrible for me as well. It forces me to break my personal conventions and workflow that I use for every other language. I avoid using go for new projects now because it got to be so annoying and disruptive (a somewhat shallow reason, I know).
- jjtheblunt 8y ago
  That's not a shallow reason: the annoyance in aggregate motivated a language usability improvement with no regressions.
- klodolph 8y ago
  That ended up being the biggest hurdle for me. I wanted a single repository with some Go source code, some Python, some C++, and I didn’t want to have to put the repo in a specific place or set environment variables for every project. Nowadays I just put my Go source code in <repo>/go/src/example.com/pkgname and that works well enough, but it's a bit clumsy and reminds me of bad experiences navigating Java source trees. I haven’t switched to modules yet but I will once I get 1.12 everywhere.
- developer2 8y ago
  Don't get too excited. You don't have to place your projects within $GOPATH anymore, but all your dependencies are still forcefully downloaded to – and imported from – the shared $GOPATH. AFAIK they didn't provide a way to have your dependencies localized to a subdirectory of your project's root. The documentation for "go mod vendor"[1] makes it seem like it should accomplish that task, but I couldn't get it to work for initial pull of dependencies – it only worked after dependencies were already downloaded to $GOPATH, at which point it was willing to make a copy of it within the project. [1] "... or to ensure that all files used for a build are stored together in a single file tree, 'go mod vendor' creates a directory named vendor in the root directory of the main module and stores there all the packages from dependency modules"
geezerjay 8y ago
> there's an experimental feature That's not a feature but a fix for a design problem, and currently the only fix is an experimental one. For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.
- llimllib 8y ago
  Go modules are extremely suitable for current work; they're as un-risky as anything labelled "experimental" could be. I've been using them for a boring professional application for about 4 months now, and there are no hassles with using them.
  - weberc2 8y ago
    Same here. I've been using them in production with no issues.
  - geezerjay 8y ago
    > they're as un-risky as anything labelled "experimental" could be. Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.
    - llimllib 8y ago
      I don't understand what you mean, sorry
      - Cyph0n 8y ago
        Think of it this way: if you spend time learning and using a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?
        throwaway2048 8y ago
        Its not like there is much of a barrier there.

freedomben 8y ago

That's terrific news! GOPATH and the file system conventions are horrible for me as well. It forces me to break my personal conventions and workflow that I use for every other language. I avoid using go for new projects now because it got to be so annoying and disruptive (a somewhat shallow reason, I know).

jjtheblunt 8y ago
That's not a shallow reason: the annoyance in aggregate motivated a language usability improvement with no regressions.
klodolph 8y ago
That ended up being the biggest hurdle for me. I wanted a single repository with some Go source code, some Python, some C++, and I didn’t want to have to put the repo in a specific place or set environment variables for every project. Nowadays I just put my Go source code in <repo>/go/src/example.com/pkgname and that works well enough, but it's a bit clumsy and reminds me of bad experiences navigating Java source trees. I haven’t switched to modules yet but I will once I get 1.12 everywhere.
developer2 8y ago
Don't get too excited. You don't have to place your projects within $GOPATH anymore, but all your dependencies are still forcefully downloaded to – and imported from – the shared $GOPATH. AFAIK they didn't provide a way to have your dependencies localized to a subdirectory of your project's root. The documentation for "go mod vendor"[1] makes it seem like it should accomplish that task, but I couldn't get it to work for initial pull of dependencies – it only worked after dependencies were already downloaded to $GOPATH, at which point it was willing to make a copy of it within the project. [1] "... or to ensure that all files used for a build are stored together in a single file tree, 'go mod vendor' creates a directory named vendor in the root directory of the main module and stores there all the packages from dependency modules"

geezerjay 8y ago

> there's an experimental feature That's not a feature but a fix for a design problem, and currently the only fix is an experimental one. For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.

llimllib 8y ago
Go modules are extremely suitable for current work; they're as un-risky as anything labelled "experimental" could be. I've been using them for a boring professional application for about 4 months now, and there are no hassles with using them.
- weberc2 8y ago
  Same here. I've been using them in production with no issues.
- geezerjay 8y ago
  > they're as un-risky as anything labelled "experimental" could be. Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.
  - llimllib 8y ago
    I don't understand what you mean, sorry
    - Cyph0n 8y ago
      Think of it this way: if you spend time learning and using a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?
      - throwaway2048 8y ago
        Its not like there is much of a barrier there.