3 ms·

Note that none of the vgo precursors (or currently vgo itself) have been official Go tools. dep, for example, is an experiment. Tools have certainly existed, s

by ovao 8y ago

Note that none of the vgo precursors (or currently vgo itself) have been official Go tools. dep, for example, is an experiment. Tools have certainly existed, sure. And they continue to exist. But they have not been official Go tools.

jrs95 8y ago
The irony is that dep was an implementation of a widely used and well tested pattern, and that vgo is essentially a new paradigm which has been accepted after just a proposal rather than a full-blown experiment. This particular problem has been obvious since Go was first open sourced, and the way the solution is being managed is a pain in the ass.
- ovao 8y ago
  I don’t disagree on any particular point. From a community-oriented perspective it seems odd to me as well, but I’m completely unqualified to critique the proposal on its technical merits. All I can say is A) I hope it’s a good technical approach and B) I hope it doesn’t result in some kind of massive chasm.
  - gkya 8y ago
    > but I’m completely unqualified to critique the proposal on its technical merits. If you ever used a working, solid package manager, you're qualified to critique. I've used many languages and their respective package managers, they just worked and got out of my way, even if I used the language to just write a hello world and see what libraries are available. With Go however, there always is a Schrodinger's package manager that is always on there like some reality show, and when you observe it finally, what do you see? Something some guy likes better than what the community was nearly deciding to universally adopt. All these shenanigans are off-putting. Especially when the blinking problem is fetching some tarballs and extracting files out of them after maybe checking checksums. CPAN's been doing that since the good part of the 90's.

3 ms·

Note that none of the vgo precursors (or currently vgo itself) have been official Go tools. dep, for example, is an experiment. Tools have certainly existed, s

by ovao 8y ago

jrs95 8y ago
The irony is that dep was an implementation of a widely used and well tested pattern, and that vgo is essentially a new paradigm which has been accepted after just a proposal rather than a full-blown experiment. This particular problem has been obvious since Go was first open sourced, and the way the solution is being managed is a pain in the ass.
- ovao 8y ago
  I don’t disagree on any particular point. From a community-oriented perspective it seems odd to me as well, but I’m completely unqualified to critique the proposal on its technical merits. All I can say is A) I hope it’s a good technical approach and B) I hope it doesn’t result in some kind of massive chasm.
  - gkya 8y ago
    > but I’m completely unqualified to critique the proposal on its technical merits. If you ever used a working, solid package manager, you're qualified to critique. I've used many languages and their respective package managers, they just worked and got out of my way, even if I used the language to just write a hello world and see what libraries are available. With Go however, there always is a Schrodinger's package manager that is always on there like some reality show, and when you observe it finally, what do you see? Something some guy likes better than what the community was nearly deciding to universally adopt. All these shenanigans are off-putting. Especially when the blinking problem is fetching some tarballs and extracting files out of them after maybe checking checksums. CPAN's been doing that since the good part of the 90's.