Go is a systems programming language which we've branched out into using occasionally when we feel Django isn't a good, or necessary, fit. Being a statically compiled, type-safe language, it's great for writing applications to automate system functionality, and works well as an API service when required. As per our manifesto, both Daniel Perry and Jon Pulfer can wrangle Go into a useful shape.
We've not yet used it for as many projects as we have Django, but where we are using it, it's in mission-critical places, and is stable in a way only type-safe languages can be.
One of our biggest wins has been translating the building of an ElasticSearch indexer and API to replace an extant one written in Django which had begun to get slower than we'd like as more functionality was required. After Jon spent some time analysing the situation, he was able to get the indexing of millions of database rows into ElasticSearch down to 30 minutes, from a previous development-server runtime of 2 days.
Being a relatively young language -- only stable for 2 years -- there's still a lot of opportunity to contribute to the open-source community's packages. We've so far contributed small improvements to Revel (a web framework), Gorp (an ORM), and packages for reading data from Python's pickle library (allowing us to share data between our Python and Go services)
Go was developed, and is supported by, Google, targeting their internal needs for high performance single-file applications that can be deployed with a minimum of fuss and/or downtime. It is heavily oriented around making concurrency easy, where other languages like Python are not. Go is a small, simple language built around being clear and precise, rather than brevity (Python, Ruby) or explicit verboseness (Java), which explicitly drops popular techniques in favour of clarity. There's no operator overloading, or exceptions, for example.
Go is often cited as being near on-par with Java, and orders of magnitude faster than interpreted languages like Python, while using comparably little memory and CPU. That usually translates into a direct increase of workload capability not to be sneezed at, at the cost of being a more labour-intensive initial-development.