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

81–90 of 138 posts

Re: The vgo proposal is accepted. Now what?

#81

Post by steveklabnik »

TheDong wrote: post #74
lobster_johnson wrote: post #53

Earlier quoted context omitted.

Here [1] is the "dep ensure -v" output for a project of mine. It takes almost 12 seconds even when there are no changes to the actual file. I don't know why, or whether it's actually the solver (though the output seems to indicate it). [1] https://gist.github.com/atombender/7c28f1d371fcb139e1e742a08...

As you can see from the output, it is not the solver per-se, but the weird idiosyncrasies of go imports and gopath layout. 'satisfy' and 'select-atom' and such are the solver bit and take about 20ms all together. A SAT solver is 20ms, MVS might be 1ms, but who cares about that difference, right? The top 3 items there are slow because they're: 1. 'source-exists' (~6s) which will do network traffic to find if a project…

Small note, this isn’t something that you’ve said, but since we’re comparing the two in this sub thread overall, Cargo doesn’t require a central registry either. You can pull straight from version control, and the lock file will even keep track of what HEAD is at the time, maintaining reproducibility. Or from the file system. Etc.

Thanks for your comments here, there’s a lot of stuff I wasn’t aware of. Very illuminating.

Re: The vgo proposal is accepted. Now what?

#82

Post by steveklabnik »

jchw wrote: post #68
lobster_johnson wrote: post #36

Earlier quoted context omitted.

The vgo proposal explicitly rejects the "Cargo way" [1]. There's no lock file, and the MVS algorithm requires, as far as I recall, that the go.mod file is modified whenever the developer wants to update to a new version. [1] https://research.swtch.com/vgo-repro

Indeed, but it does seem like a central repository is possibly the direction it's headed, or at least away from source repositories. Personally, I won't be too upset by MVS if it's one of the only deviations, though I do agree with Sam Boyer on the matter, who I actually had the pleasure of speaking with a bit ago.

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

Re: The vgo proposal is accepted. Now what?

#83

Post by kaeshiwaza »

eberkund wrote: post #20

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

I believe this video of rsc explain some concerns about the Cargo's approach and lock file issues https://www.youtube.com/watch?v=F8nrpe0XWRg

Re: The vgo proposal is accepted. Now what?

#84

Post by dikaiosune »

steveklabnik wrote: post #82
jchw wrote: post #68

Earlier quoted context omitted.

Indeed, but it does seem like a central repository is possibly the direction it's headed, or at least away from source repositories. Personally, I won't be too upset by MVS if it's one of the only deviations, though I do agree with Sam Boyer on the matter, who I actually had the pleasure of speaking with a bit ago.

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.

Re: The vgo proposal is accepted. Now what?

#85

Post by kaeshiwaza »

Spiritus wrote: post #80
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.

Who says the community is against it? I happen to like it.

Looking at the thumbs up and the comments, the community seems very favorable at vgo. 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.

Re: The vgo proposal is accepted. Now what?

#86

Post by dikaiosune »

jimmy1 wrote: post #51
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.

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

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

Re: The vgo proposal is accepted. Now what?

#87

Post by stubish »

jrs95 wrote: post #10
tmpz22 wrote: post #3

Earlier quoted context omitted.

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.

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

Re: The vgo proposal is accepted. Now what?

#88

Post by eknkc »

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.

Re: The vgo proposal is accepted. Now what?

#89

Post by Lazare »

lobster_johnson wrote: post #37
eberkund wrote: post #20

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 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. In contrast, minimal version selection prefers the minimum allowed version, which is the exact version requested by some go.mod in the project. That answer does not change as new versions are added.

So with Cargo, you get the exact version you want, ie 1.0.27, and it won't automatically update when a new version is added. And with MVS you get the exact version you want, and it won't automatically update when a new version is added? ...either I'm an idiot, or Cox is using the word "contrast" here to mean "identically".

> Those choices are stable, without a lock file. This is what I mean when I say that vgo's builds are reproducible by default.

Yes, but Cargo uses a lock file by default, meaning that Cargo's builds are reproducible by default too?

I'm open to the idea that vgo/MVS is delivering something amazing here, but every writeup I've seen so far seems to have a miraculous ability to make it sound like a re-branding of the same features every decent package manager has had forever.

Re: The vgo proposal is accepted. Now what?

#90

Post by gkya »

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…

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