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

91–100 of 138 posts

Re: The vgo proposal is accepted. Now what?

#91

Post by Lazare »

lobster_johnson wrote: post #56
_pfxa wrote: post #4

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

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

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

Re: The vgo proposal is accepted. Now what?

#92

Post by jcelerier »

pcx wrote: post #64
pcwalton wrote: post #50

Earlier quoted context omitted.

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

> The speed of the solver is not a problem in any other package management system I've seen This! I've never heard anyone complain about this aspect of a package manager, EVER. vgo seems to be optimizing for a problem no one has.

> The speed of the solver is not a problem in any other package management system I've seen

really ? It has been a large problem in Debian for instance and has enabled a lot of research (https://scholar.google.fr/scholar?q=debian+solver). One of the reason for Fedora's yum -> dnf change was also a change of solver. It's a hard problem that affects a lot of people.

Re: The vgo proposal is accepted. Now what?

#93

Post by kaeshiwaza »

stubish wrote: post #87
jrs95 wrote: post #10

Earlier quoted context omitted.

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

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

Look at 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

Re: The vgo proposal is accepted. Now what?

#94

Post by gkya »

Lazare wrote: post #91
lobster_johnson wrote: post #56

Earlier quoted context omitted.

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

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

Comparison to NPM is also unfair because of the rather unique community around it.

Re: The vgo proposal is accepted. Now what?

#95

Post by greysteil »

dikaiosune wrote: post #84
steveklabnik wrote: post #82

Earlier quoted context omitted.

Cargo doesn’t require a central repository at all, to be clear.

I'd actually be interested to find out how Cargo's performance compares in a situation as TheDong describes where all of the dependencies are being fetched directly from git. Part of me wants to say "well of course Rust's tool is faster" but it would be interesting to see just how much crates.io acts as a performance optimization for running builds, installing deps, etc.

Cargo performs dependency resolution, so fetching from git would (and does) significantly slow it down - it wound need to perform git operations to get the tags for each dependency (quick) and then checkout each tag to look for the subdependencies of that package at that version (slow).

Having a central registry is a must for package managers that perform version resolution and want to do so quickly, as it can serve them all the metadata they need to do that resolution.

Re: The vgo proposal is accepted. Now what?

#96

Post by pcx »

jcelerier wrote: post #92
pcx wrote: post #64

Earlier quoted context omitted.

> The speed of the solver is not a problem in any other package management system I've seen This! I've never heard anyone complain about this aspect of a package manager, EVER. vgo seems to be optimizing for a problem no one has.

> The speed of the solver is not a problem in any other package management system I've seen really ? It has been a large problem in Debian for instance and has enabled a lot of research ( https://scholar.google.fr/scholar?q=debian+solver ). One of the reason for Fedora's yum -> dnf change was also a change of solver. It's a hard problem that affects a lot of people.

To clarify, I(and the OP) was specifically talking about programming language specific package managers.

Re: The vgo proposal is accepted. Now what?

#97

Post by grahamedgecombe »

kibwen wrote: post #63
blaisio wrote: post #62

Earlier quoted context omitted.

It's pretty easy to get a merge conflict from a lock file. If two developers add a dependency and then try to merge their changes together, it can happen easily.

In that scenario, you're going to get a merge conflict anyway in your manifest (e.g. in go.mod).

It's probably easier to manually merge the manifest (as they're much more human-readable) than a lock file though.

Re: The vgo proposal is accepted. Now what?

#98

Post by sagichmal »

eknkc wrote: post #88
throwaway243425 wrote: post #33

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.

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.

The “vocal minority” of the community against vgo as it stands today are also mostly the package management domain experts, who have put in the sweat equity.

Re: The vgo proposal is accepted. Now what?

#99

Post by kaeshiwaza »

sagichmal wrote: post #98
eknkc wrote: post #88

Earlier quoted context omitted.

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.

The “vocal minority” of the community against vgo as it stands today are also mostly the package management domain experts, who have put in the sweat equity.

Parts of the "vocal minority" was also emotional, that doesn't help to focus on the technical args.

Re: The vgo proposal is accepted. Now what?

#100

Post by steveklabnik »

greysteil wrote: post #95
dikaiosune wrote: post #84

Earlier quoted context omitted.

I'd actually be interested to find out how Cargo's performance compares in a situation as TheDong describes where all of the dependencies are being fetched directly from git. Part of me wants to say "well of course Rust's tool is faster" but it would be interesting to see just how much crates.io acts as a performance optimization for running builds, installing deps, etc.

Cargo performs dependency resolution, so fetching from git would (and does) significantly slow it down - it wound need to perform git operations to get the tags for each dependency (quick) and then checkout each tag to look for the subdependencies of that package at that version (slow). Having a central registry is a must for package managers that perform version resolution and want to do so quickly, as it can serve…

My perception is that the initial clone is slow, but that’s it. A detailed comparison with actual numbers would be interesting!

When you depend on a git dep, you can say if you want a particular branch, tag, rev, whatever. So it’s only a clone + checkout. From there you read the Cargo.toml, same as anything else. That’s my understanding anyway, it’s been a while since I poked at the guts.

Post reply on HN