5 ms·

> in a specific case, Go did not behave as a community driven project Why are people saying this? What is your reply when folks point out that the "community-d

> in a specific case, Go did not behave as a community driven project Why are people saying this? What is your reply when folks point out that the "community-driven" modules solution did not meet the needs of anyone managing a sufficiently-large project with independently-developed (i.e. 'community'!) dependencies? Rust does the right thing there, this is a fact.

sagichmal 7y ago
dep absolutely met the needs of most/all large projects and advanced users.
- AstralStorm 7y ago
  Who is using it who is not Google? Did anyone with a big project in go even chime in, or is it that there are just no big projects yet?
  - Lazare 7y ago
    Depends what you mean by "big", but between Docker, Influx, Cockroach, etcd, all the hashicorp projects (consul, nomad, terraform), caddy, grafana, bolt, etc., there's a fair number of pretty big golang project around. And most of them seemed pretty happy with dep...
- 0815test 7y ago
  > dep absolutely met the needs of most/all large projects and advanced users. ...as long as your community dependencies never happen to depend in-turn on differing major releases of the same module. This is absolutely a show-stopper, and dep critics were right to highlight it. That these critics might be mostly Googlers in this specific case would seem to be a red herring.
  - sagichmal 7y ago
    > ...as long as your community dependencies never happen to depend in-turn on differing major releases of the same module. This is absolutely a show-stopper No, it isn't. Most other dependency management tools don't allow this condition.
    - 0815test 7y ago
      > Most other dependency management tools don't allow this condition. Ah, but how many of these dependency-management tools are in fact "corporate" vs. genuinely community-led projects? Surely this too is relevant to the controversy.
Lazare 7y ago
> What is your reply when folks point out that the "community-driven" modules solution did not meet the needs of anyone managing a sufficiently-large project with independently-developed (i.e. 'community'!) dependencies? There are many who would dispute your assertion very vigorously. I mean...the core issue was being able to have semantic import versioning, which is a feature most languages used in very large projects do not have. (And the most widely used language to try and solve the underlying issue is node, which is not well known for its suitability for large, complex projects, so...) And Cox tried and failed to explain why he thought semantic import versioning was important to a committee that included many people who had worked on large projects written in Go and other languages, so...must be a bit of a subtle issue. :) But sure. Fine. Let's just accept your entire claim as fact for the sake of argument, because even so, the real concerns here have nothing do with whether or not dep was fit for purpose, it has to do with the Go team's unwillingness to work with the community over what it would mean for a modules tool to be fit for purpose. If you piece together the different accounts, we can say with some confidence what happened, and it's pretty clear that the core issue is the dep team wanted to work with the Go team on a solution that met the needs of everyone, and the Go team did not, so they didn't. Which is fine, of course. Cox had every right to refuse to talk to the dep team, throw their work away, and re-implement it from scratch. I'm sure he enjoyed developing vgo, and perhaps it even saved him time compared to having to explain his ideas to the plebians on the dep committee...but even if so, that's not how you have a successful community driven project. > Rust does the right thing there, this is a fact. Ironic then, that dep was a straight up effort to copy Cargo, and most critic's of the Go teams management of the language have looked to Rust as an inspiration.
- 0815test 7y ago
  > the core issue was being able to have semantic import versioning, Well, the actual core issue was merely being able to use differing major releases as part of the same build, something that dep doesn't itself allow. SIV is a further tweak that's only really needed to address a common wart, namely re-exporting elements of the versioned API from one's imports without semantically-versioning them accurately in the process. What you really need is good semantic re-export versioning, which is a rather minimal subset of SIV!

sagichmal 7y ago

dep absolutely met the needs of most/all large projects and advanced users.

AstralStorm 7y ago
Who is using it who is not Google? Did anyone with a big project in go even chime in, or is it that there are just no big projects yet?
- Lazare 7y ago
  Depends what you mean by "big", but between Docker, Influx, Cockroach, etcd, all the hashicorp projects (consul, nomad, terraform), caddy, grafana, bolt, etc., there's a fair number of pretty big golang project around. And most of them seemed pretty happy with dep...
0815test 7y ago
> dep absolutely met the needs of most/all large projects and advanced users. ...as long as your community dependencies never happen to depend in-turn on differing major releases of the same module. This is absolutely a show-stopper, and dep critics were right to highlight it. That these critics might be mostly Googlers in this specific case would seem to be a red herring.
- sagichmal 7y ago
  > ...as long as your community dependencies never happen to depend in-turn on differing major releases of the same module. This is absolutely a show-stopper No, it isn't. Most other dependency management tools don't allow this condition.
  - 0815test 7y ago
    > Most other dependency management tools don't allow this condition. Ah, but how many of these dependency-management tools are in fact "corporate" vs. genuinely community-led projects? Surely this too is relevant to the controversy.

Lazare 7y ago

> What is your reply when folks point out that the "community-driven" modules solution did not meet the needs of anyone managing a sufficiently-large project with independently-developed (i.e. 'community'!) dependencies? There are many who would dispute your assertion very vigorously. I mean...the core issue was being able to have semantic import versioning, which is a feature most languages used in very large projects do not have. (And the most widely used language to try and solve the underlying issue is node, which is not well known for its suitability for large, complex projects, so...) And Cox tried and failed to explain why he thought semantic import versioning was important to a committee that included many people who had worked on large projects written in Go and other languages, so...must be a bit of a subtle issue. :) But sure. Fine. Let's just accept your entire claim as fact for the sake of argument, because even so, the real concerns here have nothing do with whether or not dep was fit for purpose, it has to do with the Go team's unwillingness to work with the community over what it would mean for a modules tool to be fit for purpose. If you piece together the different accounts, we can say with some confidence what happened, and it's pretty clear that the core issue is the dep team wanted to work with the Go team on a solution that met the needs of everyone, and the Go team did not, so they didn't. Which is fine, of course. Cox had every right to refuse to talk to the dep team, throw their work away, and re-implement it from scratch. I'm sure he enjoyed developing vgo, and perhaps it even saved him time compared to having to explain his ideas to the plebians on the dep committee...but even if so, that's not how you have a successful community driven project. > Rust does the right thing there, this is a fact. Ironic then, that dep was a straight up effort to copy Cargo, and most critic's of the Go teams management of the language have looked to Rust as an inspiration.

0815test 7y ago
> the core issue was being able to have semantic import versioning, Well, the actual core issue was merely being able to use differing major releases as part of the same build, something that dep doesn't itself allow. SIV is a further tweak that's only really needed to address a common wart, namely re-exporting elements of the versioned API from one's imports without semantically-versioning them accurately in the process. What you really need is good semantic re-export versioning, which is a rather minimal subset of SIV!