4 ms·

I still wonder why solving a solved problem took so long to solve for the Go community, given they already solved it anyways? That is, in more proper words, fi

by gkya 8y ago

I still wonder why solving a solved problem took so long to solve for the Go community, given they already solved it anyways? That is, in more proper words, first of all, language specific package management is mostly a solved problem. There are possible improvements, and maybe vgo realises some of them, but that's mostly a bikeshedding problem. What users need is to be able to declare what packages they need, in what version range. And their search for an alternative to fetching source repos is like searching for the cure to ilnesses that already have proven vaccines: you just put up a server and fetch from there. Decentralisation? Put up mirrors. Then the way this vgo thing happened is the opposite of nice. Tools already existed, and they had to conform to the restrictions of the project (like the, excuse me but, idiotic idea of a $GOPATH); but then one of the Go deities come around and goes, um, I deprecate all of you, break the rules that you had to comply, and because I-am-who-I-am, this is the way to go. Now Cox's solution might indeed be better (though I think it's an overkill, and do agree to Boyer's articles I read), but this is not the way to run a community. From my PoW, this would not preclude me from using the language if it came up, but I'd definitely be reluctant to send patches to them. Communities with deities and dogmas are always unhealthy. Those that also, additionally, are deep down in yak shaving and bikeshedding are even more so.

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.
jrs95 8y ago
It seems a little unusual for Go because they've generally gone with a good, simple, and well-proven model for things. That's sort of the whole appeal: the good kind of boring. I don't really see the point of the bikeshedding they're engaged in now, and they've made the upgrade path for everyone who's been working under dep, and glide before that, more difficult than it needs to be. The rationale behind it isn't really very solid IMO either. But I suppose I am just a mere mortal, so how I could I possibly understand?
- nicpottier 8y ago
  The upgrade path for dep users is actually pretty easy and they aren't done yet. Vgo will read your dep lock file if it is present and use it to build its own lock file. There are some warts here and there but again, it isn't even out yet and it still works pretty well. I feel like most of the complaints are coming from people who haven't actually give it a go. (pun intended) Russ Cox has also been very responsive with tracking down those problems that do crop up and addressing them quickly. The only really big pain point is if you have a dependency which is > v1 and therefore requires new import paths. You can get around that with virtual versions but that's where the main pain point is. But ironically that isn't at all the bit people are having issues with vgo about. (rather its insistence on MVS)
- kjksf 8y ago
  vgo is exactly in the spirit of Go: they took a popular mechanism and simplified it. vgo works 90% like other systems with one major simplification: it replaces a complicated system of declaring version dependencies which requires SAT solvers to implement with a much simpler, predictable algorithm that they believe will work just as well in practice. As a bonus it also removes the need for lock files, which is what other systems require to fix the issue caused by SAT solver (chosen versions of dependencies are unpredictable and will change if dependencies have newer versions). As it is with engineering, the new method also has drawbacks, which is partly why the issue is so hotly debated. As it is with Go, they believe the advantages of simplicity out weight the drawbacks. We'll have to wait and see until it's implemented and used to really decide. So far Go's strong focus on simplicity served the language pretty well.
lobster_johnson 8y ago
> Now Cox's solution might indeed be better (though I think it's an overkill ... vgo is actually much, much simpler than dep. The sheer number of words in Russ Cox's series of blog posts belies its simplicity. vgo doesn't need a SAT solver. If you look at many of the issues dep is struggling with, they're related to solving N libraries with transitive dependencies up the wazoo. Cox's long treatise reflects the complexity of the problem space. Developers tend to brush off package management as being simple. But once you include range-based version constraints and transitive dependencies, it gets a bit messier. Look at NPM and Yarn; they're still struggling to get all the details right. On the other hand, there's Ruby's Bundler. It came out in 2009, RubyGems in 2004, and I've never had a single issue with the toolchain (other than messing up my own constraints). I don't know what kind of magic elixir they were drinking, but somehow those guys managed to nail it from day one.
- gkya 8y ago
  Simpler does not mean better. ed(1) is definitely simpler than any text editor out there. DOS is simpler than any modern OS out there. Yet we use none of these because complexity is needed for sophistication.
  - BurningCycles 8y ago
    >Simpler does not mean better. Doesn't mean worse either. If it solves the same problem as dep in a less complex way I'd say it's better, if it actually does is something we'll see once it sees adoption.
- Lazare 8y ago
  > Look at NPM and Yarn; they're still struggling to get all the details right. I think that's a bit unfair. NPM has been a horrible package manager in a multitude of ways since day 1. My default assumption if it gets something wrong it isn't because it's hard, but because npm gets a lot of things wrong. Yes, RubyGems got it right, but so did Composer. And Cargo. And every other language specific dependency manager I've used in over a decade. The lesson I'm drawing isn't that dependency management is uniquely hard, it's that npm is uniquely bad. :)

by gkya 8y ago

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.

jrs95 8y ago

It seems a little unusual for Go because they've generally gone with a good, simple, and well-proven model for things. That's sort of the whole appeal: the good kind of boring. I don't really see the point of the bikeshedding they're engaged in now, and they've made the upgrade path for everyone who's been working under dep, and glide before that, more difficult than it needs to be. The rationale behind it isn't really very solid IMO either. But I suppose I am just a mere mortal, so how I could I possibly understand?

nicpottier 8y ago
The upgrade path for dep users is actually pretty easy and they aren't done yet. Vgo will read your dep lock file if it is present and use it to build its own lock file. There are some warts here and there but again, it isn't even out yet and it still works pretty well. I feel like most of the complaints are coming from people who haven't actually give it a go. (pun intended) Russ Cox has also been very responsive with tracking down those problems that do crop up and addressing them quickly. The only really big pain point is if you have a dependency which is > v1 and therefore requires new import paths. You can get around that with virtual versions but that's where the main pain point is. But ironically that isn't at all the bit people are having issues with vgo about. (rather its insistence on MVS)
kjksf 8y ago
vgo is exactly in the spirit of Go: they took a popular mechanism and simplified it. vgo works 90% like other systems with one major simplification: it replaces a complicated system of declaring version dependencies which requires SAT solvers to implement with a much simpler, predictable algorithm that they believe will work just as well in practice. As a bonus it also removes the need for lock files, which is what other systems require to fix the issue caused by SAT solver (chosen versions of dependencies are unpredictable and will change if dependencies have newer versions). As it is with engineering, the new method also has drawbacks, which is partly why the issue is so hotly debated. As it is with Go, they believe the advantages of simplicity out weight the drawbacks. We'll have to wait and see until it's implemented and used to really decide. So far Go's strong focus on simplicity served the language pretty well.

lobster_johnson 8y ago

> Now Cox's solution might indeed be better (though I think it's an overkill ... vgo is actually much, much simpler than dep. The sheer number of words in Russ Cox's series of blog posts belies its simplicity. vgo doesn't need a SAT solver. If you look at many of the issues dep is struggling with, they're related to solving N libraries with transitive dependencies up the wazoo. Cox's long treatise reflects the complexity of the problem space. Developers tend to brush off package management as being simple. But once you include range-based version constraints and transitive dependencies, it gets a bit messier. Look at NPM and Yarn; they're still struggling to get all the details right. On the other hand, there's Ruby's Bundler. It came out in 2009, RubyGems in 2004, and I've never had a single issue with the toolchain (other than messing up my own constraints). I don't know what kind of magic elixir they were drinking, but somehow those guys managed to nail it from day one.

gkya 8y ago
Simpler does not mean better. ed(1) is definitely simpler than any text editor out there. DOS is simpler than any modern OS out there. Yet we use none of these because complexity is needed for sophistication.
- BurningCycles 8y ago
  >Simpler does not mean better. Doesn't mean worse either. If it solves the same problem as dep in a less complex way I'd say it's better, if it actually does is something we'll see once it sees adoption.
Lazare 8y ago
> Look at NPM and Yarn; they're still struggling to get all the details right. I think that's a bit unfair. NPM has been a horrible package manager in a multitude of ways since day 1. My default assumption if it gets something wrong it isn't because it's hard, but because npm gets a lot of things wrong. Yes, RubyGems got it right, but so did Composer. And Cargo. And every other language specific dependency manager I've used in over a decade. The lesson I'm drawing isn't that dependency management is uniquely hard, it's that npm is uniquely bad. :)