A metrics for choosing one go package over another

<p>Does anyone else feels that go&#39;s modules infrastructure lacks any sort of measurements, that could help to choose between thousands of existing modules. </p> <p>Comparing to npm of Node.js which shows how often the package is used per week/month/etc it quite hard to decide if particular module is better than other.</p> <p>What metrics do you use when choose an external package for your go project?</p> <hr/>**评论：**<br/><br/>SportingSnow21: <pre><p>If you want a similar &#34;use&#34; measurement, just scroll to the bottom of the godoc page to see how many packages import that library. </p></pre>varankinv: <pre><p>npm shows how many projects were using (downloading) particular package during the last week/month. </p> <p>&#34;Use metric&#34; of godoc doesn&#39;t degrade through time, so it is hard to value it. Imaging 100 abandoned projects used the package several years ago. It doesn&#39;t mean the package is still relevant. </p></pre>SportingSnow21: <pre><p>Every use metric is flawed in some way, though. If a package in npm doesn&#39;t change often, requiring a new download by everyone using it, you&#39;re only getting a read on the number of new uses rather than total uses. 100 active projects that haven&#39;t re-downloaded the package won&#39;t show in the numbers, but 1000 toy programs that download the package can skew the numbers. Nothing is inherently better or worse about either use measurement.</p></pre>neoasterisk: <pre><p>The Go community has a slightly different philosophy when it comes to external packages. Gophers are the happiest when they are able to keep their dependency trees really small, which makes for programs that are simpler, compile faster and easier to maintain. These thoughts are more or less captured in the Go proverb: &#34;<a href="https://www.youtube.com/watch?v=PAAkCSZUG1c&amp;t=9m28s" rel="nofollow">A little copying is better than a little dependency.</a>&#34; That way of thinking has lead many gophers to try and go as far as possible with the standard library and use external packages if and only if it&#39;s absolutely necessary.</p> <p>Compare that philosophy with other languages where importing dozens or even hundreds of external packages is the norm, it&#39;s clear that a strong metric for their packages is practically necessary.</p> <p>Of course sometimes even a gopher will need external packages, especially when it&#39;s a large project. Sometimes it&#39;s necessary, there&#39;s no question about it. But even in that case, Go has been designed to be simple and to read well on paper; it&#39;s trivial for any gopher to check parts of the code and inspect it&#39;s quality before deciding to depend &#34;forever&#34; on it. Having a dependency is a trade-off so it&#39;s better to make absolutely sure that we need the code that we are importing and we cannot replace it with a few lines of our code.</p> <p>Now every gopher will use different measures when they decide which external packages to use but here are a few questions that I ask myself when I try to decide if I should use an external package or decide between two similar ones, in no particular order:</p> <ul> <li>Is it pure Go?</li> <li>Is it idiomatic Go?</li> <li>Does it have sufficiently few dependencies? (ideally zero)</li> <li>Which one seems to be used the most by other projects?</li> <li>Which one has more GitHub stars and why?</li> <li>What does the community think about that external package?</li> <li>Is the code well-written and simple?</li> <li>Will I be able to debug that code if something goes horribly wrong?</li> <li>Are any big projects/companies using that package in production?</li> <li>Is the code well tested?</li> <li>Does the project have good documentation?</li> <li>How stable is that package?</li> <li>How many and what GitHub issues does it have?</li> <li>How often are the package authors updating/fixing the code/accepting PRs.</li> <li>Are the package authors committed to keep master with no breaking changes?</li> </ul> <p>There are possibly more useful questions but that&#39;s all I can think of right now.</p> <p>I firmly believe that taking good care of a project&#39;s dependencies (sometimes that means eliminating them) should be a constant exercise that every good coder should do. I could even go as far as argue that not having a central repository, metrics and package manager like Node.js does is actually a boon for the Go community but I digress.</p></pre>