Go is a nice language, I've used it for 3 projects so far.
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 :(
It's really nice to see GAE add yet another support language, in addition to Python and Java. I'm pretty new to Python web development, but GAE seems absolutely fantastic. It's so easy to use and such robust features.
Great price too. Basically free until you get traction. You have to decide whether that's worth the flexibility you trade for it, but for a lot of projects it is.
It's great news for App Engine. However, ever so subtly Google is increasing developer lock-in in App Engine. GO is Google's language to rope in the developers.
Isn't the act of developing for App Engine itself "developer lock-in", regardless of language? If I could write iPhone apps in Lua or Ruby I'd still be "locked-in" to the Cocoa platform. Same with writing programs for Android, Windows, Linux, Facebook,...
There are open source replacement for most of App Engine's services and API. The old language choice Java and Python are open source. GO is Google's language just like #C for Microsoft. Currently it's really easy for me to port my App Engine apps to AWS; I'm not sure if I use GO.
I believe AppScale supports Go, so I don't see how it's any harder to port a Go App Engine app to run elsewhere than porting Python or Java apps.
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.
I'm using Go for a project right now and loving it (it's running in Windows and this is by far the least pain I've had writing low level cross platform code). I'm confused between the juxtaposition (and maybe this is just a personal perception problem) between Go as a "systems language" and the large group of people using and pushing it as a web language.
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.
Go team has stopped pushing the "systems language" label for Go, probably because discussions were derailed by philosophications about what is and isn't systems programming.
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.
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.
It's been mostly driven as a research project and because GAE is so cheap to use (thus far) there hasn't been much of an incentive for people to use it as an alternative. There has been a good amount of usage within the research community though. We're looking at making AppScale more than just an alternative; something along the lines of a hybrid setup where data is replicated to your own cluster for fault tolerance and data analytics.
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 :(