This has nothing to do with Go. It sounds like a case of poorly managed dependencies and build rules and likely weak engineering. The fact that they wanted to support the iPad and chose Go also shows this wasn't well thought out.
* Go 1.0 had a terrible GC, especially on 32-bit platforms (their target platform)
* No manual memoray management (and unlikely to ever exist)
* Can't bind to C++, can't cross-compile cgo (gccgo can though)
Go is really cool, and I use it every day, but it doesn't make any sense for games, especially not for their target platform. Maybe in a few years the GC will be more reliable, but I wouldn't try to build a game in Go if I thought I might want to try to sell it.
A little background on this: I work at Google on the MapsGL effort, and as part of launching MapsGL we decided to launch a unit testing framework we wrote for our shaders. Shaders can get hugely complicated and bug prone, and don't provide a great way to debug them. GLSL Unit hopes to change that.
We do not have an exclusion list, but we do run a micro-benchmark on your machine to ensure your GPU will be powerful enough to handle MapsGL. You can try upgrading your drivers as well, which sometimes improves performance (looks like intel put out new device drivers for that chip about a year ago)
There is also "LINQ for Javascript", which is fully integrated in with JQuery and VS as well. http://linqjs.codeplex.com/
Streams seems to be a proper subset of the things you can do with linqjs. Sometimes MSFT can do cool things too, it just doesn't always get picked up :)
The traffic estimates we eliminated are different that the ones we use in Route Around Traffic. The old ones (e.g. "Up to XX Hours, XX Minutes in traffic") were pretty inaccurate and was a picture only of worst case scenarios, whereas we feel the data used in route around traffic is much more accurate.
