<p>Hi, </p>
<p>I am a beginner with go, and I have hard time choosing which packages should I use for my web application. I wouldn't want to use package that are not popular, unmaintained, obsolete, etc.</p>
<p>With node, you get download stats on npmjs.com, symfony have packagist that show download and votes.</p>
<p>What central information point have golang?</p>
<hr/>**评论：**<br/><br/>izztmzzt: <pre><p>Assuming you found it on guthub, check stats like number of contributors, stars, last commit, open issues, build status, unit test coverage, etc. That should give a clear enough picture.</p></pre>Faffenheim: <pre><p>Also how many other packages import the package (you can find this information in the package page on godoc.org, at the end of the page).</p></pre>bmarston: <pre><p>Hum, interesting!!</p>
<p>What I cannot understand is that : <a href="https://godoc.org/?q=uuid" rel="nofollow">https://godoc.org/?q=uuid</a>
, there is more than 3 packages with similar functions that are imported more than 300 times ... and 170 others ...</p>
<p>What the point? Same for Web framework, still no clear winner.</p></pre>seufert: <pre><p>Why do you think there has to be a "clear winner"?</p></pre>hansdr: <pre><p>To save time when deciding which package to choose. If you're new to Go and confronted with a large array of packages that essentially solving the same problem, deciding which one to use can be hard and time consuming. If there's a "clear winner" then you can use the "wisdom of the crowd" to short-circuit that decision. </p>
<p>That doesn't guarantee that you'll get the best package for your particular application, but it can certainly save you a lot of time. That's time that you can use to write actual code...</p></pre>zeiko_is_back: <pre><p>It's a false economy to choose packages based purely on popularity, I have seen my fair share of very popular packages which are total crap and riddled with vulnerabilities. You would be better served by evaluating the API they present and the code quality of the package than by how many other people download it.</p>
<p>Perhaps the reason there is a "clear winner" so often on NPM is because most people don't actually evaluate packages at all, and everybody just piles on the most popular one, increasing it's popularity and meaning that the "clear winner" is pretty much chosen randomly.</p></pre>hansdr: <pre><p>I respectfully disagree. When faced with too much choice, in-depth analysis of every option becomes too costly. This is where less accurate techniques come in to cut the list down to a manageable size. Then you can look at your shortlist of options in more detail.</p>
<p>Is the assumption that "they must know something that I don't" always right? No. As you said, a crap package might get a random boost. They do tend to drop down in the long run though, due to their poor quality.</p>
<p>Could you miss the "absolute best one?" Absolutely. Could you end up choosing one that's no good? Yes. However, you've got the time to go back and evaluate other ones if your initial choice ends up being no good.</p></pre>bmarston: <pre><p>No that's right, there is no need to be a clear winner. But I think it's the best for the language if the community can focus on some important and efficient packages instead. No need for hundreds of packages, 3-4 implementation could be sufficient most of the time.</p></pre>earthboundkid: <pre><p>I looked up UUID generation in Go the other day. The conclusion I remember coming to was that UUID turns out to be more or less trivial to generate yourself so you don't really need an external library if you don't want to use one. </p></pre>natefinch: <pre><p>I think that this is actually a good thing. It's not a popularity contest. The fact that there are different implementations is a good thing. They probably have different goals (one might be a simple and fast implementation, one might be a full implementation of the full RFC, etc).</p>
<p>Go look at the repos, look to see how well they are maintained. That's probably more important than how many people import something. Maybe the repo hasn't been touched in 2 years, but everyone uses it... because everyone uses it.</p>
<p>I like that Go makes you do a little more legwork when analyzing your dependencies. It makes you really decide what is best for your project, rather than just pulling in random dependencies with no thought for their impact on your project.</p></pre>teastburn: <pre><p>I've been using <a href="https://golanglibs.com/" rel="nofollow">https://golanglibs.com/</a> and <a href="http://go-search.org" rel="nofollow">http://go-search.org</a> and liking them. I agree it's not a popularity contest but assuming other people have gone through the same library evaluation process, you can learn from their choices. Also, generally more popular libraries receive the most attention and updates.</p></pre>
