1. 31

  2. 3

    If the 2 sides spent time talk past one another, it should have been made clear to provide a proposal by X date. It seems like the process was unclear or failed on that point (deliverables, before moving onto step Y).

    1. 7

      “The single biggest problem in communication is the illusion that it has taken place.”

      (attributed to various folks in one form or another)

      EDIT: Just to be super clear: this wasn’t intended as a dig. I myself suffer from this problem continuously. It’s a constant struggle to communicate effectively.

    2. 3

      Based on reading all this stuff and using many package managers, including dep but not yet including vgo, it seems like there are two different things happening here.

      First, major miscommunication between Go core and the dep committee. Like, disastrously major. Enough said.

      Second, crucially different assumptions in the design. The dep folks seem to be coming from a concentrated study of existing reality, inelegant and unpleasant though it may be, and bringing in lessons learned in other communities. Russ seems to be coming from a position of deciding the way things “should” be and assuming the community will act accordingly. Which is totally the Go way of doing things!

      If you’ve maintained a Rails project with 30 gems that work OK but haven’t had a maintainer for years, the assumption of a singular, very active library maintainer whose library just gets jettisoned by everyone if they misbehave doesn’t ring true. But the Go community, so far, seems different, so I’m willing to see how the experiment comes out over the next 10 years.

      1. 2

        It seems to me it is dep that is trying to be elegant, enforcing single major version constraint. Real world is inelegant so vgo considers multiple major versions support non-negotiable.

        1. 1

          That’s a good point…they’ve both tried to accommodate some real-world problems, while dismissing others. The vgo approach does seem more Go-y (Goful? Goesque?). The parallel with the Go regex library makes sense (can’t handle some languages that Perl regexes can, but never goes exponential, either).

      2. 3

        It seems to me Minimal Version Selection disagreement is secondary and the primary disagreement is that “Dep does not support using multiple major versions of a program in a single build”, which is a showstopper for Russ. Peter says “Calling it … a showstopper, is a significant overstatement”. But I don’t see why it can’t be a showstopper for Russ.

        As a Rust user enjoying multiple major versions support everyday, I side with Russ on this matter.

        1. 0

          I’m very happy with vgo after spending years frustrated with buggy, partially-broken third party tools: first glide (no way to upgrade just one package, randomly fails operations) then dep (100+ comment issue on not supporting private repos).

          This comment from HN sums up my feelings on this post:

          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.

          1. 14

            This is an extremely bad faith interpretation of events. Your words have an actual negative effect on people who have tried for a very long time to do the best they could to improve a bad situation.

            1. 9

              had to learn the hard way what the D in BDFL means

              Except Go is not (or at least doesn’t market itself as) BDFL-led. The core team has been talking about building and empowering the community for years (at least since Gophercon 2015, with Russ’ talk).

              When did the “dep committee” become the gatekeepers of Go dependency discussions and solutions?

              They were put in place by / with the blessing of the Go core team, so some authority on the subject was certainly implied.

              Go is better off with Russ’s module work

              You can certainly prefer Russ’s technical solution, that’s only part of the thing being discussed (and I think it’s fair to say it’s not the heart of the matter).

              The rest of your quotes are just mean.

              1. -4

                People don’t seem to realize that Go is not driven by the community, it’s driven by Google. It’s clear to me that Google doesn’t trust its programmers to use any advanced features, the code is formatted the same (again, don’t trust the programmer), everything is kept in one single repo and there is no versioning [1]. In my opinion, Google only released Go to convince a ton of programmers it’s the New Hotness (TM), get everybody using it so they can cut down on training costs and disappointed engineers looking for resume-worthy tech to work on [2].

                So, any proposal for Go that violates Google’s work flow will be rejected [3]. Any proposal that is neutral or even helps Google, will probably be accepted. As far as I’m concerned, Go is a Google-proprietary language to solves problems Google has. The fact that it is available for others to use is intentional on Googles part, but in no way is it “communitty driven.”

                [1] Because if you change the signature of a function, it is up to you to change all the call sites at the same time. Because the code is all formatted the same way, there does exist tooling to do this. At Google. Probably no where else.

                [2] “What do you mean we got to use this proprietary crap language? I can’t put this on my resume! My skills will stagnate here! I hate you, Google!”

                [3] Stonewalled. Politely told no.. But ultimately, it will be rejected.

                1. 4

                  To be fair, don’t trust the programmer, is a pretty good rule to follow when you design a language or API. Not because programmers are bad or incompetent but because they are human and thus predisposed to make mistakes over time.

              2. 5

                hrm, I actually want to push back against this quite strongly. any BDFL making decisions in the absence of community input will quickly find themselves the BDFL of a project that has no users, or at least one that often makes poor technical choices. Also, framing this disagreement as a personal one where prestige and reputation are at stake rather than as a technical one is a characterization that nobody other than the involved parties can make, certainly not people uninvolved in the project at all. In particular, making character judgements about people you don’t know based on technical blog posts is something I expect from the orange website, but I’d like to think the community here is a bit better.

                and as far as that technical disagreement goes, I’ve read through rsc’s rationale and I’m not any more convinced than I was in the beginning that jettisoning a well known package management path (SAT-solver) in favor of a bespoke solution is the correct decision. It is definitely the Golang thing to do, but I don’t know if it’s the best. Time will tell.