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

A response about dep and vgo

peter.bourgon.org

Post reply on HN
Print view View original

31–40 of 139 posts

Re: A response about dep and vgo

#31

Post by pa7ch »

cweagans wrote: post #14
zeeboo wrote: post #4

Earlier quoted context omitted.

Additionally, dep is, and always was, meant as an experiment to learn from. Russ gave multiple concrete examples of things he learned from dep. That the dep authors don't take this as a win is telling. Pitching dep as the eventual Go dependency management system and having that not be the case is a problem they invented for themselves.

Throwing away dep means also throwing away the nontechnical groundwork that dep was built on - for instance, user research. Seems pretty careless to me, especially when the alternative is the product of one person's thinking on the subject done in a vacuum without the input of an entire committee of smart, reasonable people who have literally spent years diving into this specific domain.

As a user of dep, glide, godep and avid reader of vgo technical docs I favor vgo's solution. I've been a professional Go developer a few years now.

The notion that this committee speaks for the community seems a weak one to me and I've seen my view mirrored with many of my peers. Its good they attempted such research but it seems like confirmation bias as dep just seemed like a re-write of glide with similar fundamentals and a improved user experience. This appeal to authority by the committee to represent the Go community seems unproductive and unnecessarily divisive/misleading.

I wasn't thrilled when I saw become Sam elected to lead the implementation of the "official experiment" because I wasn't a fan of Glide at all. There was no community vote to oversee this, just one maintainer of one flavor of go pkg management was declared the expert and just re-wrote the existing Glide solution with some lesson's learned. Many other maintainers (experts) of other go pkg management solutions favor vgo.

I've navigated many thorny dependency problems in Go before and never have I ever been convinced that the solution was NP complete version constraints. MVS, good tooling, and finally SIV is enough to make this miles better then previous attempts in this space. Also hooray for GOPATH elimination and project based workflows I've always loved GB by Dave Cheney.

Re: A response about dep and vgo

#32

Post by jsd1982 »

I am not involved in this discussion and have no skin in the game, but from an outsider's perspective it seems that Russ laid out exactly what his concerns were about showstoppers in the dep implementation and those concerns were effectively ignored by the dep committee. What were they expecting to happen after that? Are there some other non-showstopper classified concerns that Russ should make up on the spot and have the dep committee then concentrate on? Why bother after showstoppers are effectively ignored?

It's odd to call out Russ as being disingenuous when he says his concerns were ignored when the dep committee did effectively ignore them. Adding 'effectively' as a qualifier here is somewhat important because it grants that there may have been a deliberation process and that those concerns were not outright dismissed, but the output of a deliberation process must be either in favor or against, and when a concern is deliberated against it is effectively ignored. It has never made sense to me when someone says something along the lines of "we've heard your concerns and have taken them into consideration" and yet did not heed those concerns. Obviously you haven't taken them into consideration and therefore they were effectively ignored.

In this case it seems to me that the burden of proof is on the dep committee to demonstrate that the alleged showstoppers are in fact not stopping the show. You don't get to call a committee meeting, decide to ignore showstoppers by claiming that you don't believe them to be so, and then expect nothing but smooth sailing and cooperation from there on. That makes no sense at all. All this rhetoric about community involvement and "working with us" falls on its face when the implicit terms of engagement are not adhered to.

Re: A response about dep and vgo

#33

Post by pas »

Athas wrote: post #17

Vgo has certainly been a disaster from a communication and community point of view. From an outsider perspective, it looks like a case of maintainer arrogance, and it is hard to believe that Go really has needs that are significantly different from those of e.g. Rust or Java. However, I am also in the unusual position that I had to design and implement a package manager for my own little language recently. My origina…

Could you contrast Cargo and vgo for those who only know the former?

Re: A response about dep and vgo

#34

Post by geodel »

coldtea wrote: post #21

> Community consensus is not always possible. If we don’t get there, then the core Go team decides. Technically I am the final decider but what actually happens is that a bunch of long-time Go team members talk through the decision to get to a consensus among ourselves. Was anything major ever decided based on a "community consensus" in Go? What I've read about, and this case is no exception, is that it's always "a b…

> something like Swift (which despite Apple's thing, goes out of its way to engage the community in feature roadmap)

Good you say that. Not too long ago solutions from swift-server-group is discarded and Apple simply developed swift-nio in-house. I read that server group was blindsided by this development and now more or less disbanded.

Re: A response about dep and vgo

#35

Post by claydavisss »

stcredzero wrote: post #11
nicpottier wrote: post #6

Earlier quoted context omitted.

Ya, I've been following all this drama since the vgo proposal and I also find it somewhat rich. I mean in a way didn't the `dep` folks do exactly the same thing to the `glide` and other existing solutions? At some point you just have to say, hey, you've done good work but I think another approach is better. They did that to glide and Russ did that to them. Note also that he doesn't dispute that Russ tried to bring th…

Ya, I've been following all this drama since the vgo proposal and I also find it somewhat rich...On another note I hope this is the last we hear about all this, please lets move on. I only became aware of this by going to a meetup and seeing a talk. I just want something that's workable and not broken. The reason BDFLs are in the position of making that decision is because they have proven through the accumulation of…

A competition still has to be judged by someone.

The only curious element here is that a (the?) judge also had the winning entry. Russ claims he got buy-in from the other core members and so far no one has contradicted that.

AND...vgo is better than dep. Let's not forget that. Peter can hem and haw about politics but in the end the best horse won.

Go developers want the tools to be as good as possible, 99% of them don't know anyone who contributes to Go by name so this drama is irrelevant to them.

Re: A response about dep and vgo

#36

Post by geodel »

munificent wrote: post #22
yawboakye wrote: post #16

Earlier quoted context omitted.

> This is the same reason given for totalitarian rule generally. The problem is that the dictator has enough power to make a big mistake, committing the entire communitiy's resources. In this position, if you can avoid making a decision, you should. Toyota doesn't simply make such decisions by fiat. Instead, they have a competition. You're comparing very different things. Programming languages and empires/nations/com…

> Rails has stayed on the course DHH wants it and hasn't become a mess mainly because DHH remains the BDFL. \* and DHH happens to make good decisions frequently enough. For every successful BDFL example, history is littered with a hundred dead languages and frameworks designed by a single visionary leader who made the wrong decisions.

So is other way round. Huge numbers of failed design-by-committee or community projects. What you say is truism not particularly insightful or useful.

Re: A response about dep and vgo

#37

Post by claydavisss »

munificent wrote: post #22
yawboakye wrote: post #16

Earlier quoted context omitted.

> This is the same reason given for totalitarian rule generally. The problem is that the dictator has enough power to make a big mistake, committing the entire communitiy's resources. In this position, if you can avoid making a decision, you should. Toyota doesn't simply make such decisions by fiat. Instead, they have a competition. You're comparing very different things. Programming languages and empires/nations/com…

> Rails has stayed on the course DHH wants it and hasn't become a mess mainly because DHH remains the BDFL. \* and DHH happens to make good decisions frequently enough. For every successful BDFL example, history is littered with a hundred dead languages and frameworks designed by a single visionary leader who made the wrong decisions.

The only meaningful example of this I can think of is Larry Wall and Perl...but his mistake was in loosening his grip instead of tightening it. Perl6 started off as a utopia wherein Larry was only considered slightly more powerful than any other contributor. This resulted in a revolving door of clowns taking the reigns and rapidly resigning as Larry looked on.

Fortunately Perl5 still does the Pumpking thing which is effectively a rotating BDFL.

Re: A response about dep and vgo

#38

Post by Athas »

pas wrote: post #33
Athas wrote: post #17

Vgo has certainly been a disaster from a communication and community point of view. From an outsider perspective, it looks like a case of maintainer arrogance, and it is hard to believe that Go really has needs that are significantly different from those of e.g. Rust or Java. However, I am also in the unusual position that I had to design and implement a package manager for my own little language recently. My origina…

Could you contrast Cargo and vgo for those who only know the former?

There are lots of small differences, but I would say there are two major:

* Semantic Import Versioning. A package is identified by some name. I think vgo calls it an "import path", but I have also seen "package path" used. Every version of that package must remain compatible with previous versions. You may not break compatibility (i.e. increment the major semver number) without also renaming the package. There is some syntactic sugar that makes it clear that a version 2 is closely related to the original version 1, but from the point of view of vgo, the two versions are completely distinct packages. This also means a program may depend on several major versions of the same package (which Russ claims is necessary when doing gradual migrations of large programs).

* Minimal Version Selection. In contrast to pretty much every other package manager, vgo tries to install the oldest version of a packages that still satisfies any lower bounds specified anywhere in the dependency tree. Upper bounds are not supported. This both makes the solving algorithm trivial (which probably doesn't matter much), but also gives you reproducible builds without using a lockfile (which is nice), and it gives you a very simple operational model for what the package manager is doing (which I think is crucial).

All package managers suck and all package managers break, but I think when vgo breaks, it will be more obvious what is wrong. Time will tell whether it works in practice!

(And I'm not even a Go programmer; I just like the thoughtfulness that goes into the tooling.)

Re: A response about dep and vgo

#39

Post by zeeboo »

Athas wrote: post #17

Vgo has certainly been a disaster from a communication and community point of view. From an outsider perspective, it looks like a case of maintainer arrogance, and it is hard to believe that Go really has needs that are significantly different from those of e.g. Rust or Java. However, I am also in the unusual position that I had to design and implement a package manager for my own little language recently. My origina…

For what it's worth, I analyzed as many Gopkg.{lock,toml} files I could find in the wild, and found that vgo's algorithms would service all of them. I've done similar analysis for a smaller number of Rust projects using Cargo and had the same findings. I've found it hard to find projects in the wild that actually do any non-trivial version selection. I think this is some good evidence that it will work out in practice.

I think it's less that Go has significantly different needs, but it's more that people overestimate what their actual needs are.

https://github.com/zeebo/dep-analysis

Re: A response about dep and vgo

#40

Post by nicpottier »

munificent wrote: post #19
nicpottier wrote: post #13

Earlier quoted context omitted.

Note that Russ isn't going against the community, he's just going against `dep`. Most of the community, myself included is pretty psyched about go modules. Note also that the risk you propose for bad decisions is mitigated for Open Source. If that decision really turns out to be so bad then it will be forked and a wiser leader(s) will have their shot at decision making. `dep` isn't squashed! You are free to continue…

> If that decision really turns out to be so bad then it will be forked and a wiser leader(s) will have their shot at decision making. No, that doesn't work in practice. The network effects are so insanely dominant in open source projects that forks are nowhere near an efficient market.

Open Source is absolutely chock full of examples of this.
Post reply on HN