3 ms·
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
by dkarl 9y ago
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.
- kenhwang 9y agoCurious about what languages you think solved it poorly, and why.
- dkarl 9y agoI 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.
- baq 9y agoA 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.