Apparently yesterday, 2010-11-10, was the first anniversary of the existence of the Go programming language. Whether it is actually true or not doesn't matter, Rob Pike, the leader of the Go team, has declared by an email on the email list, that this is a fact!
Go has definitely exhibited "phenomenon" status: in an incredibly short time it has evolved into something very useful and usable, and it has created a "buzz" not associated with an imperative programming language since 1995 and the rise of Java.
Go seems to show the possibility that it might quickly topple C as the "compiled to native code" programming language of choice. The fact that some of the original developers of C and UNIX are a part of the Go team gives added credence to the view that Go will replace C.
The core issue here is multicore. The way processor architectures are evolving, moving more and more toward distributed memory, leads to a problem for programming languages such as C, and indeed C++. Whilst C++ (via the C++0x standard) now has threads as part of the language, there is a built in assumption that all the processors available to the program are fundamentally the same. With current multicore devices this tends to be true. The future though is heading much more towards heterogeneous multicore devices: chips with many processors, but with a multiplicity of architectures. Certainly libraries can help C and C++ deal with such systems, and indeed this is one of the reasons for OpenCL. However OpenCL is really just an attempt to patch things up so that C and C++ can continue to be used, it isn't really a solution to the problem.
Increasingly, we are seeing moves to revive long forgotten software architectures: Actor Model, CSP, Dataflow Model. This is a return to process- based rather than thread-based thinking. On the JVM, Scala is heading the Actor Model route. Erlang has been using Actor Model for many years. In the native code arena, there are CSP implementations for C and C++. Go is a core part of this trend. Although developed independently of CSP, the process and channel model of Go, evolved via the Newsqueak, Alef and Limbo programming languages that preceded Go, is very similar to that of CSP. The somewhat twee naming of "goroutines" doesn't detract from the fact that they are a very usable tool for creating process-based, parallel systems.
Go seems to already have what C would need to have to be able to cope with the hardware devices that will soon be with us.