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

An Analysis of vgo

sdboyer.io

Post reply on HN
Print view View original

41–50 of 69 posts

Re: An Analysis of vgo

#41

Post by zaphar »

TheDong wrote: post #19
enqk wrote: post #5

Earlier quoted context omitted.

On the other hand, git became successful by being fast and by not solving certain of the hard theoretical problems that specialists were obsessed with solving. It's hard to know before hand what the healthy compromise might be.

This rings as a wrong interpretation of history. When git became successful, there were scant few other options with a comparable feature-set regardless of speed. Its distributed nature, ability to easily merge and rebase sets of changes, etc, were all wonderful solutions to real problems. I'm unconvinced that its success was because it solved fewer problems than the state of the art, but rather that it solved more.…

Mercurial was pretty close to contemporaneus. And when git was first launched it was extremely bare bones and even more incredibly hard to use than it is now. Darcs, Monotone, and Arch were slower and I think predated git. Darcs in particular blew the doors off of git as far as ease of use given the problem domain.

Git won almost entirely due to two factors.

1. The linux kernel used it so that brought some prestige.

2. Github made git hosting easy and free for a lot of people and had the cultural cachet to drive adoption.

Git has a very solid underpinning. But it's user interface and lack of guard rails has always made it painful. People endure the pain because if they don't they won't be able to use the tool that their industry has chosen. But some of us wish a different choice had been made in the dvcs arena.

Re: An Analysis of vgo

#42

Post by nicpottier »

Though this is well written and I'm sure Sam is trying to set a tone of respect and appreciation of what is good in vgo so as to start on the right foot, he is also "burying the lead" in that he never gets to the point.

I think Russ did an unusually good job of explaining the ideas around vgo, grounded by using real world examples. He set a high bar there, but hopefully Sam adopts some of the same methods of very concrete examples to explain his criticisms.

As it stands this is an interesting piece of reading but is too high level and abstract in its criticism to be effective. Looking forward to future installments that hopefully that will make Sam's criticisms clear.

From what I can tell one piece of criticism is the inability of vgo to define incompatibilities. That is that if you know these versions won't work, you can say never allow that version in your dependency graph. I'd love to hear more examples of this in the real world. Since vgo dependencies are basically always "pinned" this seems like that not big a deal to me, but maybe I'm missing something. Perhaps this is something that occurs with having two of your dependencies having different dependencies on a third package and one of those works only with dep3@v1.2 and the other only works with dep3@v1.3 or somesuch.

Maybe there are ways around that or maybe that's not the actual problem (again, hope Sam explains more in the future). I think there is a really interesting element to MSV that will actually drive Go culture though (and I'm a big believer in the importance of the culture of a language) which I think may minimize the problems that Sam is talking about and for the betterment of the community.

As others have noted, I hope that Sam comes out with the rest of this series quickly so that the go community can commit do a direction sooner rather than later and move on to actually building this new ecosystem.

Re: An Analysis of vgo

#43

Post by RVuRnvbM2e »

TheDong wrote: post #19
enqk wrote: post #5

Earlier quoted context omitted.

On the other hand, git became successful by being fast and by not solving certain of the hard theoretical problems that specialists were obsessed with solving. It's hard to know before hand what the healthy compromise might be.

This rings as a wrong interpretation of history. When git became successful, there were scant few other options with a comparable feature-set regardless of speed. Its distributed nature, ability to easily merge and rebase sets of changes, etc, were all wonderful solutions to real problems. I'm unconvinced that its success was because it solved fewer problems than the state of the art, but rather that it solved more.…

> This is a stark contrast to vgo which is intentionally solving fewer problems than other modern dependency management tools.

The thing is, modern dependency management tools for development suck. They are complex and slow and terribly unreliable.

A fresh, unconventional approach is needed, and vgo may be it.

Re: An Analysis of vgo

#44

Post by sagichmal »

reificator wrote: post #36
sagichmal wrote: post #32

Earlier quoted context omitted.

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.

> 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…

> 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.

Re: An Analysis of vgo

#45

Post by weberc2 »

paulsutter wrote: post #24
lobster_johnson wrote: post #15

Earlier quoted context omitted.

git may have become successful, but that doesn't mean it's right. I'd argue that most developers still don't really understand git. I know seasoned, senior developers who struggle when git gets into an unfamiliar state, or who are completely mystified as to how it actually works. And don't forget that git spent years improving its initially horrific UI to make it easier and more palatable to people who aren't kernel…

Git isn’t ideal, but it is right. It’s right because it’s solving source code control for a huge percentage of software projects. Something better could be even more right, and adoption would be the measure. > git may have become successful, but that doesn't mean it's right.

I get the general thrust, but this argument can be used for any incumbent. `git` is popular because _github_ works. Had github's founders stumbled upon Mercurial first, we would all be in a moderately better place. But yes, at the end of the day, Git Is Good Enough (TM).

Re: An Analysis of vgo

#46

Post by 4ad »

nicpottier wrote: post #42

Though this is well written and I'm sure Sam is trying to set a tone of respect and appreciation of what is good in vgo so as to start on the right foot, he is also "burying the lead" in that he never gets to the point. I think Russ did an unusually good job of explaining the ideas around vgo, grounded by using real world examples. He set a high bar there, but hopefully Sam adopts some of the same methods of very con…

> he is also "burying the lead"

The expression is burying the lede, not lead.

Re: An Analysis of vgo

#47

Post by reificator »

sagichmal wrote: post #44
reificator wrote: post #36

Earlier quoted context omitted.

> 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…

> 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.

> 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.

Re: An Analysis of vgo

#48

Post by nicpottier »

4ad wrote: post #46
nicpottier wrote: post #42

Though this is well written and I'm sure Sam is trying to set a tone of respect and appreciation of what is good in vgo so as to start on the right foot, he is also "burying the lead" in that he never gets to the point. I think Russ did an unusually good job of explaining the ideas around vgo, grounded by using real world examples. He set a high bar there, but hopefully Sam adopts some of the same methods of very con…

> he is also "burying the lead" The expression is burying the lede, not lead.

Hah, thanks, learn something every day! https://www.merriam-webster.com/words-at-play/bury-the-lede-...

Re: An Analysis of vgo

#49

Post by DannyBee »

nicpottier wrote: post #42

Though this is well written and I'm sure Sam is trying to set a tone of respect and appreciation of what is good in vgo so as to start on the right foot, he is also "burying the lead" in that he never gets to the point. I think Russ did an unusually good job of explaining the ideas around vgo, grounded by using real world examples. He set a high bar there, but hopefully Sam adopts some of the same methods of very con…

One interesting thing the article doesn't seem to cover at all is what it takes to push a community in a particular direction.

It sort of asserts various things work or don't in the real world, which is strange to me, as a lot of that behavior depends on what incentives/etc exist and these are very emergent systems that change.

It doesn't seem to consider very heavily whether vgo will be successful in changing the way people operate at all (despite this kind of thing happening all the time), and instead asserts based on the current state of the world , and random assertions about how people work, what the future will be, and asserts vgo won't change that in various ways. It's all very minimal actual explanation wrapped in a lot of language. It's also all random opinion, simply stated in a matter of fact way, with no real data cited anywhere to back it up. The only thing coming close to presenting a data backed argument then says "we'll look at this in a future part of the series".

Re: An Analysis of vgo

#50

Post by ianbicking »

nicpottier wrote: post #42

Though this is well written and I'm sure Sam is trying to set a tone of respect and appreciation of what is good in vgo so as to start on the right foot, he is also "burying the lead" in that he never gets to the point. I think Russ did an unusually good job of explaining the ideas around vgo, grounded by using real world examples. He set a high bar there, but hopefully Sam adopts some of the same methods of very con…

Back when I used to manage libraries that were required and required other libraries, I only ever really "knew" when particular version of a dependency didn't work. Do you ever really know that something works? No, there may always be a bug, some way things interact poorly. From a maintainer's point of view there are things like:

1. Probably this dependency version works, because I have no reason to believe otherwise

2. This dependency existed at the time I released a version of my library

3. This dependency existed, and I used it during testing and development

4. This dependency is co-maintained, so future versions of the dependency are likely to be compatible per semantic versioning

5. My library means nothing to this dependency, and they may or may not break it based on their whims

6. We don't really talk, but if there's an issue whoever you tell first may well fix it

7. I will release dot-releases to make sure future versions of the dependency are supported

8. I have specifically confirmed certain versions of my library and the dependency are incompatible

Most of these assertions are social and incomplete. Assuming a version, once released, is never changed or retracted, then one of the few firm guarantees you can declare is incompatibility. Declaring compatibility doesn't make it so, it only indicates a desire (and it's not even clear whose desire).

On top of that, compatibility should really be more like metadata, not included in the package. Compatibility and incompatibility is a discovery process (along with security).

In practice it's fine though, because it's ultimately the integrator (the person making some actual application) who has the responsibility to ensure everything works together.

Post reply on HN