It's all about the libraries, Python and C for example have libraries/bindings for most things, e.g. Postgresql, ZMQ, Json etc. Google could invent the best programming language ever but without _mature_ _robust_ libraries it is pretty much useless.
Which data structures have you personally been bitten by that lack of?
I ask this because I often find myself thinking I would want such-and-such a feature in a tool, library, etc, but unless it was implemented in response to an immediate need, when I actually add it I realize it ends up unused.
I mostly wanted some better set and map container implementations (hashtables, binary search trees, tries); the built-in map can't be applied to all types, and is quite limited in how configurable it is. Given that we were going to be using these data structures everywhere, we decided Go was a bad choice for our project.
My guess is that better containers aren't in the library because of the lack of generics. I really hope the Go folks get around to adding generics soon; it's a beautiful language in most other respects. It would definitely be one of my first choices for a more systems-y project.
Good software takes time. Asking a new programming language to have "mature 3rd party libraries" is a bit harsh. You are, of course, correct in that the variety of libraries available in Go is more limited than older languages, but I have hope that it will change rapidly.
I am not asking it to have anything, the article is insulating that GO is the new go to language, it is not because it doesn't have mature and comprehensive libraries. When I make a decision to use a particular language I don't wan't to handicap myself, you need as much edge as possible. In 10 years maybe Go will have a vast array of mature libs but until then I shall be choosing Python and C.
This is one of the main reasons that I use Go. Its libraries are of significantly higher quality than most other languages. And since most libraries are native, it's much easier to expand on their capabilities without having to resort to forking some C extension like with Python.
Go does have quite a few bindings that exist already for many commonly-used libraries (and some not-so-commonly-used). I'm pretty glad there are Lua bindings, for example. When Go makes more sense than C but Lua makes more sense than Go, I was kind of stuck until I discovered this.
Here is a listing I know of, this probably isn't comprehensive:
It's a chicken/egg thing. People will use Go for projects that its existing libraries can handle. That will be more people as the libraries expand. Given the extent of today's libraries I'd say that Go is useful for plenty of projects.
This can be said about pretty much any language in their infancy, it is not a setback, just a matter of time and getting attention from the community (and Go is getting a lot).
