12 ms·

The vgo proposal is accepted. Now what?

158 points by stablemap 8y ago

adwhit 8y ago
For those who missed it, Sam Boyer (maintainer of dep) wrote a detailed post about why he thinks vgo (or rather Minimum Version Selection) is inadequate[0]. The key argument is With dep, it’s usually easy to point to failures - they’re explicit, verbose (and, currently, often difficult to understand, and printed out at the end of a dep ensure run. The primary failure mode in vgo, however, is silent false positives - a vgo {get,test,run,build} command changes your dependency graph, and exits 0. Maybe everything’s fine, maybe it isn’t, but it’s incumbent upon you to take additional steps to understand that your build is broken. I haven't been following this debate very closely, and this post doesn't make it clear - have these points been addressed? Is there still room to maneuver, or is the design mostly settled now? I know the post states that any design flaws will be fixed, but it sounds very much like the more typical lock-file + solver solution has been definitively decided against. [0] https://sdboyer.io/vgo/failure-modes/ https://sdboyer.io/vgo/failure-modes/
- tmpz22 8y ago
  I just hope they figure out a solution which satisfies the community for the long run. Maybe they have already with vgo, but this is starting to feel vary Javascript-y the way people have been pushed from $OLD_PACKAGE_MANAGER -> dep -> vgo.
  - jrs95 8y ago
    Had vgo not included MVS I think they likely would have. But there's a lot of disagreement over the design of vgo which could have been avoided had it just done what almost every other recent package manager has done. This is going to make it more painful than it ought to be, but ultimately since this will be the official solution I think it's likely that it will be adopted and that the churn will end since third party tools are no longer necessary.
    - stubish 8y ago
      Third party tools will still be necessary, to work around short comings. I imagine a tool to update all your imports to the latest release will be needed by the majority who don't need reproducible builds, so you get versions with known bugs fixed. MVS seems to be essentially pinning to the oldest possible version, and having that entrenched in your software is going to suck the big tech debt when you do need to update. Hope none of the known bugs are data loss or security related, and good luck monitoring each and every one of your explicit and transient dependencies for updates on a larger project. A tool to update your dependencies to the latest version when convenient or for automated CI tests seems required to me.
      - kaeshiwaza 8y ago
        Look at https://research.swtch.com/vgo-tour https://research.swtch.com/vgo-tour (Upgrading) vgo list -m -u will show you which newer releases of your dependencies. Then you can upgrade one dependencies vgo get xxx or all vgo get -u
        stubish 8y ago
        Excellent, that seems to address my misgivings. Thanks.
  - ljm 8y ago
    Quite the contrary: NPM's reputation in these circles is less than stellar and it's been incumbent in the JS ecosystem ever since Node became a thing. Well, with a few attempts at competition along the way before those working with the browser jumped on board, but nobody is pushing anybody to use anything but NPM and that attitude hasn't changed for years. This story isn't unique to Go: both Python and Ruby have had their own ordeals with dependency management, there was an article about CMake just the other day... Maybe Go's mistake is searching for the one-true dependency resolution system and deprecating everything along the way until something good-enough turns up. Maybe it'd be better that developers are encouraged to use dep while vgo is still in proposal stage so that there is an easy migration path from one standard to another, as opposed to immediately rendering obsolete. I don't really know, neither do I know why Javascript is the scapegoat for this kind of shit, it's practically a rite of passage for a language gaining increasing mind-share.
    - weberc2 8y ago
      > Maybe Go's mistake is searching for the one-true dependency resolution system and deprecating everything along the way until something good-enough turns up. Maybe it'd be better that developers are encouraged to use dep while vgo is still in proposal stage so that there is an easy migration path from one standard to another, as opposed to immediately rendering obsolete. The odd thing is I get the feeling that their search for the one-true system is causing them to repeat every other package manager's mistakes. I'm likely misinformed, but I get the feeling that they think they can do the same thing other package managers have considered or tried, but it will work for them somehow. I don't get the feeling that they seriously considered the criticism of VGo's approach. It smells like hubris. Also, there's Cargo, which is lauded by all, but the proposal doesn't seem to consider that perhaps the Cargo folks had a reason to make their dependency resolution scheme complicated. Again, this smacks of hubris. I'm happy to be persuaded otherwise, and it would really only take a link to a thread in which some VGo proponent thoughtfully addresses Sam's criticism and the "why not copy Cargo?" criticism (and no, the "Cargo's dep resolution scheme is overly complicated" rationale from the proposal doesn't constitute).
      - ljm 8y ago
- TheSwordsman 8y ago
  The concerns haven't been addressed. Sam's latest comment for context: - https://github.com/golang/go/issues/24301#issuecomment-392549295 https://github.com/golang/go/issues/24301#issuecomment-39254...
- nicpottier 8y ago
  They haven't been addressed, but then again they exist in `dep` as well and most other package managers, just in different forms. Russ Cox had a good talk about this which is worth a watch: https://www.youtube.com/watch?v=F8nrpe0XWRg&feature=youtu.be&t=25m34s https://www.youtube.com/watch?v=F8nrpe0XWRg&feature=youtu.be...
  - Groxx 8y ago
    >They haven't been addressed, but then again they exist in `dep` as well and most other package managers, just in different forms. The whole premise of the blog post is that vgo has additional failure modes that other ones do not. Right at the top, the first item in the list of "what this post covers" is: >MVS has all the same failure modes, plus more, minus pathological SAT.
- skybrian 8y ago
  It's worth pointing out that when working in a monorepo, there are no version numbers and no package system to tell you that upstream broke you, or you broke something downstream. So how do you find bugs? You run tests. The same can be true if you're working with package management. Most bugs aren't found by the dependency tracking system anyway. Having good tests will tell you about incompatibilities that upstream didn't even know about. If you're not using exactly the same versions that the maintainer used, you need to run tests. Maybe people currently don't run tests often enough? But this suggests a different approach to software robustness than comparing version numbers.
  - lobster_johnson 8y ago
    Testing and package management aren't mutually exclusive. If you're in a monorepo, all your code evolves in lockstep. A core tenet of versioned package management is to get reproducible builds that only need to break once you choose to evolve forward in time (i.e. upgrade). Historically, most languages (C, C++, pre-Maven Java) haven't had package management at all, and so dependencies have typically been managed by vendoring the code (or JAR files). JAR files worked okay, but vendoring incurs maintenance overhead that isn't acceptable in today's environment. git submodules are theoretically a solution, but also high-maintenance.
    - skybrian 8y ago
      Yes, you are right. And I believe vgo is supposed to guarantee reproducible builds just like other package systems. However, when you upgrade a dependency, it's still possible that you're using a particular combination of library versions that have never been tested before. Some incompatibilities can be prevented by looking at version constraints. But you're not left with no error detection if the package system fails to detect an incompatibility; in the end, what matters is that the code compiles and the tests pass.
      - oceanswave 8y ago
        This methodology places way too much emphasis on the breadth of the tests into a test centric view— say you had a dep that had an SSL vulnerability - most of the time you’re not going to be checking for this type of thing at the level of your app, and doing so - but you bet you need to ensure that you are using the version of the dep that has the vulnerability fixed
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
markrages 8y ago
This article is about the Go programming language (and environment).
jrs95 8y ago
> Now what? I keep using dep for as long as it's reasonable for me to do so, because I don't like MVS and I don't like how MVS has been basically forced upon us.
- wuliwong 8y ago
  What is MVS?
  - kasey_junk 8y ago
    The new dependency resolution algo in vgo.
  - mali9 8y ago
    Minimal Version Selection https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs
- throwaway243425 8y ago
  Soon many packages will start having the module system that comes with vgo and just like aliases, community means nothing to Go.
- niftich 8y ago
  Out of curiosity, what are some of the reasons why you dislike MVS?
dstroot 8y ago
I first used $GOPATH and “go get”. Was amazed at how simple and easy it was and it “just worked”. Then you start to run into issues... so I started using Glide. Which worked pretty darn well. Then I switched to Dep because “it was the future” and it didn’t cause me to break out in hives. Now vgo... but Dep works for me so at the moment I don’t plan to switch until vgo is good and baked. Given Boyer’s concerns I hope he maintains Dep for a while as vgo is polished. Too bad this was not part of the vision at the start. Not sure where JS would be without NPM, etc.
- kodablah 8y ago
  > Not sure where JS would be without NPM Where it was before NPM, i.e. where Go is today. No real versioning or discovery (granted Go has qualified URLs for discovery).
anonfunction 8y ago
I really do not like the “semver-like” versioning string requirement. My packages are already tagged with valid semver releases and now I need to change them by adding a “v” prefix. If you don’t know what I’m talking about vgo requires the release to be tagged like “v1.0.3” which is not standard semver.
- cesarb 8y ago
  > vgo requires the release to be tagged like “v1.0.3” which is not standard semver Are you talking about git tags? Tagging a release with a "v" followed by the version number has been done since the very first git repository. I don't think semver has any official standard; the closest I can find is https://semver.org/spec/v1.0.0.html https://semver.org/spec/v1.0.0.html, which does say "When tagging releases in a version control system, the tag for a version MUST be “vX.Y.Z” e.g. “v3.1.0”."
  - anonfunction 8y ago
    Yes I am talking about git tags. I purposely followed semver 2.0.0 which doesn't mention anything about a "v" prefix. Thanks for finding an old mention of version control tagging! At the end of the day it's not a big deal. I will just duplicate the tags so it won't break any dep configurations.
- lobster_johnson 8y ago
  Every Go project I've used uses git tags prefixed with "v", e.g. v1.0.3. https://github.com/gogo/protobuf https://github.com/gogo/protobuf https://github.com/olivere/elastic https://github.com/olivere/elastic https://github.com/golang/protobuf https://github.com/golang/protobuf https://github.com/sanity-io/litter https://github.com/sanity-io/litter
  - anonfunction 8y ago
    I've seen a few that used 1.0.3 which is also common among python and other languages. One of the biggest new go projects, istio[1], uses the 1.0.3 style. I'll switch over in the future and keep existing tags for dep users. 1. https://github.com/istio/istio/tags https://github.com/istio/istio/tags
eberkund 8y ago
I wish they had just copied Rust/Cargo. I remember reading a comment on GitHub somewhere from one of the Go maintainers who responded to someone expressing a similar sentiment and his reply was basically that Go is somehow different than every other language and they need to explore and find a unique custom solution for their particular use case. Has it ever been addressed anywhere why the tried and true "list of packages" + "lock file" paradigm is not good enough for Go?
- TheSwordsman 8y ago
  I wish it was as simple as that. Instead it's that that Russ Cox is fundamentally against SAT solvers, and has opted take this alternative approach instead. I think they would have been better off iterating on the things that have worked for other languages and tools, and arguably a SAT solver is one of them.
- lobster_johnson 8y ago
  Rust/Cargo had the luxury of being a greenfield project that could adopt semver from the beginning, whereas Go made the mistake of starting out, and then going years, without any official package management solution. As a result, Go has a swathe of applications and libraries that use specific workflows as well as a mélange of community-developed package management tools such as godep, Glide and dep. The semver standard, in particular, has been inconsistently adopted by the Go community. In other words, any new Go tool either has to support/import existing code, or to wipe the slate clean and say that for a package to be importable it has to follow a new spec. dep decided on the former, and my impression is that this has had unfortunate consequences, because that inherits a lot of historical baggage. We've been using dep for a while (having escaped the bugfest that is Glide, which used a very similar approach), and it's pretty evident that the solver is buggy and slow and also complicated enough that fixing issues like [1] can only be done by a select few that already understand the codebase. I'm not in a position to judge what the causes of all of these issues are, though I'd wager they're not entirely unrelated to the inherent complexity of SAT solving. The current dep issue tracker is full [2] of reports mentioning the solver, not to mention that dep currently has problems with known libraries such as the Kubernetes client [3] and Protobuf. (Google-related projects have historically used godep.) Again, possibly related to this specific implementation and not necessarily something that would apply to a hypothetical "Cargo for Go", but I don't know. Any idea how Cargo compares to dep overall? [1] https://github.com/golang/dep/issues/1306 https://github.com/golang/dep/issues/1306 — this one is a nightmare if you work anything related to Kubernetes. [2] https://github.com/golang/dep/issues?q=is%3Aissue+is%3Aopen+solver https://github.com/golang/dep/issues?q=is%3Aissue+is%3Aopen+... [3] https://github.com/golang/dep/issues/1207 https://github.com/golang/dep/issues/1207
gyrgtyn 8y ago
As someone who just recently started using go, this seems really dumb.
- reificator 8y ago
  The churn in dependency management is one of the worst issues with go. The other is not having a canonical GUI option, instead mostly just bindings to other toolkits with varying completeness and quality. That said, I think it's worth sticking with go for the quality of the language itself. If you don't need a GUI (or plan to use a web GUI) it's a really nice balance of design decisions that let you actually get things done.
fortyseven 8y ago
Now... we bring him the baby so that he might rule this world again!
throwaway243425 8y ago
To an outsider this may sound like there is some sort of process that resulted in this solution, there actually isn't any. The committee is nothing more than a simple bureaucracy to the point that it is almost a joke how Russ makes a proposal, community is against it, then it gets accepted by the Committee. It is all just a funny joke.
- jimmy1 8y ago
  > To an outsider > Russ > throwaway Something tells me you aren't really an outsider. Anyways, > community is against it, then it gets accepted by the Committee Is this your primary gripe? Because this has happened pretty consistently in the history of almost all open source languages. Think of how many JSRs were hotly contested, only to be accepted. Open source does not mean democratic development, and thankfully so because you might have ended up with this https://i.redd.it/7t1p88ct13ez.jpg https://i.redd.it/7t1p88ct13ez.jpg
  - dikaiosune 8y ago
    FWIW, I read "To an outsider..." to mean "if you are reading this on HN and aren't involved in the community, this might seem like" as opposed to "I am pretending to be an outsider, let me tell you what about my perspective."
- Spiritus 8y ago
  Who says the community is against it? I happen to like it.
  - kaeshiwaza 8y ago
    Looking at the thumbs up and the comments, the community seems very favorable at vgo. https://github.com/golang/go/issues/24301 https://github.com/golang/go/issues/24301 edit: and everybody was not agree at the time of Dep launch as it was not simple as Go use to be.
- eknkc 8y ago
  Community is not against it as far as I can see. A minority of vocal people are. There are a lot of people who liked the idea (including me) and those do not write 30 page blog posts because there is no need.
matte_black 8y ago
What does this mean for someone who is starting out with Go?
- lobster_johnson 8y ago
  Nothing yet. The new tools should land in 1.11, but will be an experimental opt-in, with the aim of full support in 1.12.
- mahmoudhossam 8y ago
  Use dep for now, it's the closest thing to a stable package manager for go. And you'll also have the smoothest path to a vgo migration in the future.
- eosrei 8y ago
  Nothing. Use dep now. In fact, since you are just starting out, see how far you can get using only the standard library. Later, there will be a seamless upgrade to vgo.
  - marcus_holmes 8y ago
    Seconded. Unlike Node/Ruby/most other modern languages, Go devs actively avoid including dependencies if at all possible. And contrary to rumour, this is not because Go's dependency management sucks. It's more about the pursuit of simplicity, and avoidance of magic. You can write pretty much anything using just the standard library (and some of the official packages, like the crypto ones). As the parent said, it's good practice to go as far as possible with just the stdlib.
    - oceanswave 8y ago
      So go is about recreating the wheel, over and over again
      - sethammons 8y ago
        Not really. Generally, the wheel you need and the wheel I need are a bit different. Instead of using some bloated "all-wheel," developers choose their custom wheel. Simple example, SyncMap. This is a general purpose all-wheel, and as such, due to Go's type system, you have to use runtime type assertions against it. If I need a lockable map, I just make one and it is of the type I need, say map[string]*Foo. I just wrap it in a struct with a lock and I'm done. For more complicated things, most everyone will pull in a package. I'm not going to waste some time making a Redis or Kafka package. For a web server, I may pull in a different muxer, but only if needed.
Avi-D-coder 8y ago
How does Haskell's cabal compare to vgo?
- danharaj 8y ago
  Cabal uses a SAT solver. It's in the middle of a beta for replacing it's global package management with per-project package management by default (so-called new-style builds). There were some warts in the past when it couldn't manage different versions of the same package, I think because of a ghc issue but that is in the past. Most industrial users use stack or nix on top which reduce the use of Cabal's version solver.
ospider 8y ago
Besides the technical details between vgo and dep. The go team just announced and accepted its own proposal, completely ignoring the community's solutions, dep was even called the official experiment, which is sad.
rahenri 8y ago
There is a lot of criticism on the proposal with a lot of good reason. But, I'm honestly very excited about the deprecation of GOPATH, that was one of the most annoying features of go for me.

158 points by stablemap 8y ago

For those who missed it, Sam Boyer (maintainer of dep) wrote a detailed post about why he thinks vgo (or rather Minimum Version Selection) is inadequate[0]. The key argument is With dep, it’s usually easy to point to failures - they’re explicit, verbose (and, currently, often difficult to understand, and printed out at the end of a dep ensure run. The primary failure mode in vgo, however, is silent false positives - a vgo {get,test,run,build} command changes your dependency graph, and exits 0. Maybe everything’s fine, maybe it isn’t, but it’s incumbent upon you to take additional steps to understand that your build is broken. I haven't been following this debate very closely, and this post doesn't make it clear - have these points been addressed? Is there still room to maneuver, or is the design mostly settled now? I know the post states that any design flaws will be fixed, but it sounds very much like the more typical lock-file + solver solution has been definitively decided against. [0] https://sdboyer.io/vgo/failure-modes/ https://sdboyer.io/vgo/failure-modes/

tmpz22 8y ago
I just hope they figure out a solution which satisfies the community for the long run. Maybe they have already with vgo, but this is starting to feel vary Javascript-y the way people have been pushed from $OLD_PACKAGE_MANAGER -> dep -> vgo.
- jrs95 8y ago
  Had vgo not included MVS I think they likely would have. But there's a lot of disagreement over the design of vgo which could have been avoided had it just done what almost every other recent package manager has done. This is going to make it more painful than it ought to be, but ultimately since this will be the official solution I think it's likely that it will be adopted and that the churn will end since third party tools are no longer necessary.
  - stubish 8y ago
    Third party tools will still be necessary, to work around short comings. I imagine a tool to update all your imports to the latest release will be needed by the majority who don't need reproducible builds, so you get versions with known bugs fixed. MVS seems to be essentially pinning to the oldest possible version, and having that entrenched in your software is going to suck the big tech debt when you do need to update. Hope none of the known bugs are data loss or security related, and good luck monitoring each and every one of your explicit and transient dependencies for updates on a larger project. A tool to update your dependencies to the latest version when convenient or for automated CI tests seems required to me.
    - kaeshiwaza 8y ago
      Look at https://research.swtch.com/vgo-tour https://research.swtch.com/vgo-tour (Upgrading) vgo list -m -u will show you which newer releases of your dependencies. Then you can upgrade one dependencies vgo get xxx or all vgo get -u
      - stubish 8y ago
        Excellent, that seems to address my misgivings. Thanks.
- ljm 8y ago
  Quite the contrary: NPM's reputation in these circles is less than stellar and it's been incumbent in the JS ecosystem ever since Node became a thing. Well, with a few attempts at competition along the way before those working with the browser jumped on board, but nobody is pushing anybody to use anything but NPM and that attitude hasn't changed for years. This story isn't unique to Go: both Python and Ruby have had their own ordeals with dependency management, there was an article about CMake just the other day... Maybe Go's mistake is searching for the one-true dependency resolution system and deprecating everything along the way until something good-enough turns up. Maybe it'd be better that developers are encouraged to use dep while vgo is still in proposal stage so that there is an easy migration path from one standard to another, as opposed to immediately rendering obsolete. I don't really know, neither do I know why Javascript is the scapegoat for this kind of shit, it's practically a rite of passage for a language gaining increasing mind-share.
  - weberc2 8y ago
    > Maybe Go's mistake is searching for the one-true dependency resolution system and deprecating everything along the way until something good-enough turns up. Maybe it'd be better that developers are encouraged to use dep while vgo is still in proposal stage so that there is an easy migration path from one standard to another, as opposed to immediately rendering obsolete. The odd thing is I get the feeling that their search for the one-true system is causing them to repeat every other package manager's mistakes. I'm likely misinformed, but I get the feeling that they think they can do the same thing other package managers have considered or tried, but it will work for them somehow. I don't get the feeling that they seriously considered the criticism of VGo's approach. It smells like hubris. Also, there's Cargo, which is lauded by all, but the proposal doesn't seem to consider that perhaps the Cargo folks had a reason to make their dependency resolution scheme complicated. Again, this smacks of hubris. I'm happy to be persuaded otherwise, and it would really only take a link to a thread in which some VGo proponent thoughtfully addresses Sam's criticism and the "why not copy Cargo?" criticism (and no, the "Cargo's dep resolution scheme is overly complicated" rationale from the proposal doesn't constitute).
    - ljm 8y ago
TheSwordsman 8y ago
The concerns haven't been addressed. Sam's latest comment for context: - https://github.com/golang/go/issues/24301#issuecomment-392549295 https://github.com/golang/go/issues/24301#issuecomment-39254...
nicpottier 8y ago
They haven't been addressed, but then again they exist in `dep` as well and most other package managers, just in different forms. Russ Cox had a good talk about this which is worth a watch: https://www.youtube.com/watch?v=F8nrpe0XWRg&feature=youtu.be&t=25m34s https://www.youtube.com/watch?v=F8nrpe0XWRg&feature=youtu.be...
- Groxx 8y ago
  >They haven't been addressed, but then again they exist in `dep` as well and most other package managers, just in different forms. The whole premise of the blog post is that vgo has additional failure modes that other ones do not. Right at the top, the first item in the list of "what this post covers" is: >MVS has all the same failure modes, plus more, minus pathological SAT.
skybrian 8y ago
It's worth pointing out that when working in a monorepo, there are no version numbers and no package system to tell you that upstream broke you, or you broke something downstream. So how do you find bugs? You run tests. The same can be true if you're working with package management. Most bugs aren't found by the dependency tracking system anyway. Having good tests will tell you about incompatibilities that upstream didn't even know about. If you're not using exactly the same versions that the maintainer used, you need to run tests. Maybe people currently don't run tests often enough? But this suggests a different approach to software robustness than comparing version numbers.
- lobster_johnson 8y ago
  Testing and package management aren't mutually exclusive. If you're in a monorepo, all your code evolves in lockstep. A core tenet of versioned package management is to get reproducible builds that only need to break once you choose to evolve forward in time (i.e. upgrade). Historically, most languages (C, C++, pre-Maven Java) haven't had package management at all, and so dependencies have typically been managed by vendoring the code (or JAR files). JAR files worked okay, but vendoring incurs maintenance overhead that isn't acceptable in today's environment. git submodules are theoretically a solution, but also high-maintenance.
  - skybrian 8y ago
    Yes, you are right. And I believe vgo is supposed to guarantee reproducible builds just like other package systems. However, when you upgrade a dependency, it's still possible that you're using a particular combination of library versions that have never been tested before. Some incompatibilities can be prevented by looking at version constraints. But you're not left with no error detection if the package system fails to detect an incompatibility; in the end, what matters is that the code compiles and the tests pass.
    - oceanswave 8y ago
      This methodology places way too much emphasis on the breadth of the tests into a test centric view— say you had a dep that had an SSL vulnerability - most of the time you’re not going to be checking for this type of thing at the level of your app, and doing so - but you bet you need to ensure that you are using the version of the dep that has the vulnerability fixed

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

markrages 8y ago

This article is about the Go programming language (and environment).

jrs95 8y ago

> Now what? I keep using dep for as long as it's reasonable for me to do so, because I don't like MVS and I don't like how MVS has been basically forced upon us.

wuliwong 8y ago
What is MVS?
- kasey_junk 8y ago
  The new dependency resolution algo in vgo.
- mali9 8y ago
  Minimal Version Selection https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs
throwaway243425 8y ago
Soon many packages will start having the module system that comes with vgo and just like aliases, community means nothing to Go.
niftich 8y ago
Out of curiosity, what are some of the reasons why you dislike MVS?

dstroot 8y ago

I first used $GOPATH and “go get”. Was amazed at how simple and easy it was and it “just worked”. Then you start to run into issues... so I started using Glide. Which worked pretty darn well. Then I switched to Dep because “it was the future” and it didn’t cause me to break out in hives. Now vgo... but Dep works for me so at the moment I don’t plan to switch until vgo is good and baked. Given Boyer’s concerns I hope he maintains Dep for a while as vgo is polished. Too bad this was not part of the vision at the start. Not sure where JS would be without NPM, etc.

kodablah 8y ago
> Not sure where JS would be without NPM Where it was before NPM, i.e. where Go is today. No real versioning or discovery (granted Go has qualified URLs for discovery).

anonfunction 8y ago

I really do not like the “semver-like” versioning string requirement. My packages are already tagged with valid semver releases and now I need to change them by adding a “v” prefix. If you don’t know what I’m talking about vgo requires the release to be tagged like “v1.0.3” which is not standard semver.

cesarb 8y ago
> vgo requires the release to be tagged like “v1.0.3” which is not standard semver Are you talking about git tags? Tagging a release with a "v" followed by the version number has been done since the very first git repository. I don't think semver has any official standard; the closest I can find is https://semver.org/spec/v1.0.0.html https://semver.org/spec/v1.0.0.html, which does say "When tagging releases in a version control system, the tag for a version MUST be “vX.Y.Z” e.g. “v3.1.0”."
- anonfunction 8y ago
  Yes I am talking about git tags. I purposely followed semver 2.0.0 which doesn't mention anything about a "v" prefix. Thanks for finding an old mention of version control tagging! At the end of the day it's not a big deal. I will just duplicate the tags so it won't break any dep configurations.
lobster_johnson 8y ago
Every Go project I've used uses git tags prefixed with "v", e.g. v1.0.3. https://github.com/gogo/protobuf https://github.com/gogo/protobuf https://github.com/olivere/elastic https://github.com/olivere/elastic https://github.com/golang/protobuf https://github.com/golang/protobuf https://github.com/sanity-io/litter https://github.com/sanity-io/litter
- anonfunction 8y ago
  I've seen a few that used 1.0.3 which is also common among python and other languages. One of the biggest new go projects, istio[1], uses the 1.0.3 style. I'll switch over in the future and keep existing tags for dep users. 1. https://github.com/istio/istio/tags https://github.com/istio/istio/tags

eberkund 8y ago

I wish they had just copied Rust/Cargo. I remember reading a comment on GitHub somewhere from one of the Go maintainers who responded to someone expressing a similar sentiment and his reply was basically that Go is somehow different than every other language and they need to explore and find a unique custom solution for their particular use case. Has it ever been addressed anywhere why the tried and true "list of packages" + "lock file" paradigm is not good enough for Go?

TheSwordsman 8y ago
I wish it was as simple as that. Instead it's that that Russ Cox is fundamentally against SAT solvers, and has opted take this alternative approach instead. I think they would have been better off iterating on the things that have worked for other languages and tools, and arguably a SAT solver is one of them.
lobster_johnson 8y ago
Rust/Cargo had the luxury of being a greenfield project that could adopt semver from the beginning, whereas Go made the mistake of starting out, and then going years, without any official package management solution. As a result, Go has a swathe of applications and libraries that use specific workflows as well as a mélange of community-developed package management tools such as godep, Glide and dep. The semver standard, in particular, has been inconsistently adopted by the Go community. In other words, any new Go tool either has to support/import existing code, or to wipe the slate clean and say that for a package to be importable it has to follow a new spec. dep decided on the former, and my impression is that this has had unfortunate consequences, because that inherits a lot of historical baggage. We've been using dep for a while (having escaped the bugfest that is Glide, which used a very similar approach), and it's pretty evident that the solver is buggy and slow and also complicated enough that fixing issues like [1] can only be done by a select few that already understand the codebase. I'm not in a position to judge what the causes of all of these issues are, though I'd wager they're not entirely unrelated to the inherent complexity of SAT solving. The current dep issue tracker is full [2] of reports mentioning the solver, not to mention that dep currently has problems with known libraries such as the Kubernetes client [3] and Protobuf. (Google-related projects have historically used godep.) Again, possibly related to this specific implementation and not necessarily something that would apply to a hypothetical "Cargo for Go", but I don't know. Any idea how Cargo compares to dep overall? [1] https://github.com/golang/dep/issues/1306 https://github.com/golang/dep/issues/1306 — this one is a nightmare if you work anything related to Kubernetes. [2] https://github.com/golang/dep/issues?q=is%3Aissue+is%3Aopen+solver https://github.com/golang/dep/issues?q=is%3Aissue+is%3Aopen+... [3] https://github.com/golang/dep/issues/1207 https://github.com/golang/dep/issues/1207

gyrgtyn 8y ago

As someone who just recently started using go, this seems really dumb.

reificator 8y ago
The churn in dependency management is one of the worst issues with go. The other is not having a canonical GUI option, instead mostly just bindings to other toolkits with varying completeness and quality. That said, I think it's worth sticking with go for the quality of the language itself. If you don't need a GUI (or plan to use a web GUI) it's a really nice balance of design decisions that let you actually get things done.

fortyseven 8y ago

Now... we bring him the baby so that he might rule this world again!

throwaway243425 8y ago

To an outsider this may sound like there is some sort of process that resulted in this solution, there actually isn't any. The committee is nothing more than a simple bureaucracy to the point that it is almost a joke how Russ makes a proposal, community is against it, then it gets accepted by the Committee. It is all just a funny joke.

jimmy1 8y ago
> To an outsider > Russ > throwaway Something tells me you aren't really an outsider. Anyways, > community is against it, then it gets accepted by the Committee Is this your primary gripe? Because this has happened pretty consistently in the history of almost all open source languages. Think of how many JSRs were hotly contested, only to be accepted. Open source does not mean democratic development, and thankfully so because you might have ended up with this https://i.redd.it/7t1p88ct13ez.jpg https://i.redd.it/7t1p88ct13ez.jpg
- dikaiosune 8y ago
  FWIW, I read "To an outsider..." to mean "if you are reading this on HN and aren't involved in the community, this might seem like" as opposed to "I am pretending to be an outsider, let me tell you what about my perspective."
Spiritus 8y ago
Who says the community is against it? I happen to like it.
- kaeshiwaza 8y ago
  Looking at the thumbs up and the comments, the community seems very favorable at vgo. https://github.com/golang/go/issues/24301 https://github.com/golang/go/issues/24301 edit: and everybody was not agree at the time of Dep launch as it was not simple as Go use to be.
eknkc 8y ago
Community is not against it as far as I can see. A minority of vocal people are. There are a lot of people who liked the idea (including me) and those do not write 30 page blog posts because there is no need.

matte_black 8y ago

What does this mean for someone who is starting out with Go?

lobster_johnson 8y ago
Nothing yet. The new tools should land in 1.11, but will be an experimental opt-in, with the aim of full support in 1.12.
mahmoudhossam 8y ago
Use dep for now, it's the closest thing to a stable package manager for go. And you'll also have the smoothest path to a vgo migration in the future.
eosrei 8y ago
Nothing. Use dep now. In fact, since you are just starting out, see how far you can get using only the standard library. Later, there will be a seamless upgrade to vgo.
- marcus_holmes 8y ago
  Seconded. Unlike Node/Ruby/most other modern languages, Go devs actively avoid including dependencies if at all possible. And contrary to rumour, this is not because Go's dependency management sucks. It's more about the pursuit of simplicity, and avoidance of magic. You can write pretty much anything using just the standard library (and some of the official packages, like the crypto ones). As the parent said, it's good practice to go as far as possible with just the stdlib.
  - oceanswave 8y ago
    So go is about recreating the wheel, over and over again
    - sethammons 8y ago
      Not really. Generally, the wheel you need and the wheel I need are a bit different. Instead of using some bloated "all-wheel," developers choose their custom wheel. Simple example, SyncMap. This is a general purpose all-wheel, and as such, due to Go's type system, you have to use runtime type assertions against it. If I need a lockable map, I just make one and it is of the type I need, say map[string]*Foo. I just wrap it in a struct with a lock and I'm done. For more complicated things, most everyone will pull in a package. I'm not going to waste some time making a Redis or Kafka package. For a web server, I may pull in a different muxer, but only if needed.

Avi-D-coder 8y ago

How does Haskell's cabal compare to vgo?

danharaj 8y ago
Cabal uses a SAT solver. It's in the middle of a beta for replacing it's global package management with per-project package management by default (so-called new-style builds). There were some warts in the past when it couldn't manage different versions of the same package, I think because of a ghc issue but that is in the past. Most industrial users use stack or nix on top which reduce the use of Cabal's version solver.

ospider 8y ago

Besides the technical details between vgo and dep. The go team just announced and accepted its own proposal, completely ignoring the community's solutions, dep was even called the official experiment, which is sad.

rahenri 8y ago

There is a lot of criticism on the proposal with a lot of good reason. But, I'm honestly very excited about the deprecation of GOPATH, that was one of the most annoying features of go for me.