Hacker News Reader

Comment by calcifer | Hacker News Reader

From the "Avoiding Singleton Problems" section:

> Another problem would be if there were two HTTP stacks in the program. Clearly only one HTTP stack can listen on port 80; we wouldn't want half the program registering handlers that will not be used. Go developers are already running into problems like this due to vendoring inside vendored packages.

This is only a problem if you allow nested vendor/ directories, which "dep" (you know, the "official experiment" that suddenly got discarded to the surprise of its developers) doesn't have because it recurses through the entire dependency tree and reduces it to a single vendor/, just like many (most?) other languages.

The whole post reads like the author thinks Go has a very unique dependency management problem that no other language ever had which somehow necessitates a completely unorthodox solution. Three blog posts into "vgo", I still don't see why...

View on HN

Go doesn't have a unique dependency management problem. This problem is shared by many other languages that have all solved it poorly. I haven't written much Go and am not a big fan of the language, but I am watching this discussion eagerly because a successful solution in Go will be an example for other languages to follow.

Curious about what languages you think solved it poorly, and why.

I guess now that I think of it, all the solutions I've seen break down into two techniques.

First, loading different versions of the library under the same name to provide to different parts of your code. This has different risks depending on how and when symbols are looked up or linked. In some languages you can end up with the two versions accidentally calling into each other or using each other's symbols. In other languages you run into the "expected Foo but got Foo" type errors mentioned by munificent. That's what happens when you use classloader tricks as a half-assed way of isolating "components" in Java.

Second, loading different versions of the library under different names. This requires hacking the compiled code or the source code; convenience and reliability will depend on the quality of the tools you're working with. Sophistication ranges from using sed to munge source code to using tools like objcopy that can read and rewrite compiled artifacts. Java "shading" (not "shadowing" as I said earlier) relies on rewriting class files.

A solution arguably has been found and it's cargo. I still don't get why it wouldn't work with go. My understanding is that the dep tool worked (works?) very similarly in principle.

Context is important here. Just one or two sections up it describes why having two different major versions of a package in a program can be a good thing (which is something dep don't provide, as far as I know).

I understand, but the implication is that somehow all the other languages out there with collectively decades of experience in dependency management somehow all made the wrong tradeoff and Go is rightfully correcting their mistake. Basically, I think these blog posts should be 80% justification and 20% explanation for vgo, instead of vice versa.

In the first example, it shows how a other package managers may handle it (multiverse, clone arguments). What rsc is suggesting is that we learn from our past.

Can you expand on "you know, the "official experiment" that suddenly got discarded to the surprise of its developers" and where that announcement was made?

From sdboyer, developer of dep: https://sdboyer.io/blog/vgo-and-dep/

"vgo, as currently conceived, is a near-complete departure from dep. It was created largely in isolation from the community’s work on dep, to the point where not only is there no shared code and at best moderate conceptual overlap, but a considerable amount of the insight and experience gleaned from dep as the “official experiment” is just discarded."

"Now, maybe the benefits of vgo’s model will be so profound that these losses, and the difficulties of more experimental churn will be justified. i can’t prove that won’t be the case. And, if it does turn out that way, it would be stupefyingly hypocritical of me to protest, having spent the last year and a half asking the authors of other Go package management tools to gracefully bow out in favor of dep. All i can say for sure is that i’m sorry: to expose the community to yet more churn, and to anyone who feels like i’ve misled them about the process, and especially to dep contributors, who may find this announcement to feel rather like a punch in the gut. For whatever it’s worth, none of that was ever my intent, and this is not the path i believed we would be walking."

Reply on news.ycombinator.com