4 ms·

Am I correct in thinking that this proposal only lays the foundation for other tools to actually manage the vendor folder? In other words, you would still want

Am I correct in thinking that this proposal only lays the foundation for other tools to actually manage the vendor folder? In other words, you would still want something like godep or gb, because manually copying dependencies into a folder (or using git submodules, ugh), and then tracking their versions through their lifecycle, isn't a workable solution in most situations. This is clearly an improvement over "go get", but I don't understand why Go is so insistent that dependency management is something for the community to solve, and not something that should be provided by Go itself. Go is so opinionated about so many things, and yet so little interested in having a strong opinion here. The Unix philosophy is great, to be sure, but the Unix philosophy is about increasing modularity through simplicity, and this problem is about modularity.

vruiz 11y ago
> I don't understand why Go is so insistent that dependency management is something for the community to solve, and not something that should be provided by Go itself. They don't want to try solving a problem they don't really have. As RSC says: > the community understands and encounters these problems more than we on the Go team at Google do.
- lobster_johnson 11y ago
  I find it worrying that Go is seemingly entirely stewarded by a company whose technical workflow is so different, to the extent that it curtails technical decisions. It's designing for the lowest common denominator in an equation that emphasizes Google. Even if your company doesn't need or want Bundler/Cargo-style dependency management doesn't mean that you are intellectually unfit to design out a good solution together with the community. Dogfooding is great and all, but it's actually possible to design technical solutions that you won't personally use.
  - sqs 11y ago
    > I find it worrying that Go is seemingly entirely stewarded by a company whose technical workflow is so different, to the extent that it curtails technical decisions. It's designing for the lowest common denominator in an equation that emphasizes Google. There are thousands of programming languages out there, yet Go has quite a bit of traction. They haven't forced anyone to use it, so there must be some reason for that. Maybe Go is successful because it was made with Google's technical workflow in mind.
    - aikah 11y ago
      > Maybe Go is successful because it was made with Google's technical workflow in mind Sure, but Dart has a fully featured package manager, are you saying Dart was designed at Google without Google's technical workflow in mind? It's silly. > There are thousands of programming languages out there, More like hundreds of viable programming languages, not thousands. Anybody can code a lisp in his bedroom,doesn't mean it's production ready. > They haven't forced anyone to use it It's a childish and arrogant statement. Just like the "You don't need that in Go"TM. Opening source something was a political decision, but if you're saying Go doesn't need a community then by all means, state it clearly.
      - enneff 11y ago
        I think the point was that the large community that has formed around Go is made up of willing participants, not conscripts.
  - advanderveer 11y ago
    I get really disappointed when reading such responses. Even when large companies admin they don't know everything and want to see and listen to the rest of the world, its not good enough.
    - deleted 11y ago
      [deleted]
      - lobster_johnson 11y ago
        Well, I actually use Go. If I complain, it's because I want things to be better, not because I hate Google's baby.
  - saidajigumi 11y ago
    > I find it worrying that Go is seemingly entirely stewarded by a company whose technical workflow is so different, to the extent that it curtails technical decisions. Having worked at a few such, this is utterly unsurprising. Large development organizations, ala Google, Amazon, etc. are utterly unlike anything on "the outside". This happens slowly over time and is a combination of many factors: centralization of infrastructure, sheer scale (the developer tools teams in many of these shops are often bigger than many other entire software companies), the ability to make cross-cutting decisions for the organization in ways that aren't appropriate for a decentralied external community, etc. Given all that, I give huge props to the Go team for this kind of self-restraint. It's an enourmously painful decision for the community, but absolutely the right one if you aren't actually feeling the pain. I've seen too many communities suffer because of bad decisions and/or churn as the packaging system breaks and is forced to evolve.
- aikah 11y ago
  > They don't want to try solving a problem they don't really have. yet Dart has an official package manager ,which is called pub. So the Go team don't want to solve this problem because they don't have this problem , but the Dart team wants to solve this problem even though they don't have this problem? Do you know what is the name for that? it's not technicality is is called POLITICS. EDIT: and both teams work at Google.
  - TylerE 11y ago
    At google, the entire codebase is basically one big repo. Everything uses the newest version of everything. There is essentially no dependency management because there are no dependencies.
    - deleted 11y ago
      [deleted]
      - deleted 11y ago
        [deleted]
    - zellyn 11y ago
      cough Everything uses the _same_ version of everything.
  - enneff 11y ago
    It's not a political thing. The Go team and the Dart team have different design philosophies. If this were not the case, then they wouldn't be making two different languages.
enneff 11y ago
> Am I correct in thinking that this proposal only lays the foundation for other tools to actually manage the vendor folder? Yes. > I don't understand why Go is so insistent that dependency management is something for the community to solve Well, they solved it, and now we are beginning to adopt their solution. Seems to be working.
- lobster_johnson 11y ago
  Given that you still need an external tool not provided by Go, I'm not sure it's "solved" until the community rallies around a single tool, like Ruby did with RubyGems and later Bundler.
  - deleted 11y ago
    [deleted]
  - tshannon 11y ago
    He's saying the community solved it, and the Go Team is using the best ideas from the community to start implementing a solution built into the Go tools. This has been their policy from the start. The Go team knows that Google tends to handle dependency management differently from your standard project, so they left it to the community to help build and decide which tools and ideas work best for dependency management. Several have arisen, and the Go team has started implementing some of those ideas.
  - enneff 11y ago
    It's solved in the sense that the community has converged on a particular approach, and now we are supporting that approach in the go tool.
    - NateDad 11y ago
      Which is fantastic. Thank you!
  - rsc 11y ago
    Yes and no. This is about agreeing on a common file tree layout. It's not the end of the story: there is a separate effort (github.com/kardianos/vendor-spec) about agreeing on a common format for recording where code came from. Once there is agreement on those, however, I am not sure how important it will be to agree on a single program, although there may end up being natural agreement anyway. The Go community need not rally around a single text editor, because instead we agree on what Go source files are and that they are named *.go. It may be that something similar can happen here.
rsc 11y ago
Is the criticism here really that we have declined to express a strong opinion about something we don't know a lot about?
- deleted 11y ago
  [deleted]
- lamejoke 11y ago
  That never stopped you regarding generics!
  - rsc 11y ago
    I can assure we've spent far more time thinking about generics than about vendoring.
- ngrilly 11y ago
  A quick comment to tell you that I really really appreciate how you solve problems step-by-step, without rushing. The improvement you proposed for supporting vendoring in Go 1.5 is great.
twblalock 11y ago
> I don't understand why Go is so insistent that dependency management is something for the community to solve The expectation that every new language should come with a dependency management ecosystem is a bit questionable. A lot of major languages' dependency management solutions were created by the community: Java: Maven, Gradle Python: PIP Ruby: Gems Node.js: NPM Some of these have been adopted by the official language maintainers, but as far as I know, they originated in the community.
- coldtea 11y ago
  The problem is that Go implements a half-arsed way of dependency management (go get) and enforces things like GOPATH that clash with community created solutions.

vruiz 11y ago

> I don't understand why Go is so insistent that dependency management is something for the community to solve, and not something that should be provided by Go itself. They don't want to try solving a problem they don't really have. As RSC says: > the community understands and encounters these problems more than we on the Go team at Google do.

lobster_johnson 11y ago
I find it worrying that Go is seemingly entirely stewarded by a company whose technical workflow is so different, to the extent that it curtails technical decisions. It's designing for the lowest common denominator in an equation that emphasizes Google. Even if your company doesn't need or want Bundler/Cargo-style dependency management doesn't mean that you are intellectually unfit to design out a good solution together with the community. Dogfooding is great and all, but it's actually possible to design technical solutions that you won't personally use.
- sqs 11y ago
  > I find it worrying that Go is seemingly entirely stewarded by a company whose technical workflow is so different, to the extent that it curtails technical decisions. It's designing for the lowest common denominator in an equation that emphasizes Google. There are thousands of programming languages out there, yet Go has quite a bit of traction. They haven't forced anyone to use it, so there must be some reason for that. Maybe Go is successful because it was made with Google's technical workflow in mind.
  - aikah 11y ago
    > Maybe Go is successful because it was made with Google's technical workflow in mind Sure, but Dart has a fully featured package manager, are you saying Dart was designed at Google without Google's technical workflow in mind? It's silly. > There are thousands of programming languages out there, More like hundreds of viable programming languages, not thousands. Anybody can code a lisp in his bedroom,doesn't mean it's production ready. > They haven't forced anyone to use it It's a childish and arrogant statement. Just like the "You don't need that in Go"TM. Opening source something was a political decision, but if you're saying Go doesn't need a community then by all means, state it clearly.
    - enneff 11y ago
      I think the point was that the large community that has formed around Go is made up of willing participants, not conscripts.
- advanderveer 11y ago
  I get really disappointed when reading such responses. Even when large companies admin they don't know everything and want to see and listen to the rest of the world, its not good enough.
  - deleted 11y ago
    [deleted]
    - lobster_johnson 11y ago
      Well, I actually use Go. If I complain, it's because I want things to be better, not because I hate Google's baby.
- saidajigumi 11y ago
  > I find it worrying that Go is seemingly entirely stewarded by a company whose technical workflow is so different, to the extent that it curtails technical decisions. Having worked at a few such, this is utterly unsurprising. Large development organizations, ala Google, Amazon, etc. are utterly unlike anything on "the outside". This happens slowly over time and is a combination of many factors: centralization of infrastructure, sheer scale (the developer tools teams in many of these shops are often bigger than many other entire software companies), the ability to make cross-cutting decisions for the organization in ways that aren't appropriate for a decentralied external community, etc. Given all that, I give huge props to the Go team for this kind of self-restraint. It's an enourmously painful decision for the community, but absolutely the right one if you aren't actually feeling the pain. I've seen too many communities suffer because of bad decisions and/or churn as the packaging system breaks and is forced to evolve.
aikah 11y ago
> They don't want to try solving a problem they don't really have. yet Dart has an official package manager ,which is called pub. So the Go team don't want to solve this problem because they don't have this problem , but the Dart team wants to solve this problem even though they don't have this problem? Do you know what is the name for that? it's not technicality is is called POLITICS. EDIT: and both teams work at Google.
- TylerE 11y ago
  At google, the entire codebase is basically one big repo. Everything uses the newest version of everything. There is essentially no dependency management because there are no dependencies.
  - deleted 11y ago
    [deleted]
    - deleted 11y ago
      [deleted]
  - zellyn 11y ago
    cough Everything uses the _same_ version of everything.
- enneff 11y ago
  It's not a political thing. The Go team and the Dart team have different design philosophies. If this were not the case, then they wouldn't be making two different languages.

enneff 11y ago

> Am I correct in thinking that this proposal only lays the foundation for other tools to actually manage the vendor folder? Yes. > I don't understand why Go is so insistent that dependency management is something for the community to solve Well, they solved it, and now we are beginning to adopt their solution. Seems to be working.

lobster_johnson 11y ago
Given that you still need an external tool not provided by Go, I'm not sure it's "solved" until the community rallies around a single tool, like Ruby did with RubyGems and later Bundler.
- deleted 11y ago
  [deleted]
- tshannon 11y ago
  He's saying the community solved it, and the Go Team is using the best ideas from the community to start implementing a solution built into the Go tools. This has been their policy from the start. The Go team knows that Google tends to handle dependency management differently from your standard project, so they left it to the community to help build and decide which tools and ideas work best for dependency management. Several have arisen, and the Go team has started implementing some of those ideas.
- enneff 11y ago
  It's solved in the sense that the community has converged on a particular approach, and now we are supporting that approach in the go tool.
  - NateDad 11y ago
    Which is fantastic. Thank you!
- rsc 11y ago
  Yes and no. This is about agreeing on a common file tree layout. It's not the end of the story: there is a separate effort (github.com/kardianos/vendor-spec) about agreeing on a common format for recording where code came from. Once there is agreement on those, however, I am not sure how important it will be to agree on a single program, although there may end up being natural agreement anyway. The Go community need not rally around a single text editor, because instead we agree on what Go source files are and that they are named *.go. It may be that something similar can happen here.

rsc 11y ago

Is the criticism here really that we have declined to express a strong opinion about something we don't know a lot about?

deleted 11y ago
[deleted]
lamejoke 11y ago
That never stopped you regarding generics!
- rsc 11y ago
  I can assure we've spent far more time thinking about generics than about vendoring.
ngrilly 11y ago
A quick comment to tell you that I really really appreciate how you solve problems step-by-step, without rushing. The improvement you proposed for supporting vendoring in Go 1.5 is great.

twblalock 11y ago

> I don't understand why Go is so insistent that dependency management is something for the community to solve The expectation that every new language should come with a dependency management ecosystem is a bit questionable. A lot of major languages' dependency management solutions were created by the community: Java: Maven, Gradle Python: PIP Ruby: Gems Node.js: NPM Some of these have been adopted by the official language maintainers, but as far as I know, they originated in the community.

coldtea 11y ago
The problem is that Go implements a half-arsed way of dependency management (go get) and enforces things like GOPATH that clash with community created solutions.