Hacker News new | ask | show | jobs
by nicpottier 2957 days ago
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.

4 comments

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

> he is also "burying the lead" in that he never gets to the point.

He does say this is the first of a series of articles, so I think this is an uncharitable criticism. Dependency management is a very big topic and talking about it with sophistication — which you need to do to actually solve the problem well — takes a lot of words.

> I think Russ did an unusually good job of explaining the ideas around vgo, grounded by using real world examples.

Sure, it's always easier to understand something when you talk about it in terms of small carefully-crafted examples. But with something like the emergent effects of dependency management tool UX choices on the health of a software ecosystem, you lose a lot when you limit your discussion to "here's what the algorithm does on these three toy packages".

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.

> he is also "burying the lead"

The expression is burying the lede, not lead.