| Let me ask the obvious question. Why hasn’t the go community, of professional software engineers built an even richer ecosystem of libraries? Is it ennui, incompetence, or attitude? As Go came from Google, is that the attitude was, “I am a professional I’ll just write my own code to solve X”, rather than considering building a library that others can use? Are libraries harder to build in Go? Is adoption of libraries by the Go community different? Is it a mindset, that libraries are uninteresting? Or is it something else entirely? |
Plus, I've been programming in Go professionally for a while and it's been a while since I reached for a critical library and it was missing.
Go ends up needing fewer libraries anyhow; in Python you have the pure-Python version, no, wait, the Twisted version (which may not be current but are still all there, increasing the library count), no, wait, the async version, no, wait, the Python 2 version, no, wait, the one that binds to a C library.... and actually this isn't specific to Go, it's really more specific to Python. Library count gets bloated up over the decades by the fact that when, for example, Python went to async, all non-async libraries in which async was relevant suddenly needed a clone. Go has had effectively no language changes which create such parallel libraries (note changes, not additions; Go has had additions which create opportunities for more libraries but don't create lots of parallel libraries). I don't know that Python is uniquely changing, "best practices C++" is arguably up there, Javascript has had a lot of churn, but it's in the higher tier of such things. Languages that don't churn like that should be able to cover the same amount of "need" for libraries in fewer libraries by the numbers.