[rosshemsley]

Anyone have a bullet-pointed summary of the "crux" of what the author dislikes about MVS?

I find MVS to be a very natural and simple solution to versioning - I feel like it's much closer to how people actually manage their dependencies in practice.

After an admittedly low-effort skim of this article, most of the arguments seem to be that the author doesn't think it "feels right". Is there something more concrete hidden in here?

[cdoxsey]

Its a long post, but I don't think he actually gives the reasons, rather he intends to write several additional posts that will.

[ngrilly]

Honestly, Russ Cox published his first post about vgo on February 20 (https://research.swtch.com/vgo). It's been almost 3 months then. It's not fair to ask the community to wait any longer. If Sam Boyer has good reasons to oppose vgo, then he should publish them now.

[sagichmal]

Russ waited over a year and a half before engaging meaningfully with the community on package management, and waited another nine months before coming up with this greenfield proposal. There's no reason to rush things now.

[reificator]

> There's no reason to rush things now.

Golang is hurting right now because of this issue. In fact this and the lack of a canonical GUI approach are the only two caveats I have when suggesting the use of Go.

I'm not saying to rush, but the constant churn in this space needs to end as soon as it can. For a language with as much of a focus on simplicity and stability as Go, it's embarrassing that this has been an issue for so long.

I have been using Go professionally[0] starting sometime between 1.1 and 1.4 and in that time I have something like 4-5 different ways of handling dependencies in my repositories based on when those projects were started and/or last overhauled. Each time I changed my approach I was following the current best practices, or so I believed. It's madness, and it has to end sometime.

[0]: Started playing with it in 2009, in fun projects I'll use whatever works and/or is fun and/or gets the job done soonest. In professional projects I'm much slower to adopt new tools.

[sagichmal]

> Golang is hurting right now because of this issue.

Go was hurting _three years ago_ because of this issue. The pain was tractable and critical. The community made a thorough and good-faith attempt to end the churn with `dep` -- which was summarily dismissed, ignored in part and whole.

I don't see why `vgo` should get the fast track now, when the core team has been dragging their feet on the issue for years.

[reificator]

> The community made a thorough and good-faith attempt to end the churn with `dep` -- which was summarily dismissed, ignored in part and whole.

I've used `dep` on a few projects and I don't mind it. If that's what we use that's fine with me.

> I don't see why `vgo` should get the fast track now, when the core team has been dragging their feet on the issue for years.

I think you misunderstand my point. I'm not throwing my weight behind `vgo`, I'm throwing my weight behind making a long term decision of any kind.

I get that it's important to take your time and get things right. That way you can avoid starting down one path and wasting everyone's time, then switching and declaring that everyone follow you down this one, and so on, and so on...

Oh wait - that happened anyway.

[ngrilly]

> There's no reason to rush things now.

I disagree. I want things to move forward as soon as possible. I've been waiting so long for a dependency management solution and for GOPATH deprecation!

Russ came with his "greenfield" proposal because he was not convinced that dep could become the long term solution to dependency management in Go.

Sam and the whole dep team have been working on package management for more than a year now. If they see important issues with vgo, I think they should be able to explain them succinctly in a post, at least to convince other gophers to hold on.