6 ms·

Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior art

Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior art went with a particular approach. I swear I should put together a list of these instances.

jjuel 9y ago
Do you have proof that the Go team has not looked at any other dependency management approaches or considered ones from other languages?
- stouset 9y ago
  Obviously I don’t, but the available evidence — to me, anyway — points to this being a cultural reality in the golang ecosystem. I left the language years ago, but the steady stream of articles of the form “Why go doesn’t need $x” followed by innumerable comments, articles, and blog posts by people struggling with the lack of $x, followed by the go core team (due to the completely foreseeable consequences of not having $x) begrudgingly adopting $y, which is supposed to (but doesn’t actually) obviate the need for $x… I’ve reached my own conclusions, and I’m finding more and more people who are leaving the ecosystem with those same conclusions. I believe that Go excellently solves problems that Google has. I don’t believe it solves many problems that most other users have, even though it might seem like it at the outset.
  - pjmlp 9y ago
    Wait until they finally cave in to generics being one of the top requests on Go surveys and bring something to Go following that same design process.
mseepgood 9y ago
> Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior art went with a particular approach. Actually it's pretty clear that they did their homework.
- stouset 9y ago
  If you count as “their homework” the dozens of iterations of this we’ve been through. First, it was literally argued that just `go get` just grabbing `master` of all of your dependencies was good enough, because if you ever need to release something backwards-incompatible, you should create a new repo. I wish I were making this up. Then we just vendored everything and never updated our dependencies, and that too was good enough. Then GoPM, go dep, and a deluge of other tools that I don’t care to track down or sort into their appropriate order. And now this, which decides to buck the trends that everyone else follows yet again and attempts to satisfy dependency trees by choosing the minimal compatible versions instead of the maximal ones, with the completely foreseeable consequences that: * security patches won’t be applied * issue trackers will be filled with bug reports that are closed with messages saying “this was fixed months ago, update”, and * updating dependencies will become *harder*, since this is a straightforward result of doing it less frequently
  - mjevans 9y ago
    If you can't go get -u all on your project at least you have done something 'wrong' or your upstreams have done something wrong. First, the upstream behavior; not supporting the published interface (as it was and should therefore work forever) means they need to deprecate that interface and release another with the incompatible changes. However the PROPER way of handling this is to add new versions of exposed public methods and interfaces / constants with new names and only if such a major change is required that you can't support the old interfaces, at THAT point, release at least under a new inclusion path if not new dependency name. Things local a developer might have done wrong: A) include an 'immature' upstream repository that behaves like above. B) use non-public components or other unsafe practices to go beyond the interface contract that was exposed.
    - TheDong 9y ago
      I guess using any dependency, directly or transitively, that declares itself pre-1.0 in the go or semver meaning of the word, is thus right out. At that point, almost all of the go ecosystem can't be used.
weberc2 9y ago
> Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior art went with a particular approach. The popular criticism is that Go isn't reinventing enough; that it's stuck in the 70's and it's not sufficiently innovative.
- stouset 9y ago
  I think it's two sides of the same coin. I've heard go described as a language that doesn't try to solve any hard problems. Let's set aside for a moment whether or not that's a positive or a negative. The bigger problem is that they also seem to completely ignore everyone else's existing solutions to hard problems too, which leads to the criticism that it's stuck in the 70's. Sure, a lot of the existing solutions to some of these problems aren't perfect or involve tradeoffs that don't work for everyone. In general though, more recent solutions have built upon the lessons of previous approaches and now we've got languages and tooling that get a hell of a lot right, straight out of the box (I'm looking at you Rust / Cargo). But go isn't doing this. They appear to be trying to come up with de novo solutions to problems from the perspective of the 70's. Whereas everyone else is "standing on the shoulders of giants", they insist on discarding the lessons we've learned over the past fifty years and running one by one into all of the same problems that led us to the solutions we have today. As an observer from the sidelines it's painful to watch them relearn these same lessons the hard way.
  - weberc2 9y ago
    I largely agree, and still for everything that Rust and company get right and for everything that Go gets wrong and for how much optimism I approach Rust and company with, I'm still far more productive in Go than any other language (even the ones with which I have much more experience). The only way I can explain this is that programming language design is something of an art form, and the integration of features and tools is far more important than the set of features and tools.
    - geodel 9y ago

jjuel 9y ago

Do you have proof that the Go team has not looked at any other dependency management approaches or considered ones from other languages?

stouset 9y ago
Obviously I don’t, but the available evidence — to me, anyway — points to this being a cultural reality in the golang ecosystem. I left the language years ago, but the steady stream of articles of the form “Why go doesn’t need $x” followed by innumerable comments, articles, and blog posts by people struggling with the lack of $x, followed by the go core team (due to the completely foreseeable consequences of not having $x) begrudgingly adopting $y, which is supposed to (but doesn’t actually) obviate the need for $x… I’ve reached my own conclusions, and I’m finding more and more people who are leaving the ecosystem with those same conclusions. I believe that Go excellently solves problems that Google has. I don’t believe it solves many problems that most other users have, even though it might seem like it at the outset.
- pjmlp 9y ago
  Wait until they finally cave in to generics being one of the top requests on Go surveys and bring something to Go following that same design process.

mseepgood 9y ago

> Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior art went with a particular approach. Actually it's pretty clear that they did their homework.

stouset 9y ago
If you count as “their homework” the dozens of iterations of this we’ve been through. First, it was literally argued that just `go get` just grabbing `master` of all of your dependencies was good enough, because if you ever need to release something backwards-incompatible, you should create a new repo. I wish I were making this up. Then we just vendored everything and never updated our dependencies, and that too was good enough. Then GoPM, go dep, and a deluge of other tools that I don’t care to track down or sort into their appropriate order. And now this, which decides to buck the trends that everyone else follows yet again and attempts to satisfy dependency trees by choosing the minimal compatible versions instead of the maximal ones, with the completely foreseeable consequences that: * security patches won’t be applied * issue trackers will be filled with bug reports that are closed with messages saying “this was fixed months ago, update”, and * updating dependencies will become *harder*, since this is a straightforward result of doing it less frequently
- mjevans 9y ago
  If you can't go get -u all on your project at least you have done something 'wrong' or your upstreams have done something wrong. First, the upstream behavior; not supporting the published interface (as it was and should therefore work forever) means they need to deprecate that interface and release another with the incompatible changes. However the PROPER way of handling this is to add new versions of exposed public methods and interfaces / constants with new names and only if such a major change is required that you can't support the old interfaces, at THAT point, release at least under a new inclusion path if not new dependency name. Things local a developer might have done wrong: A) include an 'immature' upstream repository that behaves like above. B) use non-public components or other unsafe practices to go beyond the interface contract that was exposed.
  - TheDong 9y ago
    I guess using any dependency, directly or transitively, that declares itself pre-1.0 in the go or semver meaning of the word, is thus right out. At that point, almost all of the go ecosystem can't be used.

weberc2 9y ago

> Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior art went with a particular approach. The popular criticism is that Go isn't reinventing enough; that it's stuck in the 70's and it's not sufficiently innovative.

stouset 9y ago
I think it's two sides of the same coin. I've heard go described as a language that doesn't try to solve any hard problems. Let's set aside for a moment whether or not that's a positive or a negative. The bigger problem is that they also seem to completely ignore everyone else's existing solutions to hard problems too, which leads to the criticism that it's stuck in the 70's. Sure, a lot of the existing solutions to some of these problems aren't perfect or involve tradeoffs that don't work for everyone. In general though, more recent solutions have built upon the lessons of previous approaches and now we've got languages and tooling that get a hell of a lot right, straight out of the box (I'm looking at you Rust / Cargo). But go isn't doing this. They appear to be trying to come up with de novo solutions to problems from the perspective of the 70's. Whereas everyone else is "standing on the shoulders of giants", they insist on discarding the lessons we've learned over the past fifty years and running one by one into all of the same problems that led us to the solutions we have today. As an observer from the sidelines it's painful to watch them relearn these same lessons the hard way.
- weberc2 9y ago
  I largely agree, and still for everything that Rust and company get right and for everything that Go gets wrong and for how much optimism I approach Rust and company with, I'm still far more productive in Go than any other language (even the ones with which I have much more experience). The only way I can explain this is that programming language design is something of an art form, and the integration of features and tools is far more important than the set of features and tools.
  - geodel 9y ago