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

11–20 of 139 posts

Re: A response about dep and vgo

#11

Post by stcredzero »

nicpottier wrote: post #6
claydavisss wrote: post #3

Go does not exist to raise the profiles of Sam Boyer and Peter Bourgon. Sam wanted to be a Big Man On Campus in the Go community and had to learn the hard way what the D in BDFL means. The state of dep is the same as it was before - an optional tool you might use or might not. Lots of mentions in Peter's post about things the "dep committee" may or may not have agreed with. Isn't this the same appeal to authority he…

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 their previous decisions that they get it right more than they get it wrong. And that's the very reason there is a community around them at all.

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.

I mean in a way didn't the `dep` folks do exactly the same thing to the `glide` and other existing solutions?

Was the competition squashed?

Re: A response about dep and vgo

#12

Post by c2h5oh »

mbreese wrote: post #10
c2h5oh wrote: post #8

Earlier quoted context omitted.

> I don't see the comparison you're drawing here. I think the similarity is as follows: - there is a desire to fix something that feels like a gap (in this case limited support of constant-time math in standard library) - there is a change proposal coming from the community - there are arguments why it should be included and some discussion if it belongs in a separate library or not - very little or no input from cor…

> which the author admits that it also could be a separate package I don't think the similarity is all that apt. If the core team is the limiting factor in the PR, and if there is a need for this, then why not just make the separate package and be done with it? If it is popular and core wants to merge it in at a different time, then great.

I'm not aware of a way to plug your own crypto to a lot of things that are part of standard library and I'm not aware of a way to plug your own math library to existing crypto.

Re: A response about dep and vgo

#13

Post by nicpottier »

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…

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 using it, it's just that they likely won't find much audience anymore.

Re: A response about dep and vgo

#14

Post by cweagans »

zeeboo wrote: post #4
claydavisss wrote: post #3

Go does not exist to raise the profiles of Sam Boyer and Peter Bourgon. Sam wanted to be a Big Man On Campus in the Go community and had to learn the hard way what the D in BDFL means. The state of dep is the same as it was before - an optional tool you might use or might not. Lots of mentions in Peter's post about things the "dep committee" may or may not have agreed with. Isn't this the same appeal to authority he…

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.

Re: A response about dep and vgo

#15

Post by philip1209 »

claydavisss wrote: post #3

Go does not exist to raise the profiles of Sam Boyer and Peter Bourgon. Sam wanted to be a Big Man On Campus in the Go community and had to learn the hard way what the D in BDFL means. The state of dep is the same as it was before - an optional tool you might use or might not. Lots of mentions in Peter's post about things the "dep committee" may or may not have agreed with. Isn't this the same appeal to authority he…

"The first principle is that you must not fool yourself and you are the easiest person to fool."

- Richard Feynman

Re: A response about dep and vgo

#16

Post by yawboakye »

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…

> 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/companies aren't the same thing. Rails has stayed on the course DHH wants it and hasn't become a mess mainly because DHH remains the BDFL. Go could benefit from similar structure. We're now about to see how Python will do post-Guido.

Re: A response about dep and vgo

#17

Post by Athas »

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 original hunch was to just create a Cargo clone, but after reading Russ Cox's writings, I ended up cloning vgo (with a few simplifications). The implementation was wonderfully simple - everything just fit together. The algorithms are trivial. Operationally, it is easy to understand what the package manager is doing (even more so than for vgo, as vgo has do deal with various Go idiosyncracies and backwards compatibility).

This is in stark contrast to my experience with other package managers, which are temperamental beasts at the best of times. When they work, everything's groovy, but their error modes are easily incomprehensible. I think vgo's approach of restricting expressivity and streamlining processes is the right one. But since nobody has used such a package manager before, it remains to be seen whether it works in practice.

For my own experiment, I do have one data point: I showed people the (rather brief) documentation for my vgo-inspired package manager, and they all felt it was very simple to follow and easy understand what it did, and how.

Re: A response about dep and vgo

#18

Post by munificent »

zeeboo wrote: post #4
claydavisss wrote: post #3

Go does not exist to raise the profiles of Sam Boyer and Peter Bourgon. Sam wanted to be a Big Man On Campus in the Go community and had to learn the hard way what the D in BDFL means. The state of dep is the same as it was before - an optional tool you might use or might not. Lots of mentions in Peter's post about things the "dep committee" may or may not have agreed with. Isn't this the same appeal to authority he…

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.

> dep is, and always was, meant as an experiment to learn from.

My impression is that the dep folks understand that too. The problem is that there is no consensus on what was learned from it.

The dep folks seem to have come away convinced that a SAT-solver approach is the better approach. rsc is clearly convinced of the opposite.

Everyone knows it is ultimately rsc's call, so I don't think talking about the power dynamics is very interesting. What I am more interested in is whether or not it's the right call. A good faith interpretation is that the dep folks aren't sad that their solution lost, it's that what they believe is a better solution lost.

Re: A response about dep and vgo

#19

Post by munificent »

nicpottier wrote: post #13
stcredzero wrote: post #11

Earlier quoted context omitted.

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…

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.

Re: A response about dep and vgo

#20

Post by jessaustin »

c2h5oh wrote: post #12
mbreese wrote: post #10

Earlier quoted context omitted.

> which the author admits that it also could be a separate package I don't think the similarity is all that apt. If the core team is the limiting factor in the PR, and if there is a need for this, then why not just make the separate package and be done with it? If it is popular and core wants to merge it in at a different time, then great.

I'm not aware of a way to plug your own crypto to a lot of things that are part of standard library and I'm not aware of a way to plug your own math library to existing crypto.

Would they take PRs for adding that bit of plugability?
Post reply on HN