It's very interesting to see stories about Google Go, although I wish this one had gone into a little more technical detail with perhaps an example of something interesting that's been done with go routines and channels. I'm very drawn to Google Go because of my background in CSP and as an old-school C programmer. My experience with it has been very positive.

Go has really been great fit for web based APIs where I work. Going from multiple servers running PHP-FCGI to a single server running a Go app behind Nginx has reduced costs significantly.

"In our tests, Go's performance blew away most of the competition."

Since it didn't blow away "all" of the competition, this reader is curious about which other stacks held their ground.

This reader is also curious as to why Erlang wasn't in the competition, since Erlang meets all of the stated requirements (same programming language for backend and frontend systems, fast HTML templating system, fast start-up, modular recompilation, lots of connections on one machine, language tools for handling application-level concurrency, good performance, robust RPC layer to talk between tiers, lots of libraries, and open source). I'm guessing there was an unstated requirement along the lines of "syntax is not weird".

Node performed well, but we prefer writing async code in Go, and we like compiled languages.

We'd love to experiment with Erlang at some point, at the very least to write an Erlang StatHat library.

It's not only syntax, I think Erlang although a very good language, puts you in a different mode of thinking. This might be a good thing, but it also makes it harder to find developers to work on your project as they are less abundant.

How's the deployment story for Erlang? One attractive feature of Go is that it produces self-contained* binaries that can be easily deployed to your production hardware. No other setup required.

(*Go's net package links against libc to get around domain resolution issues on various broken systems. This can be disabled if you want a truly standalone binary.)

Andrew,

deployment story for Erlang is not as simplistic as in Go, but it allows much more, including deploying and running several versions simultaneously, hot patching or live profiling. The philosophy of Erlang/OTP is drastically different from Go/Google production, so it's not easy to have a direct comparison.

I'm really interested in Go, but I wish they would elaborate on statements like this:

   Although Go is a young language, it has a lot of system
   packages and a growing number of user-contributed 
   packages. With only a few exceptions, we have found Go 
   packages for everything we have needed. 

Highlighting what is missing is the best way to fill in the gaps (especially on a blog directed at eager developers like this)

You can see a few of the packages we wrote ourselves as we open sourced them: http://www.stathat.com/src

Basically what I was referring to as missing were the Amazon SES package and braintree. We haven't released the package for braintree yet, but we will.

I'm interested to use Go, but probably couldn't justify introducing it at work until they hit version 1.0.

The built-in RPC is nice, but it seems like one would still want to use something like Thrift -- I assume that non-Go servers cannot talk Go RPC

There's also a standard JSON rpc package that you can use to interact with non-Go servers.

We plan to launch Go 1 early next year.

I wonder if GO can be used as a new front-end language, i.e., replacing javascript. The fast compile times certainly would make it feasible to compile the code at runtime in the browser and then execute in a sandboxed environment.

I got schooled angrily by the creator of JavaScript and founder of Mozilla on the difficulties of NaCl and Dart here http://shaver.off.net/diary/2011/10/28/approaches-to-perform...

He says it would be impractical for other browser vendors to keep up with the sprawling mess of APIs required by NaCl known as Pepper. Also Google's behavior around it's open source but not open standard tech like NaCl and Dart leaves a bad taste.

THAT was the question people kept asking Pike at conferences. and his answer to the question is "yes, we would like to see that happen too".

and i hope Google is listening. i mentioned in many comments before, i just see it there, unlike Dart.

i am not ignoring the hard work behind Dart or anything, but it's just my feeling that i wouldn't personally move from Javascript to something that just looks like Java. Javascript to Go or Python? definitely.

If one could emit assembly we could just use any langauge for front-end development.

"Language tools for handling application-level concurrency" this sounds interesting. Can you recommend a good read about this topic?

PS: I presume the graph drawing library is written in-house, what did you use as the building blocks for it (both for design and implementation) ?

Regarding concurrency in Go, this is a good place to start: http://golang.org/doc/effective_go.html#concurrency

And, yes, the chart drawing library was written by us. It uses cairo for drawing primitives.

Thanks! Cairo looks interesting too. If you have some invites left I would be grateful!

I've been experimenting with GO and I really like it, especially since I come from a C/C++ background. Does anyone know of any good GO packages?

I wanted to use the experimental support for GO in google app engine but it seems fairly limited...at least for the time being.

It looks like a lot of App Engine functionality is available. What's missing?

Indeed, it's almost on par with the the other runtimes. Remember that the Google thanksgiving doodle was written in Go and ran on standard App Engine infrastructure.

I think GO is still experimental in app engine and doesn't support some services like OAuth, Google Cloud Storage, and XMPP. Also, "experimental" scares me for production use.

I'm writing an AppEngine app in Go right now. It uses the same datastore as Python and Java, as well as OAuth and JavaScript Channels. Iterating with the development server is a pleasure, since it compiles everything in the background as you work.

Have you tried releasing it for production use? I would love to hear how it is working out for you. Are there any frameworks?