4 ms·

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 com

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.

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.