Go is possibly easier to get into production than something based on a hefty VM, because it compiles down into one relatively small executable (except for any dynamically linked libraries being used through cgo). If you've compiled a binary executable for the target platform all you have to do is put the executable on the production machine and run. No additional runtimes, no extra libraries or vm extensions. Everything you need is right there in that executable.
I find this to be a big advantage for using Go over something like Python or Java. You still need any dynamically linked DLLs, but all the Go code itself and the runtime is statically compiled and linked into the executable produced by gc.
All this is completely ignoring the fact that the language itself has a really nice syntax, and some excellent concurrency support. Nothing it does is particularly new, but I think Go is greater than the sum of its parts.
I find this to be a big advantage for using Go over something like Python or Java. You still need any dynamically linked DLLs, but all the Go code itself and the runtime is statically compiled and linked into the executable produced by gc.
As for the concerns about it not being used in production, there's Heroku: http://blog.golang.org/2011/04/go-at-heroku.html
All this is completely ignoring the fact that the language itself has a really nice syntax, and some excellent concurrency support. Nothing it does is particularly new, but I think Go is greater than the sum of its parts.