It might be nice for a quick script or standalone program, but most decent size software projects need plenty of mature libraries to be of much use. Python and C have decades head start here.
I think 24 months quoted in the article is optimistic...
But is simpler to just write all your code in Go, Python code is not just slower, it is also less reliable and less maintainable.
(Part of Python's popularity is that it is such a great glue language)
Everyone is striving for concurrency as a language feature but sometimes it seems like a solution looking for a problem. What is it that you _cannot_ do now that you must have concurrency in order to do? What specific real world problem is it that you cannot solve? What are the cost-savings you will achieve with concurrency?
Maybe concurrency is a matter of smart programming, not dummy-proof languages with concurrency "built-in"?
Concurrency seems to be Go's main selling point (along with fast compilation). But Go is not small, it's not embeddable and it can't leverage C functions with the same ease as Lua. With Lua you can extend apps written in C. With Go you are writing the same old C apps again in Go. All the Go libraries I've see so far are just libraries that exist in other languages to do the same old things we've been doing for years, rewritten in Go.
At least with Lua, creativity and expression is encouraged by letting people write their own libraries. All the existing C libraries don't have to be rewritten as Lua libraries. What a boring exercise that would be. All you need to do is understand how to interface with C functions and there's little you cannot do vis-a-vis existing C libraries to do the "usual things".
Just my opinion. Lua is an arbitrary example. It's the general concepts of simplicity, small size, extending applications, and leveraging existing C code of which I am a "fanboy". It just happens that Lua meets some of these criteria. Sorry if it offends anyone.
However, Go's apparent concurrency focus is a bad assumption.
The problems that Go solves are simply: simplicity, synchronisation, thread scalability, time to market, modularity, testability, consistency, security and memory management.
All of those, you really can't do in C quickly and safely.
Go is a fixed C, with a fixed standard library that suits NOW, not 20-30 years ago. That's all it is and that should be applauded and praised. It also fixes the inevitable mountain of stuff you have to do to get something significant done in C and ignores the utter retarded complexity of C++ and Java.
Ultimately:
A single person can build something significant in Go in a week.
A single person cannot build something signficant in C in a week.
cgo is very easy. I've plugged SDL into it in a few minutes.
A question: What is your idea of "something significant"?
Go seems like an ideal language to quickly build servers. Am I missing something else?
Still, it is rarely used, building in pure Go is much nicer, because one of the great things about Go is building systems where you can understand all the pieces.
And if you want to understand what a Go lib does looking at the source is surprisingly informative. (This also addresses most of the complaints about documentation).