1 files changed, 160 insertions, 0 deletions
diff --git a/content/io2013-chat.article b/content/io2013-chat.article
new file mode 100644
index 0000000..9b031da
--- /dev/null
+++ b/content/io2013-chat.article
@@ -0,0 +1,160 @@
+# A conversation with the Go team
+6 Jun 2013
+Summary: At Google I/O 2013, several members of the Go team hosted a "Fireside chat."
+OldURL: /a-conversation-with-the-go-team
+
+##
+
+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.
+
+.iframe //www.youtube.com/embed/p9VUCp98ay4 309 549
+
+We also hosted a similar session at I/O last year:
+[_Meet the Go team_](http://www.youtube.com/watch?v=sln-gJaURzk).
+
+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](http://groups.google.com/group/golang-dev).
+
+As for the timeline, we do have
+[concrete plans](https://docs.google.com/document/d/106hMEZj58L9nq9N9p7Zll_WKfo-oyZHFyI6MttuZmBU/edit?usp=sharing):
+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._
+_Where is_ `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](https://golang.org/wiki/SQLDrivers)
+lists some good ones.
+
+The `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
+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](https://golang.org/wiki/Projects#Graphics_and_Audio)
+out there, and a few Go-specific projects. One of the more promising ones is
+[go.uik](https://github.com/skelterjohn/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_](http://www.gophercon.com/)_?_
+_Does anyone from the team plan to attend?_
+
+**Andrew:** It's very exciting. I'm sure some of us will be there.