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.
Well, I don't expect most programs to be re-written in Go, but I think in, say 10 years' time most new programs will be. By then Go's mature, fast libraries will be comparable to any of Python's (although C will have the kernel-level advantages still I think).
I think 24 months quoted in the article is optimistic...
I think Lua is still the most simple and easiest in this regard. And Lua is embeddable.
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.
I've evaluated Lua for a number of use cases and even use it on my Ti NSpire calculator occasionally, but it has some horrible problems, particularly related to metatables and the concept of 1-based indexes. It also doesn't give us any advantages over other languages. LuaJIT is impressive I will say though.
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.
I agree with you mostly. Although you are comparing Go to a language with manual memory management, not another GC language, like Lua (sorry to keep using that example).
A question: What is your idea of "something significant"?
Go seems like an ideal language to quickly build servers. Am I missing something else?
Go has FFI hooks with "import C", outside of that I haven't found anything (though Go's way looks much simpler than typical FFI setups at first glance). No direct access to C / C++ libraries like D does, though that's probably a good thing.
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).
