3 ms·

And hopefully try will have the same outcome, i.e. something significantly better than existed in the ecosystem before. Basically I agree that the process for

And hopefully try will have the same outcome, i.e. something significantly better than existed in the ecosystem before. Basically I agree that the process for modules may not have been ideal, but the outcome was pretty good. We could do a lot worse than getting the same again.

losingthefight 7y ago
I mean, everyone is entitled to their own opinion, but I actually liked dep and never had a problem with it. With Go modules, it has been a massive problem converting our microservices over to Go modules, especially because some dependencies like Resty caused a lot of headaches and I lost several man weeks going through the process. Dep worked and modules doesn't seem to have brought us any real benefit, but again, my use case is my own and perhaps for you module was a better experience.
- CamouflagedKiwi 7y ago
  Indeed, I had exactly the reverse experience; dep never worked well, it was always moaning about obtuse errors ("project is not part of any GOPATH" etc) and was pretty slow even when it did, whereas go mod just worked almost flawlessly. I guess our mileages vary :)
- atombender 7y ago
  Go modules have some (minor, in my opinion) issues, but Dep was a total nightmare. Dep was made by one of the authors of Glide, which coincidentally suffered from many of the exact same bugs, maybe because it reused some of the same code. Our entire team constantly had "dep ensure" failing in unpredictable ways (locally or on the CI server), usually caused by the solver not understanding something. These failures were completely incomprehensible and not fixable by the user. Dep's solver was also very slow. From what I could tell, it was a combination of shoddy engineering and trying to do too much; if I remember correctly, Dep and Glide both tried to automatically detect and convert dependencies that used competing tools like Godep, which didn't work very well. For a long time, Dep didn't work at all with the Kubernetes client library, for example. We've had almost zero problems with Go modules. I've encountered some minor bugs, but unlike Dep, nothing worth tearing my hair out. The drama around Dep vs. Russ Cox shouldn't have happened, of course.
  - no_wizard 7y ago
    Any good documentation on using go modules day to day? I have found the package management story around go so confusing its really stopped me from trying to use the language. For context, I'm used to how composer/npm install the modules into a folder locally. I just can't seem to figure the go way of doing modules where I don't get completely confused.
    - atombender 7y ago
      The official wiki is good: https://github.com/golang/go/wiki/Modules https://github.com/golang/go/wiki/Modules This article looks like a good intro: https://roberto.selbach.ca/intro-to-go-modules/ https://roberto.selbach.ca/intro-to-go-modules/ The equivalent of "npm install" is "go get" (optionally "-u"). You can also edit go.mod manually. Like NPM, this must be done within an application's root. A point of confusion might be the difference between a module and a package. A package is just a folder that declares "package foo" at the top in all its Go files. A module is the closest analogue to an NPM package. Similar to NPM, a single Git repo can contain many nested modules. Unlike NPM, modules can be imported with Git -- no need to publish to a special registry. When a Go file imports a package, the referenced package might live in a module outside your own. It knows it's outside your module because go.mod defines the full root path (e.g. github.com/foo/bar/baz) of your module. You might experience some confusion when you look at how the new module system interacts with the old GOPATH way. Go current supports both modes.
- ploxiln 7y ago
  Why did you go through it? You didn't have to, you could have waited a couple of years. dep still works. A custom script to populate a GOPATH with specific versions or forks of all needed modules still works.
politician 7y ago
Yes, in fact, I like Go modules. But that's not the point, the point is that the community had precisely zero say in how that feature works. Likewise, the community doesn't have any say in how try works, and that ticket asking for feedback is window dressing. You can tell that this is window dressing by looking at the timestamps on when that ticket was opened, comparing it to when this blog post was released, and then considering how the hundreds of comments on that ticket were completely ignored.
- camdenlock 7y ago
  Why must “the community” necessarily have any say at all in how this new feature is designed?
  - marcus_holmes 7y ago
    simply, because "the community" are a set of people who have spent (collectively) millions of hours using the language in a massive variety of use cases and environments. it's not democracy, but they'd be stupid to just ignore all that expertise.
- marcus_holmes 7y ago
  I feel like there's also some "not invented here" syndrome going on. Dep was pretty good, and there was absolutely the possibility of just making that official (and maybe tidying away a few of the points raised during the module discussion). But no, that wasn't good enough. Dave Cheney's errors package (pkg/errors) is a great contribution to Go error handling, used by a lot of gophers. Adopting that would have been simple, backward-compatible, and given us better error handling. But no, that wasn't good enough. I'm so used to "if err != nil" that it's punctuation for me. Having some code use "try" because it doesn't need to be wrapped, and other code use "if err != nil" is going to break that. I'll have to actually read the error handler now, in case it does something unexpected. Or not use "try" and stick with errors.Wrap. That seems way more sensible to me.
- ngrilly 7y ago
  I disagree. I think Go modules are the result of listening to the community. GOPATH, for example, would still be there if the Go team would not have listened to the community.
tacticus 7y ago
modules as a way to download stuff, and to remove the dependency on go path. Sure Semantic import version and the rush of shit to the head in their attempts to break vendoring on the other hand.

losingthefight 7y ago

I mean, everyone is entitled to their own opinion, but I actually liked dep and never had a problem with it. With Go modules, it has been a massive problem converting our microservices over to Go modules, especially because some dependencies like Resty caused a lot of headaches and I lost several man weeks going through the process. Dep worked and modules doesn't seem to have brought us any real benefit, but again, my use case is my own and perhaps for you module was a better experience.

CamouflagedKiwi 7y ago
Indeed, I had exactly the reverse experience; dep never worked well, it was always moaning about obtuse errors ("project is not part of any GOPATH" etc) and was pretty slow even when it did, whereas go mod just worked almost flawlessly. I guess our mileages vary :)
atombender 7y ago
Go modules have some (minor, in my opinion) issues, but Dep was a total nightmare. Dep was made by one of the authors of Glide, which coincidentally suffered from many of the exact same bugs, maybe because it reused some of the same code. Our entire team constantly had "dep ensure" failing in unpredictable ways (locally or on the CI server), usually caused by the solver not understanding something. These failures were completely incomprehensible and not fixable by the user. Dep's solver was also very slow. From what I could tell, it was a combination of shoddy engineering and trying to do too much; if I remember correctly, Dep and Glide both tried to automatically detect and convert dependencies that used competing tools like Godep, which didn't work very well. For a long time, Dep didn't work at all with the Kubernetes client library, for example. We've had almost zero problems with Go modules. I've encountered some minor bugs, but unlike Dep, nothing worth tearing my hair out. The drama around Dep vs. Russ Cox shouldn't have happened, of course.
- no_wizard 7y ago
  Any good documentation on using go modules day to day? I have found the package management story around go so confusing its really stopped me from trying to use the language. For context, I'm used to how composer/npm install the modules into a folder locally. I just can't seem to figure the go way of doing modules where I don't get completely confused.
  - atombender 7y ago
    The official wiki is good: https://github.com/golang/go/wiki/Modules https://github.com/golang/go/wiki/Modules This article looks like a good intro: https://roberto.selbach.ca/intro-to-go-modules/ https://roberto.selbach.ca/intro-to-go-modules/ The equivalent of "npm install" is "go get" (optionally "-u"). You can also edit go.mod manually. Like NPM, this must be done within an application's root. A point of confusion might be the difference between a module and a package. A package is just a folder that declares "package foo" at the top in all its Go files. A module is the closest analogue to an NPM package. Similar to NPM, a single Git repo can contain many nested modules. Unlike NPM, modules can be imported with Git -- no need to publish to a special registry. When a Go file imports a package, the referenced package might live in a module outside your own. It knows it's outside your module because go.mod defines the full root path (e.g. github.com/foo/bar/baz) of your module. You might experience some confusion when you look at how the new module system interacts with the old GOPATH way. Go current supports both modes.
ploxiln 7y ago
Why did you go through it? You didn't have to, you could have waited a couple of years. dep still works. A custom script to populate a GOPATH with specific versions or forks of all needed modules still works.

politician 7y ago

Yes, in fact, I like Go modules. But that's not the point, the point is that the community had precisely zero say in how that feature works. Likewise, the community doesn't have any say in how try works, and that ticket asking for feedback is window dressing. You can tell that this is window dressing by looking at the timestamps on when that ticket was opened, comparing it to when this blog post was released, and then considering how the hundreds of comments on that ticket were completely ignored.

camdenlock 7y ago
Why must “the community” necessarily have any say at all in how this new feature is designed?
- marcus_holmes 7y ago
  simply, because "the community" are a set of people who have spent (collectively) millions of hours using the language in a massive variety of use cases and environments. it's not democracy, but they'd be stupid to just ignore all that expertise.
marcus_holmes 7y ago
I feel like there's also some "not invented here" syndrome going on. Dep was pretty good, and there was absolutely the possibility of just making that official (and maybe tidying away a few of the points raised during the module discussion). But no, that wasn't good enough. Dave Cheney's errors package (pkg/errors) is a great contribution to Go error handling, used by a lot of gophers. Adopting that would have been simple, backward-compatible, and given us better error handling. But no, that wasn't good enough. I'm so used to "if err != nil" that it's punctuation for me. Having some code use "try" because it doesn't need to be wrapped, and other code use "if err != nil" is going to break that. I'll have to actually read the error handler now, in case it does something unexpected. Or not use "try" and stick with errors.Wrap. That seems way more sensible to me.
ngrilly 7y ago
I disagree. I think Go modules are the result of listening to the community. GOPATH, for example, would still be there if the Go team would not have listened to the community.

tacticus 7y ago

modules as a way to download stuff, and to remove the dependency on go path. Sure Semantic import version and the rush of shit to the head in their attempts to break vendoring on the other hand.