7 ms·

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 w

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 is throwing at Russ? When did the "dep committee" become the gatekeepers of Go dependency discussions and solutions? Looks like a self-elected shadow government, except it didn't have a "commit bit". Someone should have burst their balloon earlier, that is the only fault here. Russ, you are at fault for leading these people on. Go is better off with Russ's module work and I personally don't care if Sam and Peter are disgruntled.

zeeboo 8y ago
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.
- cweagans 8y ago
  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.
  - Athas 8y ago
    Why do you think vgo wasn't built on the nontechnical research carried out by dep? In fact, that's normally what I would assume would be the purpose of something branded an "official experiment" - the code will for certain be thrown away eventually, but the experiences gained will be used to create the actual final product.
  - geodel 8y ago
    > without the input of an entire committee of smart, reasonable people who have literally spent years diving into this specific domain. If that is the case why the solution wasn't developed already outside of Go team's ambit. After all Go team said multiple times they don't need module system as Google does not use it.
    - cweagans 8y ago
      A solution was in progress before Russ preempted it with his own thing: dep.
  - pa7ch 8y ago
    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.
    - kaeshiwaza 8y ago
      I have exactly the same feeling. And remember at the time of the start of Dep that there was no consensus and a big hope that the final integrated solution will be more Goish than Glide. Very surprised by the begin of Dep. I don't believe that rsc and the go team didn't know since the begin that it will not fit sooner or later...
  - DannyBee 8y ago
    "specially 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." Even this very article contradicts your assertion about how it was done.
  - mseepgood 8y ago
    > for instance, user research "If I had asked people what they wanted, they would have said faster horses." (or yet another Bundler/npm/Cargo clone.)
- munificent 8y ago
  > 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.
  - zeeboo 8y ago
    I think there's empirical evidence that the SAT-solver approach is not necessary. I have done an analysis on as many Gopkg.{lock,toml} files as I could find, and in no instances did it ever do any non-trivial version selection: the maximal available version at the time was always selected. Additionally, Russ has stated that ~93% of the top 1000 Go packages in the wild build successfully with no changes. I appreciate that they may be convinced, but I think they need to ask themselves what evidence would change their mind. They have had months coming up on a year to figure this out. https://github.com/zeebo/dep-analysis https://github.com/zeebo/dep-analysis
    - munificent 8y ago
      The more interesting question for me is what evidence would change Russ's mind? The package managers for many successful languages and distributions use lockfiles and constraint solvers. Not only is that empirical evidence that it works technically, it is evidence that it works socially — users are able to understand and work with it, and the package ecosystems for those languages have evolved with those rules in place. Empirical data from Go's own package ecosystem is useful too, but you can only learn so much about package management from a corpus that does not have sophisticated package management. The ecosystem has already learned to work within the restrictions so you'll mostly see packages that confirm the system's own biases. It's like countering passers-by on a bike trail and concluding that the only vehicles users need are bikes. I'm not saying vgo isn't better. But it's an unproven approach where lockfiles and constraint solving are proven, multiple times over. The burden of proof lies on vgo.
nicpottier 8y ago
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 them into the fold with his concerns and direction but they rejected his arguments. That's a fight they should have known they were going to lose. Maintainers / BDFLs get the final say, that's just how it is. Just because there is a large community does not mean they get the final say, just because you put in a lot of work does not mean you get the final say. 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. If you walk into ANY project, public or private, open sourced or closed, and ignore the lead's objections when you go off in a direction they don't agree with, then yes, you are very likely in for some wasted work. That's just how the world works. On another note I hope this is the last we hear about all this, please lets move on.
- stcredzero 8y ago
  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?
  - 8y ago
zellyn 8y ago
I've interacted quite a bit with both Sam and Peter. Your characterization rings completely false. I've never gotten the least hint of the impression they were doing this for self-promotion, but rather to serve to fill an obvious vacuum, perhaps even with a degree of reluctance. I remember being excited when the “dep committee” was formed, because (if I remember correctly) it was set up with the explicit blessing of the Go Team, with a Go Team Member on it to facilitate two-way communication. Your characterizations are both inaccurate and ugly.
- jakevn 8y ago
  The vacuum was filled, thanks to them. Now, an official solution is being presented. Why is there a problem?
- geodel 8y ago
  > Your characterizations are both inaccurate and ugly. I think it may be blunt but seems true to me. Sam calling integration of Go module as sad milestone does seem disgruntled. Dep folks have decided not to take high road which is fine but others are free to call this out.
  - weberc2 8y ago
    I want vgo to succeed and I like most of your contributions, but comments like this and the original post (“Sam just wants to be the big man on campus”) are petty and rude. You’re better than this.
    - geodel 8y ago
      Not that I disagree with you. But this unending whining by dep folks is not helping them endeared to me or so many others.
philip1209 8y ago
"The first principle is that you must not fool yourself and you are the easiest person to fool." - Richard Feynman
jdoliner 8y ago
Yeah it's hard to see how Peter can reconcile: > Russ failed to convince the committee that it was necessary, and we therefore didn’t outright agree to modiying dep to leverage/enforce it. and > The community of contributors to dep were ready, willing, able, and eager to evolve it to satisfy whatever was necessary for go command integration. If you're willing to say: "Sorry BDFL, you didn't convince us this was necessary so we're not doing it." Then you're not willing to do whatever is necessary, BDFL objections are necessities. Peter and Sam just found out what happens when an unstoppable force meets a quite movable object. I agree with the sentiment that Russ's only mistake here was leading them on for too long. I see this as an argument in favor of Linus' style of BDFLing, in this case he would have cussed them out over their design's flaws and told them in no uncertain terms that it was never getting merged and probably that they were stupid. It would have hurt more at the time, but also probably would have saved them a ton of time and, in the long run, might have even hurt less.
brown9-2 8y ago
From this account, it sounds like “the community” was encouraged by “the core team” to work on, meet, discuss an idea and present work to “the core team” that was then ignored. Would you really expect those people to be excited about the outcome? This feels like an overly personal attack.
jasonwatkinspdx 8y ago
This is some pretty ugly character assassination. I haven't seen anything that justifies your characterizations of Sam or Peter.
- deleted 8y ago
  [deleted]

zeeboo 8y ago

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.

cweagans 8y ago
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.
- Athas 8y ago
  Why do you think vgo wasn't built on the nontechnical research carried out by dep? In fact, that's normally what I would assume would be the purpose of something branded an "official experiment" - the code will for certain be thrown away eventually, but the experiences gained will be used to create the actual final product.
- geodel 8y ago
  > without the input of an entire committee of smart, reasonable people who have literally spent years diving into this specific domain. If that is the case why the solution wasn't developed already outside of Go team's ambit. After all Go team said multiple times they don't need module system as Google does not use it.
  - cweagans 8y ago
    A solution was in progress before Russ preempted it with his own thing: dep.
- pa7ch 8y ago
  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.
  - kaeshiwaza 8y ago
    I have exactly the same feeling. And remember at the time of the start of Dep that there was no consensus and a big hope that the final integrated solution will be more Goish than Glide. Very surprised by the begin of Dep. I don't believe that rsc and the go team didn't know since the begin that it will not fit sooner or later...
- DannyBee 8y ago
  "specially 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." Even this very article contradicts your assertion about how it was done.
- mseepgood 8y ago
  > for instance, user research "If I had asked people what they wanted, they would have said faster horses." (or yet another Bundler/npm/Cargo clone.)
munificent 8y ago
> 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.
- zeeboo 8y ago
  I think there's empirical evidence that the SAT-solver approach is not necessary. I have done an analysis on as many Gopkg.{lock,toml} files as I could find, and in no instances did it ever do any non-trivial version selection: the maximal available version at the time was always selected. Additionally, Russ has stated that ~93% of the top 1000 Go packages in the wild build successfully with no changes. I appreciate that they may be convinced, but I think they need to ask themselves what evidence would change their mind. They have had months coming up on a year to figure this out. https://github.com/zeebo/dep-analysis https://github.com/zeebo/dep-analysis
  - munificent 8y ago
    The more interesting question for me is what evidence would change Russ's mind? The package managers for many successful languages and distributions use lockfiles and constraint solvers. Not only is that empirical evidence that it works technically, it is evidence that it works socially — users are able to understand and work with it, and the package ecosystems for those languages have evolved with those rules in place. Empirical data from Go's own package ecosystem is useful too, but you can only learn so much about package management from a corpus that does not have sophisticated package management. The ecosystem has already learned to work within the restrictions so you'll mostly see packages that confirm the system's own biases. It's like countering passers-by on a bike trail and concluding that the only vehicles users need are bikes. I'm not saying vgo isn't better. But it's an unproven approach where lockfiles and constraint solving are proven, multiple times over. The burden of proof lies on vgo.

nicpottier 8y ago

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 them into the fold with his concerns and direction but they rejected his arguments. That's a fight they should have known they were going to lose. Maintainers / BDFLs get the final say, that's just how it is. Just because there is a large community does not mean they get the final say, just because you put in a lot of work does not mean you get the final say. 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. If you walk into ANY project, public or private, open sourced or closed, and ignore the lead's objections when you go off in a direction they don't agree with, then yes, you are very likely in for some wasted work. That's just how the world works. On another note I hope this is the last we hear about all this, please lets move on.

stcredzero 8y ago
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?
- 8y ago

zellyn 8y ago

I've interacted quite a bit with both Sam and Peter. Your characterization rings completely false. I've never gotten the least hint of the impression they were doing this for self-promotion, but rather to serve to fill an obvious vacuum, perhaps even with a degree of reluctance. I remember being excited when the “dep committee” was formed, because (if I remember correctly) it was set up with the explicit blessing of the Go Team, with a Go Team Member on it to facilitate two-way communication. Your characterizations are both inaccurate and ugly.

jakevn 8y ago
The vacuum was filled, thanks to them. Now, an official solution is being presented. Why is there a problem?
geodel 8y ago
> Your characterizations are both inaccurate and ugly. I think it may be blunt but seems true to me. Sam calling integration of Go module as sad milestone does seem disgruntled. Dep folks have decided not to take high road which is fine but others are free to call this out.
- weberc2 8y ago
  I want vgo to succeed and I like most of your contributions, but comments like this and the original post (“Sam just wants to be the big man on campus”) are petty and rude. You’re better than this.
  - geodel 8y ago
    Not that I disagree with you. But this unending whining by dep folks is not helping them endeared to me or so many others.

philip1209 8y ago

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

jdoliner 8y ago

Yeah it's hard to see how Peter can reconcile: > Russ failed to convince the committee that it was necessary, and we therefore didn’t outright agree to modiying dep to leverage/enforce it. and > The community of contributors to dep were ready, willing, able, and eager to evolve it to satisfy whatever was necessary for go command integration. If you're willing to say: "Sorry BDFL, you didn't convince us this was necessary so we're not doing it." Then you're not willing to do whatever is necessary, BDFL objections are necessities. Peter and Sam just found out what happens when an unstoppable force meets a quite movable object. I agree with the sentiment that Russ's only mistake here was leading them on for too long. I see this as an argument in favor of Linus' style of BDFLing, in this case he would have cussed them out over their design's flaws and told them in no uncertain terms that it was never getting merged and probably that they were stupid. It would have hurt more at the time, but also probably would have saved them a ton of time and, in the long run, might have even hurt less.

brown9-2 8y ago

From this account, it sounds like “the community” was encouraged by “the core team” to work on, meet, discuss an idea and present work to “the core team” that was then ignored. Would you really expect those people to be excited about the outcome? This feels like an overly personal attack.

jasonwatkinspdx 8y ago

This is some pretty ugly character assassination. I haven't seen anything that justifies your characterizations of Sam or Peter.

deleted 8y ago
[deleted]