You're right, although I doubt Ken Thompson & Rob Pike can be called a new generation. Actually, Go seems to be history going the other way ; Go isn't very innovative, it's the main this his detractors point to, it's just Pascal/Oberon/C with almost-new clothes. So Go is "solving" issues that were raised by Python/Ruby et al, mainly regarding performance, programming in the large and ease of deployment.
Most of the "I'm switching for 10 years ago's hype to Go" articles (including this one) are actually saying "whoops, 10 years ago's technology had drawbacks, I just discovered them, let's use 15 years ago's technology with fancy clothes".
Maybe Go isn't very innovative, but that doesn't mean it wouldn't be more useful than the old stuff. With Turbo Pascal and Delphi I could also generate a single exe with no stupid DLL dependencies. But Turbo Pascal and Delphi don't support anything besides Windows and Borland's Kylix never got traction. Go on the other hand can generate no-dependency executables for Windows, Linux and OSX, pretty much all the major players of today. And what's maybe more important than the language's innovativeness is community support. Of all the languages today that allow generating a single executable for all major platforms, Go probably has the most active community.
Actually, there's FreePascal/Lazarus, and IIUC it's quite cross-platform:
from http://www.freepascal.org/ :
"It can target multiple processor architectures: Intel x86, AMD64/x86-64, PowerPC, PowerPC64, SPARC, and ARM. Supported operating systems include Linux, FreeBSD, Haiku, Mac OS X/iOS/Darwin, DOS, Win32, Win64, WinCE, OS/2, MorphOS, Nintendo GBA, Nintendo DS, and Nintendo Wii."
You might want to take another look at Delphi, as the recent versions (XE4 and XE5) have added cross-platform support for OSX and Android (at least). While I still have to develop on Windows, I can easily produce native static OSX binaries and Windows binaries from one source tree and with careful selection of UI components also an Android app.
To support Android the Go team needs to accept dynamic loading, at least for the current NDK toolchain as you can only have shared objects as binaries.
How about goroutines? Not that they created them (although their actual implementation is fairly unique) but they certainly gave them a chance to make them mainstream.
Most of the "I'm switching for 10 years ago's hype to Go" articles (including this one) are actually saying "whoops, 10 years ago's technology had drawbacks, I just discovered them, let's use 15 years ago's technology with fancy clothes".