I think I agree.  There are a <i>lot</i> of great things about Go, but (currently) library versioning is not one of them.<p>This doesn&#x27;t contradict much of what the author writes: it really is true that two different versions of one library are actually two different libraries; it really is true that sometimes copy-and-paste is better than generalising (when the cost of being general obscures the meaning of the code itself); it really is true that many libraries should just specify and implement an API, then <i>stop</i>.<p>The issue with libraries in versions in Go could probably be resolved with a more flexible import syntax.  It&#x27;d be sweet to be able to write &#x27;import foo.invalid&#x2F;bar@94d0ef312881e694ded9ff38e33a2c07fb398eb8&#x27; and know that I&#x27;d always either get the exact version that I specified.  It&#x27;d be even cooler to have some way to specify &#x27;I want the latest version of library X which offers the exact API I&#x27;m using&#x27;; in principal this would be possible by calculating some deterministic ordering of the used, exposed API and hashing that, but the details would be tricky (as an example, consider a case where Foo() and Bar() still exist, with the same signatures, but in version 2.0 Bar() can only run properly if Baz() has been called previously—there&#x27;s no way in Go to express that sort of contract to the compiler.