code.google.com is down; all packages hosted there are no longer available with 'go get'

<hr/>**评论：**<br/><br/>chrj: <pre><p>It&#39;s not just down. It has been shut down :)</p></pre>scharty: <pre><p>Is this google killing off golang?</p></pre>maruwan: <pre><p>what? no. code.google.com is going down, as has been announced a long time. Most projects moved to github.</p></pre>elitest: <pre><p>No they just decided that they weren&#39;t in that business, and that GitHub and others do better.</p></pre>anacrolix: <pre><p>Good. Lots of dead repos on there hopefully people will now update their imports.</p></pre>tailot: <pre><p>Alleluja</p></pre>boarhog: <pre><p><a href="https://code.google.com/">From the site itself</a>:</p> <blockquote> <p>In 2016 the service was shut down, see <a href="http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html">this post</a> for more info. Projects hosted on Google Code remain available in the <a href="https://code.google.com/archive">Google Code Archive</a>. </p> </blockquote></pre>heptara: <pre><p><a href="http://imgur.com/OYJJinj">http://imgur.com/OYJJinj</a></p></pre>papageek: <pre><p>I hope gvm (go version manager) updates the protobuf build bits to reflect this.</p></pre>banjochicken: <pre><p>And this is why relying on a version control system as a package manager is a bad idea. </p></pre>Tacticus: <pre><p>No. this is why not updating your repo with a years notice is a failure. </p> <p>at least in this method you don&#39;t lose every package.</p></pre>banjochicken: <pre><p>Also true, but lets deal with reality here rather than the current party line. A dedicated centralised package manager has a notion of longevity about it that the current flavour of repository hosting platform shouldn&#39;t be expected to. An actual package manager where it is explicitly in the interests of the maintainers and interested parties to ensure that packages remain available as a whole, not where the onus is on the individual to ensure that his or her external dependencies do not disappear when some corporation shuts something down. </p> <p>Take CPAN as an example, according to Wikipedia it has been around since 1997 and has over 260 mirrors. I can more than likely spin up some 10-15 year old Perl project, pull in the dependencies and away I go. Google code lasted about 10 years. Why is that a bad thing worthy of down votes? </p> <p>This isn&#39;t a direct criticism of Golang, there are other tools like Bower content on pushing the primary source of truth for packages into Github.</p></pre>Funnnny: <pre><p>Using a dead package is as bad as it sound. A centralized package manager won&#39;t solve that. Not being able to update your package in 1 year is not a good sight of a healthy ecosystem </p></pre>weberc2: <pre><blockquote> <p>A dedicated centralised package manager has a notion of longevity about it that the current flavour of repository hosting platform shouldn&#39;t be expected to.</p> </blockquote> <p>I don&#39;t buy this. I don&#39;t expect Github to be more or less transient than any centralized package repository. More importantly though, this is a problem with a 2 minute fix that comes around once every ten years, and you&#39;re given a year&#39;s notice to plan for it. You&#39;re still winning when you consider all the time saved <em>not</em> configuring your project for centralized hosting, but even if you weren&#39;t this is the least of all problems.</p></pre>boarhog: <pre><p>But this is not a version control system&#39;s fault, it&#39;s the host&#39;s fault. Using version control is a good thing</p></pre>