12 June 2013
In 2011 we announced the Go runtime for App Engine. Since then, we have continued to improve the Go App Engine experience, and generally improved Go support for the Google Cloud Platform. For instance, the google-api-go-client provides a Go interface to a range of Google's public APis, including Compute Engine, Cloud Storage, BigQuery, Drive, and many more.
Learn more by watching these talks from Google I/O this year:
High Performance Apps with Go on App Engine
The Go runtime for App Engine is a high performance engine for running web applications. It produces fast responses, starts instances in a fraction of a second, makes the most use of instance hours, and allows your app to do serious processing at full machine speed. Come along to hear how to fully exploit the power of Go on App Engine and make your web applications the best they can be.
All the Ships in the World
Visualizing Data with Google Cloud and Maps
Tens of thousands of ships report their position at least once every 5 minutes, 24 hours a day. Visualizing that quantity of data and serving it out to large numbers of people takes lots of power both in the browser and on the server. This session will explore the use of Maps, App Engine, Go, Compute Engine, BigQuery, Cloud Storage, and WebGL to do massive data visualization.
6 June 2013
At Google I/O 2013, several members of the Go team hosted a "Fireside chat." Robert Griesemer, Rob Pike, David Symonds, Andrew Gerrand, Ian Lance Taylor, Sameer Ajmani, Brad Fitzpatrick, and Nigel Tao took questions from the audience and people around the world about various aspects of the Go project.
We also hosted a similar session at I/O last year: Meet the Go team.
There were many more questions from Google Moderator than we were able to answer in the short 40 minute session. Here we answer some of those we missed in the live session.
Linking speed (and memory usage) for the gc toolchain are a known problem. Are there any plans to address this during the 1.2 cycle?
Rob: Yes. We are always thinking about ways to improve performance of the tools as well as the language and libraries.
I have been very pleased to see how quickly Go appears to be gaining traction. Can you talk about the reactions you have experienced working with other developers inside and outside Google? Are there any major sticking points remaining?
Robert: A lot of developers that seriously tried Go are very happy with it. Many of them report a much smaller, more readable and thus maintainable code base: A 50% code size reduction or more when coming from C++ seems common. Developers that switched to Go from Python are invariably pleased with the performance gain. The typical complaints are about small inconsistencies in the language (some of which we might iron out at some point). What surprises me is that almost nobody complains about the lack of generics.
When will Go be a first-class language for Android development?
Andrew: This would be great, but we don't have anything to announce.
Is there a roadmap for the next version of Go?
Andrew: We have no feature roadmap as such. The contributors tend to work on what interests them. Active areas of development include the gc and gccgo compilers, the garbage collector and runtime, and many others. We expect the majority of exciting new additions will be in the form of improvements to our tools. You can find design discussions and code reviews on the golang-dev mailing list.
As for the timeline, we do have concrete plans: we expect to release Go 1.2 on December 1, 2013.
Where do you guys want to see Go used externally? What would you consider a big win for Go adoption outside Google? Where do you think Go has the potential to make a significant impact?
Rob: Where Go is deployed is up to its users, not to us. We're happy to see it gain traction anywhere it helps. It was designed with server-side software in mind, and is showing promise there, but has also shown strengths in many other areas and the story is really just beginning. There are many surprises to come.
Ian: It’s easier for startups to use Go, because they don’t have an entrenched code base that they need to work with. So I see two future big wins for Go. One would be a significant use of Go by an existing large software company other than Google. Another would be a significant IPO or acquisition of a startup that primarily uses Go. These are both indirect: clearly choice of programming language is a very small factor in the success of a company. But it would be another way to show that Go can be part of a successful software system.
Have you thought any (more) about the potential of dynamically loading_ Go packages or objects and how it could work in Go? I think this could enable some really interesting and expressive constructs, especially coupled with interfaces.
Rob: This is an active topic of discussion. We appreciate how powerful the concept can be and hope we can find a way to implement it before too long. There are serious challenges in the design approach to take and the need to make it work portably.
There was a discussion a while ago about collecting some best-of-breed
database/sql drivers in a more central place.
Some people had strong opinions to the contrary though.
database/sql and its drivers going in the next year?
Brad: While we could create an official subrepo (“go.db”) for database drivers, we fear that would unduly bless certain drivers. At this point we’d still rather see healthy competition between different drivers. The SQLDrivers wiki page lists some good ones.
database/sql package didn’t get much attention for a while, due to lack of
drivers. Now that drivers exist, usage of the package is increasing and and
correctness and performance bugs are now being reported (and fixed). Fixes will
continue, but no major changes to the interface of
database/sql are planned.
There might be small extensions here and there as needed for performance or to
assist some drivers.
What is the status of versioning? Is importing some code from github a best practice recommended by the Go team? What happens when we publish our code that is dependent on a github repo and the API of the dependee changes?
Ian: This is frequently discussed on the mailing list. What we do internally is take a snapshot of the imported code, and update that snapshot from time to time. That way, our code base won't break unexpectedly if the API changes. But we understand that that approach doesn’t work very well for people who are themselves providing a library. We’re open to good suggestions in this area. Remember that this is an aspect of the tools that surround the language rather than the language itself; the place to fix this is in the tools, not the language.
What about Go and Graphical User Interfaces?
Rob: This is a subject close to my heart. Newsqueak, a very early precursor language, was designed specifically for writing graphics programs (that's what we used to call apps). The landscape has changed a lot but I think Go's concurrency model has much to offer in the field of interactive graphics.
Andrew: There are many bindings for existing graphics libraries out there, and a few Go-specific projects. One of the more promising ones is go.uik, but it's still in its early days. I think there's a lot of potential for a great Go-specific UI toolkit for writing native applications (consider handling user events by receiving from a channel), but developing a production-quality package is a significant undertaking. I have no doubt one will come in time.
In the meantime, the web is the most broadly available platform for user interfaces. Go provides great support for building web apps, albeit only on the back end.
In the mailing lists Adam Langley has stated that the TLS code has not been reviewed by outside groups, and thus should not be used in production. Are there plans to have the code reviewed? A good secure implementation of concurrent TLS would be very nice.
Adam: Cryptography is notoriously easy to botch in subtle and surprising ways and I’m only human. I don’t feel that I can warrant that Go’s TLS code is flawless and I wouldn’t want to misrepresent it.
There are a couple of places where the code is known to have side-channel issues: the RSA code is blinded but not constant time, elliptic curves other than P-224 are not constant time and the Lucky13 attack might work. I hope to address the latter two in the Go 1.2 timeframe with a constant-time P-256 implementation and AES-GCM.
Nobody has stepped forward to do a review of the TLS stack however and I’ve not investigated whether we could get Matasano or the like to do it. That depends on whether Google wishes to fund it.
What do you think about GopherCon 2014? Does anyone from the team plan to attend?
Andrew: It's very exciting. I'm sure some of us will be there.
23 May 2013
At Google I/O a year ago Rob Pike presented Go Concurrency Patterns, an introduction to Go's concurrency model. Last week, at I/O 2013, Go team member Sameer Ajmani continued the story with Advanced Go Concurrency Patterns, an in-depth look at a real concurrent programming problem. The talk shows how to detect and avoid deadlocks and race conditions, and demonstrates the implementation of deadlines, cancellation, and more. For those who want to take their Go programming to the next level, this is a must-see.
The slides are available here (use the left and right arrows to navigate).
13 May 2013
It is our great pleasure to announce the release of Go 1.1.
In March last year we released Go 1.0, and since then we have released three minor "point releases". The point releases were made to fix only critical issues, so the Go 1.0.3 you use today is still, in essence, the Go 1.0 we released in March 2012.
Go 1.1 includes many improvements over 1.0.
The most significant improvements are performance-related. We have made optimizations in the compiler and linker, garbage collector, goroutine scheduler, map implementation, and parts of the standard library. It is likely that your Go code will run noticeably faster when built with Go 1.1.
There are some minor changes to the language itself, two of which are worth singling out here: the changes to return requirements will lead to more succinct and correct programs, and the introduction of method values provides an expressive way to bind a method to its receiver as a function value.
Concurrent programming is safer in Go 1.1 with the addition of a race detector for finding memory synchronization errors in your programs. We will discuss the race detector more in an upcoming article, but for now the manual is a great place to get started.
The tools and standard library have been improved and expanded. You can read the full story in the release notes.
As per our compatibility guidelines, Go 1.1 remains compatible with Go 1.0 and we recommend all Go users upgrade to the new release.
All this would not have been possible without the help of our contributors from the open source community. Since Go 1.0, the core received more than 2600 commits from 161 people outside Google. Thank you everyone for your time and effort. In particular, we would like to thank Shenghou Ma, Rémy Oudompheng, Dave Cheney, Mikio Hara, Alex Brainman, Jan Ziak, and Daniel Morsing for their outstanding contributions.
To grab the new release, follow the usual installation instructions. Happy hacking!
Thanks to Renée French for the gopher!
14 March 2013
In July 2012, Rob Pike and I presented a talk at OSCON titled The path to Go 1. In it we explain how Go 1 came to be, and outline the process by which Go was refined and stabilized to become the clean, consistent programming environment that it is today. We present the major highlights of the release and discuss the details behind some specific libraries and tools.
The slides for the talk are available here.
It's almost a year since we cut Go 1.0 and we are now busy preparing Go 1.1. The release will include performance improvements to the gc compiler, garbage collector, and goroutine scheduler, some standard library additions, and many bug fixes and other improvements. Stay tuned, as we hope to release Go 1.1 in the coming weeks.
See the index for more articles.