Why is Go module output so low?

<p>According to modulecounts.com Golang&#39;s daily module output is currently only 3. Compared with 90 for Python it doesn&#39;t seem to make sense. </p> <hr/>**评论：**<br/><br/>scottjbarr: <pre><p>I&#39;m don&#39;t know how they&#39;re counting packages.</p> <p>I see the fantastic stdlib coupled with a foundation of really solid packages as one of the strengths of Go. I don&#39;t feel a need for validation by a high number of new shiny things per day. I think the package/library ecosystems of other languages beat it into me that more does not mean better.</p> <p>Personally, I build solid, reliable services using a handful of packages. I don&#39;t feel like I&#39;m missing anything right now as far as packages are concerned.</p></pre>brokedown: <pre><p>What a stupid metric. It&#39;s like judging your congressman based on how many pages of legislation he writes.</p></pre>recurrency: <pre><p>• Sheer size of the community</p> <p>• General tilt towards quality over quantity: we don&#39;t need 20 libraries for doing the exact same thing (except for http routers ;)))). Plus the stdlib takes you a long way (and the apis are so well thought through and the docs so good compared to pythons you don&#39;t need an alternative pkg for most stuff)</p> <p>• A little copying is better than a little dependency, nick the parts u need, mash it up as needed</p></pre>wordsnerd: <pre><blockquote> <p>(except for http routers ;))))</p> </blockquote> <p>As Benjamin Franklin said, a nanosecond saved is a nanosecond earned.</p></pre>dgryski: <pre><p>modulecounts changed their source of go modules. At the moment its using <a href="https://gopm.io/" rel="nofollow">https://gopm.io/</a>, which seems to be undercounting.</p></pre>lstokeworth: <pre><p>The site counted the number of packages on godoc.org/index at one point. This overcounted the number of modules because the page listed packages whether the package was intended for reuse or not. The godoc.org/index page was removed.</p></pre>yawboakye: <pre><p>Packages usually make up for missing functionalities and bad APIs. Same go for web frameworks for scripting languages. Django (and the popular requests module) and Rails compensate for many key but missing web and HTTP functionalities in their base languages.</p> <p>Go has no definitive web application framework because the language + stdlib is pretty solid in this space. You’ll see an explosion in modules in areas where the language doesn’t perform well naturally. Currently most use cases of Go haven’t extended into unfamiliar territories hence the minimal number of packages. This is my 2 cents. I hope it made any sense. </p></pre>