4 ms·

I should add that another big part of the reason I've been avoiding the language for years is the cult of Golang telling me my complaints are "totally naive and

I should add that another big part of the reason I've been avoiding the language for years is the cult of Golang telling me my complaints are "totally naive and irrational".

dasacc22 9y ago
I've been working with Go for 6 years, your complaints are not "totally naive and irrational". I don't mind GOPATH, but I did argue that if vendoring was to be a thing then it needed to be dropped entirely. I was also not a fan of the vendoring mechanism. The approach given here looks much more thought out getting rid of each, first proposal I've actually liked.
Groxx 9y ago
This kind of attitude around package management and especially dependency injection have been major turn-offs for me as well. More than a sufficient number of the community has been emitting a high-pressure stream of NIH combined with ignorance of existing solutions, and it has been crippling the community for years.
- neoasterisk 9y ago
  Dependency injection is very commonly used in the Go ecosystem. Do not confuse resistance about unidiomatic DI frameworks with resistance about DI itself.
  - Groxx 9y ago
    Which ones are common? I've been hoping this would be the case, but I've been unable to find evidence for it. e.g. the most-popular one I can see so far is Facebook's "inject", which has a remarkably small 841 stars: https://github.com/facebookgo/inject https://github.com/facebookgo/inject Even Glide, Godep, and Dep have several thousand. And those can barely claim "most", much less "very common".
    - neoasterisk 9y ago
      What do you mean which ones? I am talking about dependency injection as a technique/pattern. In Go you can just do it without importing anything. Please read: https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1#db5a https://medium.com/@benbjohnson/standard-package-layout-7cdb... (I've linked to the exact point in the article where it talks about DI but you might want to read the rest as well.)
      - Groxx 9y ago
        Yeah, it's widespread as a hand-coded thing. It has to be - you essentially have no choice in Go for even basic things like tests. But that just means that everyone rolls their own thing by hand, with widely-varying feature-sets, method names, bugs, etc. DI frameworks are very much nicer for interop between a bunch of libs.

I should add that another big part of the reason I've been avoiding the language for years is the cult of Golang telling me my complaints are "totally naive and irrational".

dasacc22 9y ago

I've been working with Go for 6 years, your complaints are not "totally naive and irrational". I don't mind GOPATH, but I did argue that if vendoring was to be a thing then it needed to be dropped entirely. I was also not a fan of the vendoring mechanism. The approach given here looks much more thought out getting rid of each, first proposal I've actually liked.

Groxx 9y ago

This kind of attitude around package management and especially dependency injection have been major turn-offs for me as well. More than a sufficient number of the community has been emitting a high-pressure stream of NIH combined with ignorance of existing solutions, and it has been crippling the community for years.

neoasterisk 9y ago
Dependency injection is very commonly used in the Go ecosystem. Do not confuse resistance about unidiomatic DI frameworks with resistance about DI itself.
- Groxx 9y ago
  Which ones are common? I've been hoping this would be the case, but I've been unable to find evidence for it. e.g. the most-popular one I can see so far is Facebook's "inject", which has a remarkably small 841 stars: https://github.com/facebookgo/inject https://github.com/facebookgo/inject Even Glide, Godep, and Dep have several thousand. And those can barely claim "most", much less "very common".
  - neoasterisk 9y ago
    What do you mean which ones? I am talking about dependency injection as a technique/pattern. In Go you can just do it without importing anything. Please read: https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1#db5a https://medium.com/@benbjohnson/standard-package-layout-7cdb... (I've linked to the exact point in the article where it talks about DI but you might want to read the rest as well.)
    - Groxx 9y ago
      Yeah, it's widespread as a hand-coded thing. It has to be - you essentially have no choice in Go for even basic things like tests. But that just means that everyone rolls their own thing by hand, with widely-varying feature-sets, method names, bugs, etc. DI frameworks are very much nicer for interop between a bunch of libs.