What does this mean for someone who is starting out with Go?
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.
The vgo proposal is accepted. Now what?
41–50 of 138 posts
Re: The vgo proposal is accepted. Now what?
#42I 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 pac…
Cox discusses Cargo here, and why he doesn't like it: https://research.swtch.com/vgo-repro
Thanks for posting this. It's much more fleshed out than my hazy memory of a GitHub comment although I still don't agree that all this effort it is worth the "simplification" of not having a lock file.
Re: The vgo proposal is accepted. Now what?
#43I 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.
> 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 , which does say "When tagging releases in a version control system, the tag for a v…
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.
Re: The vgo proposal is accepted. Now what?
#44As someone who just recently started using go, this seems really dumb.
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.
Re: The vgo proposal is accepted. Now what?
#45> 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.
Out of curiosity, what are some of the reasons why you dislike MVS?
Re: The vgo proposal is accepted. Now what?
#46Earlier quoted context omitted.
Cox discusses Cargo here, and why he doesn't like it: https://research.swtch.com/vgo-repro
Thanks for posting this. It's much more fleshed out than my hazy memory of a GitHub comment although I still don't agree that all this effort it is worth the "simplification" of not having a lock file.
The aversion to lockfiles is especially head-scratching given that vgo has a concept of a go.modverify file (separate from the go.mod file) which is used to store version hashes, which is a function that lockfiles usually fulfill. I think the advantage is supposed to be that modverify files are optional, but in practice I don't see why anybody wouldn't want one given that it provides additional security for free.
Re: The vgo proposal is accepted. Now what?
#47For 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 -…
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.
Re: The vgo proposal is accepted. Now what?
#48I 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.
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/olivere/elastic https://github.com/golang/protobuf https://github.com/sanity-io/litter
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.
Re: The vgo proposal is accepted. Now what?
#49I 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 pac…
Cox discusses Cargo here, and why he doesn't like it: https://research.swtch.com/vgo-repro
> The lock file stops future upgrades; once it is written, your build stays on serde 1.0.27 even when 1.0.28 is released.
That means that the only difference is that `vgo` doesn't require lock file for reproducible builds, now the question is what's considered so terrible wrong/dangerous with having a lock file?
Re: The vgo proposal is accepted. Now what?
#50I 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 pac…
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 stand…
Rust was actually around for a good while before Cargo was adopted. (In fact, there were two Cargos, the older of which bore very little resemblance to the Cargo of today.) Of course, Go was stable for longer.
I have to admit I'm a bit confused as to why the dependency resolution algorithm in dep is seen as slow. The speed of the solver is not a problem in any other package management system I've seen. If it is indeed the solver that is the problem (which, again, I'm skeptical of—I'd have to see profiling data to believe it), then it could just come down to optimization differences between rustc and Go 6g/8g.