Go for App Engine is now generally available
blog.golang.org
blog.golang.org
But the garbage collector needs some big improvements until I will use it for anything that gets some kind of heavy work load. I used it as a simple HTTP daemon that just collects data submitted by flash clients via POST requests and keeps some internal stats about them. It is literally just something like 200 lines of code. When I had over 30 req/s, nearly 100mb overall RAM usage and a Go heap of usually about 60-70mb, a GC run would take over 115ms. During that run, it stops all other threads (stop-the-world GC). For this particular project that was OK-ish since the clients don't see the latency. But for anything where the user is exposed to the latency (e.g. serving pages), this would be a problem. Especially since the GC latency increases faster than linearly. I'd expect a GC run to take more than 1 second with about 100 req/s and something like 500mb RAM usage.
I could probably get much better performance by reducing the heap size by avoiding using the stdlib packages like "http". They create LOTS of garbage. Strings being imutable does not help with that either.
Unfortunately even though they said the GC is being rewritten right during the first and nearly every other presentation, this is not happening. They still are using a conservative non-generational stop-the-world GC. Even though they are tuning it a fair bit, this type of GC is not really good to begin with. It's a shame :(
I'd also very much like to see Go on Android, but I know it's harder since the vast majority of APIs are Java-side.
Go to Google is not like C# is to MS. Microsoft's C# platform is not free and they have complete control over the language. The Go compilers and libraries are open source. You're free to take and use them as you see fit (under the terms of its BSD license). Google can't "lock you in" to using Go.
Of course, I say that and my usage leverages the fact that it has nice http and websocket facilities as well as the awesomeness that is cgo and the wide world of C libraries.
Now they refer to it simply as "general purpose programming language" although, unsurprisingly, the label still persists from the early usage.
Go isn't good at some things that some people consider systems programming so it's best to stop thinking of it that way.
Go is a programming language, good for some things (including both server and client web programming) and less good for some other things.
Git is still referred to by some as a content-addressable filesystem and not an SCM, which is what Linus wrote in his announcement email.
EDIT: and git is just an example.
I'm not entirely sure he would disagree with with what he said here. He seems to be trying to convince people to come at the problem of content management from a different perspective, and to abandon the intellectual baggage of CVS, rather than to insinuate that they should replace EXT* with git, or that they should develop an actual FS.
If what you say is true, it seems more likely that people misunderstood the original statement and carried that into the future, where the Go people seemed very serious about it being a systems language.
Anyway, that was just an example. Generally, what gets written about something that is still new is what will stick in people's head for quite a long time.
I believe it's like when you hear a song that's been recorded by more than one artist: the first arrangement you hear is often the one you will end up liking the most. When you'll hear another arrangement, odds are good you won't like it as much as you like the first.