I've been using Go for the AI challenge, and it's been an awesome experience. I feel like I'm programming in Python (well, almost), but then I head to the forums and I see all these Python programmers discussing how to tweak their programs so that they don't time out. Mine runs in a few milliseconds with no particular effort.

Thanks, Go!

Two is very young for a language. Scala is 8 years old and starting to gain a larger following. Having said that, does anyone on HN have a good story about using Go in production? Scala can be snuck in with Java. Go is going to be a little more difficult to get in the back door.

Go is possibly easier to get into production than something based on a hefty VM, because it compiles down into one relatively small executable (except for any dynamically linked libraries being used through cgo). If you've compiled a binary executable for the target platform all you have to do is put the executable on the production machine and run. No additional runtimes, no extra libraries or vm extensions. Everything you need is right there in that executable.

I find this to be a big advantage for using Go over something like Python or Java. You still need any dynamically linked DLLs, but all the Go code itself and the runtime is statically compiled and linked into the executable produced by gc.

As for the concerns about it not being used in production, there's Heroku: http://blog.golang.org/2011/04/go-at-heroku.html

All this is completely ignoring the fact that the language itself has a really nice syntax, and some excellent concurrency support. Nothing it does is particularly new, but I think Go is greater than the sum of its parts.

Heroku use it for their Doozer datastore which manages their distributed grid thingy.

Info here:

http://www.theregister.co.uk/2011/05/05/google_go/print.html

http://blog.golang.org/2011/04/go-at-heroku.html

http://xph.us/2011/04/13/introducing-doozer.html

And of course google use it internally.

>does anyone on HN have a good story about using Go in production?

http://tinkercad.com http://techcrunch.com/2011/11/08/tinkercad-raises-1-million/ (HN user kaib can say more)

Krasin is right, most of the stuff on tinkercad.com is written in Go. There are a few inner loops that use C++ to get better SSE optimizations.

I work at Iron.io[1]. Our new SimpleWorker API[2] is written in Go and we'll soon be releasing another service implemented with Go.

[1] http://iron.io/

[2] http://blog.simpleworker.com/2011/11/simpleworker-has-shiny-...

There are a surprising number of organizations using Go in production for such an extremely young and fast evolving language, and they all seem quite happy with it, including Canonical, Heroku, the Open Knowledge Foundation and others

For an unofficial and incomplete list see: http://go-lang.cat-v.org/organizations-using-go

I like go because it has good concurrency and doesn't use a boatload of RAM like the JVM.

Go's major advantage is its cute mascot.

At Google, Go seems to be competing with Python. http://www.quora.com/Which-is-easier-to-program-in-Python-or...

Looks like for certain problems that don't need to interoperate with the larger system and don't need big library support, Go can sneak in.

I've always wondered if Google would look at the possibility of making Go a supported language to use with Android.

Android and Native Client are two big areas that would help to give Go traction. If Google really cared about Go's adoption they would certainly talk about integration with these.

Google support for Go in their products seems half-hearted at most. Seems like only a few engineers in core Go team are working on it.

AppEngine doesn't support Go (no, without windows Go SDK it is not supported).

Android doesn't support native full featured Go apps, although in theory it seems like a perfect match.

Given that lack of support, I'm not even sure it is as widely used inside Google, or the story about inside usage is just a marketing.

I have answered your statement about App Engine in another post.

As for Android, it would be a colossal undertaking to implement native support for writing Android apps in Go. How can you say it's "half-hearted" to choose not to do such a massive project? Engineering time is not an infinite resource.

Unfortunately it is Google's policy not to comment on internal infrastructure, otherwise I could comment more on our internal usage of Go. But think logically: why would Google continue to invest the time of some of its best engineers (myself excluded) in something that wasn't of benefit to Google?

I would have to disagree. They seem to be putting a lot of support behind it.

"AppEngine doesn't support Go" Go itself is still pretty experimental. Changes are still made and with preparation for Go 1 they are making many backwards incompatible changes. They plan to remove the experimental tag on AppEngine the same time Go 1 is released. Until go itself becomes stable, they can hardly call the AppEngine version stable.

"no, without windows Go SDK it is not supported" Considering that the compiler they use for go (gc) is not supported on windows, that is not much of a surprise.

"Android doesn't support native full featured Go apps, although in theory it seems like a perfect match." This does not seem like a very good match at all. First, android GUI is programmed in java, it makes very little sense to try and make some sort of bridge between go and the java gui. Also, go at this stage is much better for servers than client facing applications. You know what would be an awesome fit? Go on AppEngine...

"Given that lack of support, I'm not even sure it is as widely used inside Google, or the story about inside usage is just a marketing." So far you have given evidence that Go is not being supported for people who use Windows and for programming phones. That means Google does not use it in house? The fact that AppEngine supports Go is an indication of the opposite. They probably wanted Go on AppEngine so they could use it themselves.

I know that Go support for appengine is marked as experimental, but being linux/mac only for half a year, without any roadmap for window support is exactly what I call half hearted.

And full windows support for Go wouldn't be that hard. Many open source projects have windows support thanks to mingw/msys. Having Go and Go appengine fully supported on Windows wouldn't take more than 1 full time engineer. If that is too much to ask for Google, than Go is not even half-hearted supported.

For android, I know that it would be a bad choice to bridge it to Java UI framework. I was thinking of having native Go SDK for Android that will have its own UI and other API, which doesn't have to be similar to Java. Gooogle has already separate appengine SDKs for Python, Java and Go. I know that it would be a lot of work to do the same for Android, but that will at least show that Google is really pushing behind Go.

Let me correct some mistakes:

- Go (gc) runs on Windows just fine. Go under Windows is now well-supported. We'll do a better job of communicating this once we (the Go team) are able to provide Google-built Windows binaries (currently they're provided by the community). This will come with Go 1 early next year.

- Go for App Engine is near feature parity with the Java and Python runtimes. It will come out of experimental early next year.

- The Go App Engine SDK will be available for Windows early next year.

I'm a bit insulted that you call our (very strenuous) efforts half-hearted, but I guess you can't please everyone.

"AppEngine doesn't support Go" http://code.google.com/appengine/docs/go/ They have an experimental support for Go at the moment but it's not a mainstream project.

My understanding of go is that it was designed for highly parallelized tasks like servers. That doesnt really seem like a good fit for a handset os.

It has a small memory footprint which would be great on a mobile device. Also, the entire dev cycle would be much improved. The Java/Dalvik cycle with the emulator is slow.

Also the great concurrency model would be nice to handle the ever-growing number of inputs (and outputs) mobile apps have to deal with.

Wow, my memcached server in go is going to be two years old tomorrow. :)

Fun fact: Brad Fitzpatrick, author of the original (in C) memcached is now part of the core Go team at Google.

One thing he did was write this memcached client lib that is used for Go on AppEngine: https://github.com/bradfitz/gomemcache

But I'm not sure a new memcached server in Go is coming, I think he is more interested in his 'copious' spare time to hack on Camlistore: http://camlistore.org which is a really cool but a bit hard to describe project with lots of Go code.

I've mistakenly understood the title: I though the language was being forked into two different ones ... Am I the only one?

You're probably not the only one, but "turns N" is a common idiom in English for "becomes N years old."