Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The vgo proposal is accepted. Now what?

research.swtch.com

Post reply on HN
Print view View original

11–20 of 138 posts

Re: The vgo proposal is accepted. Now what?

#11

Post by ovao »

jrs95 wrote: post #9
ovao wrote: post #7

Earlier quoted context omitted.

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.

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.

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.

Re: The vgo proposal is accepted. Now what?

#12

Post by dstroot »

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.

Re: The vgo proposal is accepted. Now what?

#14

Post by kodablah »

dstroot wrote: post #12

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…

> 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).

Re: The vgo proposal is accepted. Now what?

#15

Post by anonfunction »

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.

Re: The vgo proposal is accepted. Now what?

#16

Post by gkya »

ovao wrote: post #11
jrs95 wrote: post #9

Earlier quoted context omitted.

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.

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.

> 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.

Re: The vgo proposal is accepted. Now what?

#17

Post by ljm »

tmpz22 wrote: post #3
adwhit wrote: post #2

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 -…

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.

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.

Re: The vgo proposal is accepted. Now what?

#19

Post by cesarb »

anonfunction wrote: post #15

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.

> 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 version MUST be “vX.Y.Z” e.g. “v3.1.0”."

Re: The vgo proposal is accepted. Now what?

#20

Post by eberkund »

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?
Post reply on HN