ANDREW GERRAND: Hi everyone. My name is [INAUDIBLE]. [INAUDIBLE], I'm here with the
Go Team, and for those of you that don't know, [INAUDIBLE] at Google, and I'm joined
by [INAUDIBLE] 2009 [INAUDIBLE] version 1.0, which is a version
that will be supported for years to come. And I'll just get everyone to
introduce themselves, starting from the left, and a bit
about what they do. BRAD FITZPATRICK: I'm
Brad Fitzpatrick. I work on the standard library
and libraries within Google, and miscellaneous bugs
and whatever. KEN THOMPSON: Hi. I'm Ken Thompson, and-- [APPLAUSE] --and I'm semi-retired. I worked on Go until the public
release in November and a little after that, and
now I'm having fun. ROB PIKE: I'm Rob Pike. I work mostly on the libraries
and help with documentation and basically make trouble. ROBERT GRIESEMER: I'm
Robert Griesemer. I wrote part of Go Doc and Go
[INAUDIBLE], and worked a little bit on the spec. ANDREW GERRAND: He
wrote the spec. DAVID SIMONS: I'm
David Simons. I worked on the Go runtime for
App Engine, and a bunch of other things in the standard
library and inside Google. ANDREW GERRAND: And I'm
Andrew Gerrand, and I'm a developer advocate. I'm sort of public interface
to the Go Team at Google. And so without further ado,
I'll just invite people to come up to the mics. Nigel, my glamorous assistant,
it's also a member of the Go Team, and he's going to read
some of the questions from [INAUDIBLE]. Oh, yeah. I should mention the other
important members of our team like Russ Cox and Ian Taylor-- Ian Lance Taylor-- who couldn't be here today, just
do really great stuff and I wish they were here with us. NIGEL: Let's do a couple
questions from the [INAUDIBLE]. So the first one is, what is the
core Go Team spending most of its time on-- I'll start again. What is the core Go Team
spending most of its time on since the Go 1 release. What sort of things can we
expect in the medium term, say six months? ROB PIKE: Mostly the Go 1
release formed a boundary for stable language that we knew
we could sort of depend on. And so now we're focusing more
than we were before, although certainly not exclusively, on
more internal development, trying to get some Go
development inside Google, because we made the language
to help make Google more productive and helpful
internally. So there's been a
shift of focus. I wouldn't say it's a majority
time, but a lot of us are working more exclusively
on internal stuff. The longer term, there's a
bunch of stuff coming. We'll probably do a Go
1.1 release maybe sort of end of year-ish. Do you want to talk
about that? ANDREW GERRAND: Yeah, by the end
of the year we would say. ROB PIKE: And that'll include
a bunch of performance improvements. We've got some pretty amazing
compiler changes that have given remarkable speed-ups
to some programs. The libraries probably won't
change all that much for Go 1.1, we might add a couple
of minor things. The thing is once you commit to
a library, you've got to be sure it's right, and we really,
really care about getting the APIs right, so I
suspect there won't be a lot of API changes until we're
absolutely convinced that that's the right model. That's sort of a bigger thing
than a point release. There's some garbage collector
changes that will make it significantly more efficient on
parallel execution, and a precise collector is in the
works that will make 32-bit collection much more effective
and therefore eliminate that one sort of sore spot. ANDREW GERRAND: We're also
hoping to promote some of the other operating system ports,
like the OpenBSD, NetBSD ports, and then there may be
another one, to that fully supported status. Currently there's only FreeBSD,
Windows, Linux, and [INAUDIBLE], and so they should
be in 1.1 as well, depending on the [INAUDIBLE]. Oh, and there may be some
scheduler changes as well, but we're not sure how
they're going. But the long and short of it
is 1.1 is really about tightening the screws and making
things faster and more efficient and more reliable. We're not looking at any
language changes at all until Go Version 2, and we're not
sure when that will be. So we don't have a long-term
roadmap for the project at the moment. We're really happy to be a
position where we have something that we think is
really great, really solid, and a great platform for which
you guys can use to build reliable software. You can get up and ask
questions as well. Let's take another
one from Nige. NIGEL: I know it's been asked
before, and probably again recently, but do you
have any news or plans about Go on Android? ANDREW GERRAND: No. ROB PIKE: Clap? NIGEL: What feature or design
decision on Go had the most surprising impact, or
changed the way code was written the most? Defer, interfaces, reflection? KEN THOMPSON: In just volume of
code, I think it's slices. I think they turned out
to be very nice. ROB PIKE: Ken designed the
slices, by the way. I should mention that Robert
and Ken and I, who were the original instigators of all
this spent probably a year trying to figure out how arrays
would work, because we knew we wanted some sort of
variable-sized array, but we also knew we wanted fixed-size
arrays that were statically checked, and we had these things
called open arrays, I don't remember how
they worked. But it was a real struggle, we
spent a long time, and then Ken walked in one day with this
slice idea, and it wasn't clear it was the right answer,
but as soon as we started using it, it was obvious. I would add, I think that
there's sort of two parts that question. One is, what made existing Go
programs change, and I think slices are definitely
the answer there. As far as how I think about
programming is different, for a lot of people, it's the
concurrency stuff, but I've been using concurrency longer
than some of you and so it wasn't as big a deal, although
I love having it. For me, the whole idea of
interfaces profoundly changed how I think about software
development. The idea that a program is
composed of these things that stick together feels so
easy to work with. It just changes the way software
gets constructed, it changes the way libraries get
built, and for the sort of day to day programming I do, I
think they're the biggest single thing. MALE SPEAKER: Anybody else? ROBERT GRIESEMER: Yeah. Maybe the fact that a package
file can just be a single file as opposed to two files where
one is specifying what you export, as is still the case
for the standard systems programming languages. I think that reduces your number
of files there by a factor of two, and also makes
it much easier to maintain your code. ROB PIKE: I also remember that
when we changed it so that all of the globals in your package
could be declared in whatever order you wanted, you didn't
have to predeclare, Ken came in one day and he said,
this is the best decision we ever made. ANDREW GERRAND: Yeah, I would
go further and say that the entire way packages are
arranged, where you can have packages that consist of
multiple files and it's all kind of fairly loose, has really
made the process of building software from the
ground up much more straightforward and fluid, and
I feel like refactoring and everything becomes really a very
minor deal, whereas it can be very difficult
in other languages. Hey Bob. BOB: Hey Andrew. You talked about improving the
scheduling of Go routines. I'm wondering if you can discuss
it, what type of internal discussions you have of
how to improve that type of schedule without writing a
operating system on top of an operating system. ANDREW GERRAND: It's actually
been an external discussion on the Go lang dev mailing list. One of our prolific
contributors, Dmitry Vyukov, who we should thank profusely
for his great work on improving the efficiency of
the runtime, he actually posted a proposal for a revised
scheduler and that's what's been under discussion. So there's kind of tentative
plans there, but I won't go into it now, but if
you're curious, it's all there online. BOB: Thanks. ROB PIKE: I would like to just
add that you kind of do have to implement an operating
system above an operating system. That's really what the runtime
is, and what it's doing is it's changing the primitives
you have that the operating system doesn't give you. The main thing that Dimitri is
doing, he's trying to speed up by structuring it differently
and thinking about scheduling things in a different way, and
I think it's a big deal. The thing he's not doing, which
I think needs to be done at some point, but it's very,
very difficult to do well, is some kind of preemptive
scheduler. The current scheduler will
schedule a particular thread, or therefore, Go routine only
at communication points, locks, system calls,
things like that. So if you have an infinite
loop, it will never yield the processor. If you're running on multiple
processors, if your program is truly parallel, then you
can get them to execute independently, but the load
balancing doesn't work right unless there's some sort
of preemption. So I think preemption has to
happen, but it's a very difficult subject and we haven't
done it yet because we've been worrying about
other things. It doesn't have a huge effect
on things like correctness, but it does mean you can
do a much better job of managing resources. But we don't have it yet. AUDIENCE: So I know this was
covered a little bit in the previous session, the
concurrency and synchronization features of Go
channels, but it seems to me that it supports really one
paradigm or one pattern of concurrency, which is really
produce a consumer framework, and I guess you could also add
semaphores if you look at the queue length as a
synchronization feature. I'm just wondering if anyone has
done a survey of a number of design patterns in
concurrency, such as the ones in Java.Lang.Concurrent or some
other large library where there are a lot of different
design patterns for concurrency, to see if any of
those should be implemented as higher order features on top of
the mutexes and semaphores that are provided
in Go libraries. So basically the short form of
the question is, is it true that really, we're just
looking at produce and consumer relationships
with Go channels? And the next question then is,
should there be some higher order features built on top of
the semaphores and f that are the low level synchronization
features that are provided in the libraries? BRAD FITZPATRICK: Well, there's
some things already there, there's like Sync Week
group, which is like CountDownLatch in Java or
whatever, and it's also pretty easy to build your own
primitives on top of those. We have a library that I use in
a lot of my servers called Single Flight where if you have,
let's say, a web server, and three people come in roughly
at the same time and they all want something
expensive, I have just a little function that latches
onto existing requests that are in flight, and then
multiplexes the answer out to everyone. It's a tiny amount of code, but
that's a primitive you can build using existing
Go routines and channels and stuff. There could probably be a
package like SyncUtil that puts a lot of these patterns
into a library, but outside of like Wait Group, there's not
too many of them right now. ANDREW GERRAND: I think also
part of the issue is that because these primitives are so
easy to write, we've sort of shied away from including
too many of these tricks in the standard library because
everybody's need is subtly different, and if you just write
the code yourself, you have total control over
the intricacies of the particular piece. AUDIENCE: Although most people
shouldn't be writing that code, right? Most people shouldn't
be writing low level synchronization primitives
if they want their code to be safe. I don't trust most programmers
to write that sort of code. ROB PIKE: I actually take
objection to that. I think in the last talk,
I showed a lot of really interesting examples that
didn't have low level synchronization of any kind. And part of the whole point of
the design of Go's concurrency is that it's not low level. And I don't object to having
low level synchronization primitives where they're
necessary, but Go takes a pretty firm stand that you can
think about large scale concurrent programming with much
higher level, easier to reason about, primitives. And I think you're being a
little contentious on how you're describing that. I'd also like to say that
saying that the channels promote a producer consumer
model is OK, but you can do other things with it, too. I mean, the whole idea of a
channel on a channel doesn't map into the idea of a producer-consumer kind of thing. There are really rich models
that you can build with these that don't have the flavors of
these words you're using. That said, I completely agree it
would be fantastic to have libraries for some of these
larger level things, but I would make the libraries not be
things like semaphores but things like multiplexers, and
load balancers, and that kind of thing, much higher level
rather than just one level up from the locks and
things like that. AUDIENCE: Right, thank you. DAVID SIMONS: I'll just add to
that that it's also sometimes a trap that new Go programmers
fall into where they try to map concepts from other
languages too directly when they start to write Go. So that can be very easy, if
you're familiar with, say, writing concurrent coding in
Java, to come over to Go and immediately look for
all the things from java.util.concurrent in Go to
pretty much write exactly the same code, just with
Go syntax. Part of the appeal of Go is that
you can structure your program in a very different way,
something that could be a lot more natural or decomposing
to Go routines, because Go routines
are efficient. The more mappings that you
provide, the easier it is for people to not take a sit back
and rethink how they've structured their code. AUDIENCE: In broad strokes, can
you tell us a bit about the problems that led you to
create Go in the first place, and then how your goals have
changed for Go as it's got more real world adoption
and gotten out there. Are they still the same, or
has it evolved a lot? ROB PIKE: I actually give a
talk just last week on-- ANDREW GERRAND: Do
you have it here? You could just-- ROB PIKE: Give the talk, yeah. I mean, it's kind of a cartoon
answer but it's fairly accurate that we were doing a
lot of C++ development, and the joke, but there's a grain
of truth in it, is we got tired of waiting for
the compilations. We were building these massive
binaries on massive compute clusters and it was
taking over an hour to build a binary. And we thought, why is this the
case when a video game can generate 100 frames a second? What's wrong with our world? And we thought about the kind
of software that we build, which is basically web servers
and back ends, and that's one branch. But then we also thought about
why these things take so long. It's mostly because of the
dependency hierarchy. And in C++, to a much greater
extent than Java, say, the dependency hierarchy is
very uncontrolled. You include a Header file, but
you don't know whether you need it or not, unless you
take it out and find it doesn't compile anymore. With all the ifdef guards and
nonsense like that, it's possible to have complete
uncontrolled dependency stuff, which causes things to be
built many, many times. Mike Burrows, who built the
Chubby server, was waiting for a build one day-- we
spent a lot of time waiting for C++ builds-- and he noticed a file went by
that he didn't understand the need for in his binary, and so
he looked into it, and it was a file he'd never heard of
in a package heap that no business being linked in, and
the header files being compiled 37,000 times to
build [INAUDIBLE]. And you laugh, but that's what
happens when the model is, you use ifdef guards to protect
your dependencies, and you just include everything and let
it build, and it becomes this incredibly dense nest
of too much work. So a key driver behind Go was
making that not possible, fixing through the language the
dependency problem, having totally clear dependencies,
rejecting unused imports, making the dependency problem
solved by the compiler. And there's a key point there,
which we've talked about in talks before, which is you have
a Package A that depends on a Package B that depends on
a Package C, but A does not itself depend on C directly-- so A depends on B and B depends
on C. To compile A, you should not have to compile
C along with B. So once you compile B, it pulls up all of
the information about C that it needs into its object code
so that when A runs, it says import B, all it has to read is
B. And for the three steps, that's obviously a trivial
thing, but when you have thousands and thousands of
files, that can save exponentially in the number of
dependencies you have look at, and I mean exponentially. And so Go builds take a fraction
of a second, partly because the compiler's fairly
quick, but mostly because the dependency problem just doesn't
exist in the language, and that was a really, really
key part of it. AUDIENCE: And is that still
what you see as the most important problem today
that Go solves? KEN THOMPSON: For me, the reason
I was enthusiastic about Go is because just about
the same time we were starting on Go, I read or tried to read
the C++ 0x proposed standard, and that was the convincer
for me. BRAD FITZPATRICK: The thing
I like about it is you can actually find the code. I read C++ code, even code I
used to write, that I wrote, and I just try to trace through
it, and it's bouncing around dozens of files, dozens
of callbacks, and I like being able to read code that
reads top down. I've been porting a lot of C++
code at Google to Go, and it gets substantially shorter and
readable, and we can see the logic finally, whereas it used
to be spread over so many files that you couldn't actually
get the high level picture of what your
server was doing. ANDREW GERRAND: And as somebody
coming from a different angle who-- I don't have a C++ background at
all, but I worked mostly in more dynamic languages like
JavaScript and Python, and what I love about Go is that I
can write the software that I want to write with high
performance which is not really verbose code. It's very simple to understand,
and the code that I read on the page is the
code that is executed. When I iterate over a slice,
there's not some chance that there's an iterative
implementation that fetches a file from a web server in
Romania and serves me some JSON or something. Instead, the language is very
deliberately simple and contained so that it's very easy
to reason about code that you're reading. And as programmers, we tend to
spend way more time reading other people's code than writing
code, and I think that speaks to what Brad is saying is
that if you dive into a Go project like the Go standard
libraries, it's very, very accessible, and more accessible
than any other language that I've worked in. BRAD FITZPATRICK: It's
also nice to be able to block for a change. When you come from writing
servers where it's all callbacks and callbacks and
callbacks with no JS code or whatever, where every line of
your code is indented a little bit more, another anonymous
function, another, it's nice to be able to be like, oh, I
can write to the network there, and I can wait however
long it takes, however slow that client is, and then I go
to the next line of code. I don't have to name that,
I don't have to name that lambda, I don't have to
name that callback, I just write code. ROBERT GRIESEMER: I have written
a lot of C++ code in my previous life, and I think
you can actually write quite nice code in C++, but you have
to be incredibly disciplined. And almost every company that I
know, they have an internal style where they just use
a subset of C++, because otherwise, they just can't
control their code. And so even if you're very
disciplined, if you make an error, it's incredibly difficult
to find them. Now in Go, it would be really
nice, I thought, if we had a language where these things
are simply not possible. And the fact is that all or many
of the ideas that we have now in Go actually existed
a very long time ago. Rob Pike pointed out many of
the concurrency ideas, they were invented 20 years
ago, 30 years ago. The ideas about how you organize
packages, they go back all the way to [INAUDIBLE]
and the [INAUDIBLE]. There's a lot of ideas in Go
that have been around forever in different languages, which
all for some reason or not, really made it to
a mainstream. I thought it would be
nice if we had them. I want them. AUDIENCE: Is anyone doing a-- ROB PIKE: One more point
before you go, sorry. Is this on? Robert mentioned this thing that
everybody subsets C++ so they write in their own subset
in their company. Last week Russ Cox, who's not
here joked that maybe the C++ style guide has all that in
it, but the Go style guide should start by saying, you can
use the whole language. AUDIENCE: Is anyone writing
a kernel in Go? I've always wanted to have this
idea where I could just push services out of the kernel
into user [INAUDIBLE] like a micro-kernel, and then
rewrite them in Go one at a time, and then keep going until
the whole thing was Go. ROBERT GRIESEMER: I believe
Ross actually prototyped a completely standalone
mini-kernel that was just written in Go and ran
on bare hardware. BRAD FITZPATRICK: And somebody
else ported something like BusyBox that ran as a [? nit, ?]
and so the whole userland, at least, was
Go, including the shell and all the tools. At least it was a proof
of concept. AUDIENCE: Another question just
on Amazon Web Services. Any experience, tips, tools? ANDREW GERRAND: Relating to
go on Amazon Web Services? AUDIENCE: Yes, sorry,
obviously. ANDREW GERRAND: Well, use
Gustavo's Go AMZ package for talking to Amazon. It works. AUDIENCE: Or not. ANDREW GERRAND: Or not. That may be the case. BRAD FITZPATRICK: I don't do
anything fancy on Amazon, but I run a lot of Go code on
Amazon, just on random single machines, and it runs fine,
like anything else. ANDREW GERRAND: We support
x86 hardware. AUDIENCE: So it has been said
that inside C++, there is a very small and beautiful
language trying hard to get out, and it appears that finally
it is getting out. So my question is, how would
you compare Go effort to effort by Digital
Mars and Andre Alexandrescu with [? D? ?] ROBERT GRIESEMER: I don't know
what I should say here. I attended a D talk a couple of
months ago, and one of the questions that was asked about
D is, what happens if a new paradigm comes along? Is D going to incorporate it,
and the answer was yes. I cannot speak for the D
developers and inventors, of course, but my impression from
this presentation was that D is going to grow very, very
much the same as C++ has grown, and I think in Go, we're
tried to do a completely different approach. We're trying to take things
out as much as we can, to reduce them to the bare bones,
the absolute minimum that you need to build everything up. And if those little pieces are
orthogonal and work well together, you actually get
something that is more powerful than when you have a
lot of features that kind of all scratch each other a little
bit and then have very weird side effects that are
difficult to understand. AUDIENCE: Thank you. ANDREW GERRAND: Maybe you guys
can speak briefly about the design process of the language
as well, if you want to. ROB PIKE: It was interesting,
for this talk last week, I did some archaeology, and I found a
Mail message from the first week, actually a thread
with the three of us talking about it. And it was remarkable to me how
much of the flavor of the language emerged in those
first conversations. We knew what we wanted, and
fairly quickly converged on a rough approach to what
was going on. I think one of the most
important things about Go in its design is that Robert
comes from a very object-oriented, Smalltalk,
Oberon kind of background, Ken is Unix and worked on C stuff
and things like that, and I have this concurrent point
of view about everything. And so we have three completely
different worldviews, and to design a
language with three completely different worldviews, one thing
you do is just put all the ideas in, and whoo,
and you get something. But instead, what we did was
make sure that every single feature that went into the
language went in only when the three of us agreed that it was
the right feature and the right design for that feature,
and I think that's a really important part of why Go works
so well despite being a fairly simple language, at least
in broad strokes. Do you agree with that? ROBERT GRIESEMER: Yeah, I
would agree with that. I want to say one thing. I think it was an incredibly
hard process. I think there were several times
where I probably yelled at Ken Thompson, and then I
would go back in my room and said, hey, you don't yell
at Ken Thomson. ROB PIKE: Did you yell back? KEN THOMPSON: No, no. I remember one instance, and
basically, it was almost the first day when we wrote a big
list of things on the blackboard, and there was one
question that we spent maybe 10 seconds on. Should the declarations be
C-like, like inside out, or should they be Pascal-like,
left to right? And we said Pascal-like,
and that was it. And from then on, decorations
were in, and-- MALE SPEAKER: Best
decision ever. KEN THOMPSON: But one that early
on got a lot of flack. AUDIENCE: I think it was
definitely the right decision. NIGEL: The next question from
the moderator, what has the biggest mistake in Go's design
turned out to be, and how have you worked around it? Is there a billion dollar
mistake in Go? ANDREW GERRAND: So the billion
dollar mistake I guess refers to [? null point ?], and yes, Go
has [? null pointers ?], so we have the billion dollar
mistake in Go. ROB PIKE: And some people don't
like it because of that. I don't think it's a billion
dollar mistake, but what do I know? Mistakes. I wish that some of the syntax,
it was a little simpler in a few places. I think there are too many ways
to declare a variable, and there's this whole shadowing
nonsense and so on and so on. But I don't think there's
a huge single thing that I feel is wrong. Part of the Go 1 process was
actually going through all of the things that were bugging
us and fixing them. And so a year ago, the
language looked quite different from it does today,
but we fixed a lot of it, and a lot of stuff got cleaned up,
and that's precisely what the Go 1 release process
was all about. So we fixed the things
that were bugging us. But for biggest mistake in the
language, I don't know. [INAUDIBLE]. MALE SPEAKER: There's the
scoping of loop variables is kind of confusing to
a lot of people. ROB PIKE: Scoping for
loop variables. That confuses people. I think it's fine, but I can see
why a different decision would also be fine. But this is the kind of thing
you can't just change. Once you've decided people using
your language, you can change the semantics of a for
loop, that's kind of scary. ANDREW GERRAND: That's the one
that I regret, but the reason why we decided not to change
it is because it would have been incredibly subtle to detect
when people were using it [INAUDIBLE]. AUDIENCE: So what led to your
design decision, in the formatting of Go code, the
conical formatting, to use tabs instead of spaces? ROBERT GRIESEMER: Good taste. KEN THOMPSON: If you read the
ASCII spec, it says a tab is some number of spaces that set
the tab stops, and so it just appears that that's the
definition of what you want there, instead of saying
five tabs or eight tabs or two tabs-- spaces, excuse me-- the answer is a tab. It's the definition. ANDREW GERRAND: [INAUDIBLE] your
editor render it how you want it to look. ROBERT GRIESEMER: I wrote Go
[INAUDIBLE], and the reason for writing it was unrelated to
this, it was just everyone wanted to get rid of some silly
discussions about how you format code that
just consumed time. But then when it comes to
indentation, I thought, everybody has a different style,
and ideally, it would be great if everybody could just
look at the code the way they want to look at
it in their editor. And with indentation, it's
a very contentious thing. Some people really want a lot of
indentation, some are happy with two spaces or
even one space. And the fact of the matter is
you get used to everything. But with tabs, you at least have
the chance to actually change it in most environments
to be a different size. And the idea was that by doing
that, you have a chance to actually adjust it to
your personal needs. Now it turns out,
I think that's probably not true in reality. People don't really
change that. ROB PIKE: That's not true. I know Ken uses eight-space
tabs and I use four-space tabs. ROBERT GRIESEMER: OK,
there you go. Even within the Go Team,
everyone I think uses a different editor and everyone
has different preferences on syntax highlighting or
fixed-width fonts versus variable-width fonts, so I mean,
it's not like we're very religious one way or another,
we just use what we want to use. ROB PIKE: The most important
thing about Go [INAUDIBLE] is not the choices it makes
but that it makes them. The fact that there's a program that formats the code-- I actually would publicly like
to thank Robert, because I think he did an amazing
job on Go [INAUDIBLE]. It is an incredible tool. But it also enables
things that we didn't realize upfront. Because what [INAUDIBLE] does,
it reads your entire program, parses it into a full Go
syntax tree, and then reformats in, or maybe
just leaves it alone, but it depends. But because of that ability to
pick up a tree, a syntax tree of a Go program, and generate
human, readable, commented, neatly laid-out code, we can
write tools that do things to your Go program that would
be very difficult to do automatically, like the Go Fix
tool that will go in and rewrite your program to bring
it up to date to go on spec. That would be almost
inconceivable if we didn't have an automatic
code formatter. And it's such a powerful idea
that we're starting to think about doing it for some
of the other things. You can imagine a Make File
version of Go [INAUDIBLE] that would let you edit your Make
Files automatically, or conceivably, other languages,
Java would probably benefit from that kind of thing. Being able to rewrite your
program and generate human, readable output wasn't the goal
of Go [INAUDIBLE], but it turned out to be one of
the most important properties about it. And if you get tabs instead of
spaces, I think that's a small price to pay. KEN THOMPSON: For me, before
Go [INAUDIBLE], there was continual wars about whether
curly braces were at the end or the beginning, or all
sorts of things. And while at the time that Go
[INAUDIBLE] was written, I didn't agree on all the
decisions, but now, there's no wars, there's no arguments, it's
just the way it is, and that probably saves half of the
discussions that go on at Google over C and C++. NIGEL: The next question is
about what's happening with garbage collection over the next
six months or so, but I think we covered that earlier
with the roadmap. So the next question after that,
are there any plans to distribute Go Lang threads to
work across similar machines to create truly distributed
systems? If something like this should
be implemented for Go Lang, what do you see as the
challenges that should be considered? ROB PIKE: That's something
I really love to see. I think there's two
ways to do it. The way the question
was phrased was to distribute the threads. That sort of implies some kind
of process migration aspect, which is not the way that
I would approach it. A long time ago, I wrote a
little toy package called netchan, which lets you turn
a channel into a network connection so that you can have
two machines sharing a network but using the channel
primitives on either end to manage their communication. And I think that's a really good
idea but I didn't get the API right, so we pulled it out
of Go 1, and we've been talking again about what
the design for that really should be. And I think it's a really,
really powerful idea. But one of the things we want to
make sure happens when you do that is that all of those
patterns I showed you in the previous talk still work. So you should be able to send
a channel over a netchan and stuff like that. And getting that done is
actually quite subtle and difficult, but we definitely
want to see it. I can't promise any date for
it, because it is a hard problem, but it's definitely
from the beginning an idea that we had. I remember Ken and I had a
conversation sometime in the first year, we probably had five
conversations about how we were going to get channels
and networks together, and we never quite figured it out, but
we still really want to see it happen. I should mention Erlang, by the
way, gets this done, but it has a very different model. AUDIENCE: So I love Go
concurrency, but I know some problems are better solved using
GPU parallelism, and I wonder if anyone's using
GPU parallelism in Go. ROB PIKE: Not that we know of. ANDREW GERRAND: Only in the same
way that they used them from C or other languages. It's a sweet idea, the idea of
launching a Go routine that runs on an auxiliary processor
in some heterogeneous system, but it's not something that
exists now, and it's certainly a difficult problem. ROBERT GRIESEMER: So my
understanding is also that all these systems which employ
that parallelism use specialized languages for those
GPUs because the GPUs pretty much change from year
to year, or even half year to half year. So I'm not an expert, but I
suspect that if you use it, let's say from C, that you're
just invoking or sending those snippets of that
other language. ROB PIKE: My understanding is
it's actually a compiler that runs on the video card, and we
haven't yet managed to port Go to a video card, but it would
be cool if we could. MALE SPEAKER: If Russ has
a free weekend, maybe. NIGEL: The next moderator
question is about Go 1.1 roadmap, I think we covered
that already. The next one, any plans
to port Go to MIPS? A lot of embedded hardware
with network support runs MIPS, and writing network
software in Go is so much easier than in C, C++. ANDREW GERRAND: GCC Go should
be able to output code that runs on MIPS. ROB PIKE: It's already done. ANDREW GERRAND: We'd would love
to more users, so anybody who's hearing this and
has the hardware-- BRAD FITZPATRICK: [INAUDIBLE]. ANDREW GERRAND: Yeah, OK. So for those of you who don't
know, we have two compilers that the Go Team work on
actively, and there's the GC, which is the one that was
based on Ken's Plan 9 C compiler design, and that's the
one that you get with the standard Go distribution. And then in GCC 471, GCC Go will
be included, which is a front end for the new
compiler collection. And so you can compile Go for
all of the platforms that GCC can target within some
constraints, I believe. We're publishing a blog
post about this within the next week. But with GCC Go, I know people
have run stuff on SPOC systems and MIPS, Alpha, IRIX, which is
Alpha, and other operating systems we don't support,
and so there's a lot of scope there. But it's not that it's not
supported, it's that it's not been well tested, so if you have
these kinds of systems, we'd love for you to get GCC Go
and try it out, and let us know how it goes. ROB PIKE: Both the compiler
suites were written to the specs, so as far as
we know, they implement the same language. Of course, there's probably bugs
and variations, but as far as we know, you have no
problem compiling programs on either suite and have it work. AUDIENCE: So is there a plan to
add versioning to imports or external packages? ANDREW GERRAND: No,
not at this stage. AUDIENCE: Because it's kind of
hard if an external package or some library that you're using
changes API and you want to use Go Get to get that library,
and it's in a different version, you
have to jump in and get check out another. ANDREW GERRAND: Yeah, I
understand the problem, and I'm sure the other Go developers
do as well. What we're trying to encourage
Go package authors to do is maintain a consistent interface,
and if you go in and change the interface, it's
probably wise to change the import path as well, and have
a V2 of your library that supports a different
kind of interface. And that's just part of release
engineering, and I think it's something that some
parts of the open source community do well, and other
parts that are more ad hoc don't really address
very well. Brad has more experience
with this domain-- BRAD FITZPATRICK: I was just
going to point out, you shouldn't rely on
that, though. I mean, the responsible thing to
deploy code to prod is not to have a script that runs
Go Get, which could be malicious code. Maybe that GetHub author's
account got taken over or something. So use Go Get during
development, and then once you're going to ship something,
put it in your own version control system,
snapshot it, whatever. ANDREW GERRAND: Also, you don't
have to update all of your dependencies every time. The default behavior of Go Get
is only to fetch, not to update, so get it to a working
state, and then only Dash U with Go Get with care. AUDIENCE: Are there already
any backwards incompatible changes being thought of for
the fabled Go 2 release? ROB PIKE: No. But that's not to say there
won't be, we just haven't thought about it. Really, Go 2 is in the
indefinite future. It's years away. There's been a couple of ideas
that have been mentioned that might be Go 2 things, but we're
not thinking about Go 2. We're just not. We're thinking about taking what
we've built so far and using it, because the ideas in
Go 2 will be ideas that we develop using Go 1 and
finding out what we need to make better. ANDREW GERRAND: I think to
answer the question literally, I think by necessity, Go 2
would include backwards incompatible changes. Otherwise, it would just
be Go 1.something. AUDIENCE: Are there any plans
to bring a self-hosted compiler to Go? BRAD FITZPATRICK: I mean, we're
not doing it, but other people have discussed it. There's a project called LL
Go, which is a Go compiler that uses the Go AST and Go
parser and all that, and then they're fleshing out the type
checking and then they're emitting all the bit
code and whatnot. AUDIENCE: What's the reason
behind that decision? BRAD FITZPATRICK: Some guy's
having fun with it. AUDIENCE: No, I mean what's
the reason behind you guys sticking with writing everything
in C instead of moving to self-hosted. BRAD FITZPATRICK: I mean, the
pragmatic answer is there was no Go to write Go in
initially, right? I mean, look at Rust. They took a long time writing
their compiler in Rust because Rust didn't exist. It's a route, but it's just a
very slow, painful route. AUDIENCE: All right. Thank you. ROB PIKE: It's much easier to
bootstrap, both locally and to other people, if the compiler is
written in a language that everybody has. ANDREW GERRAND: Russ made a
really good point in the recent Q&A session that he did
is that if you're changing a language, or if you find a bug
in your language and your compiler is written in that
language, it can be a very, very difficult process to
correct the bug in your language and in the compiler
at the same time. You have to sort of bootstrap
the change and propagate it through the chain, and there are
people on this stage know way more about that than I
do, but it's very hard. ROBERT GRIESEMER: But also,
there is actually a significant part of a front end
in the library, and as we speak, some people in the
community are thinking about completing that part so there
would actually be a front end, at least for a compiler, where
somebody could hook up a back end if they wanted to. ROB PIKE: Go is a fine
language for writing compilers, it's just we haven't
taken it on yet. And I think maturity will
probably lead to one at some point, but we have no
plans at the moment. We're working on using
it rather than rewriting the compiler. AUDIENCE: Are there any plans
to add anything like DL Open or DY Sim to Go for dynamically loading code at runtime? ANDREW GERRAND: No. ROB PIKE: There are no plans. I will admit that although Go
is statically linked, and in the first session today,
everyone on the panel, I think, said how important that
was to their deployment. So having a statically-linked
binary is a really important part of what makes Go nice
to use and deploy. I do think there's a real merit
in having a dynamic loadable module, which is a
slightly different point, and I actually would kind of like
to see that happen. I don't think it's terribly
difficult, but there are no plans to do so. I do understand the
distinction, and it might be cool. MALE SPEAKER: [INAUDIBLE]. ROB PIKE: Does what? Where would you see Go? MALE SPEAKER: Using DL Open? ROB PIKE: I haven't tried
it, I don't know. MALE SPEAKER: [INAUDIBLE]. AUDIENCE: How large is the
largest known Go project, and the longest one running
in production? ANDREW GERRAND: YouTube's
[? vtest ?] project, which is [INAUDIBLE],
I think is in the realm of approaching 100K. That sounds a bit
high, above 50. It's hard to say because I, like
the guys that we had on the stage today, I don't know
how big their code bases are, probably sizable. But just on the weekend I met
somebody from a fairly large company who said, when he met me
and learned what I did, he said, thank you so
much for Go. We use it everywhere
in our company. And so I had no idea
they were using it, they didn't tell anybody. And so I think there are a lot
of people that use Go that don't go out and just send us
an email about it, hey, I'm using your product. There's a lot of stuff that
exists that is not out there. But certainly, we're using
it inside Google. Unfortunately, we can't go into
great detail about that. ROBERT GRIESEMER: You should
also remember that a 50K Go program is really a
100K C program. ROB PIKE: Go Doc is also quite
big and it runs in production, and it's been running
for quite awhile, several years now. The YouTube project has been
running in production for at least a year or more, long
before they open sourced it. So there's serious examples of
large programs running for a long time in production,
but I don't know what the specifics are. AUDIENCE: I'd be very surprised
if this hasn't been asked before, but given that
Ken is famous for paper reflections on trusting trust,
where you can build a compiler that builds a back door into
itself each time you compile it with itself, how do we know
that we can trust Go? KEN THOMPSON: Well, if you read
the paper, you can't. Somebody said, I think in a
[? Turing ?] lecture, not me, that the popularity of a
language is guaranteed when you get your first virus
in that language. And I've heard that the first
virus in Go has come around. ROB PIKE: We're on the
world stage now. AUDIENCE: Are there any plans
or desires to revise some of the old abandoned Go ports, Tiny
Go, Native Client, which were proofs of concept and which
were really meant to be fully developed? ANDREW GERRAND: I was going
to say, tiny was really an experiment and I don't think
Russ ever intended to take that further as something
bigger. The Native Client port of Go
was something that we were serious about at the time, but
the Native Client platform has kind of changed direction a bit,
and now they are focusing on people exporting [INAUDIBLE]
code, it's called [? Pinochle ?], and it uses an
LLVM back end to dynamically generate machine code on
various platforms. And so that would necessitate
a way of producing Go code that's in LLVM's intermediate
language, and that's something that we would love to do and
would love to see happen, but it's not something that we're
actively looking for, no. AUDIENCE: How much do I need to
pay to keep generics out of the language? ANDREW GERRAND: How
much have you got? AUDIENCE: Next question, how
close does GCC go to running in front of non-GCC back
ends like Clang? ROB PIKE: I don't know
if anyone's actually actively doing it. Certainly, one of the most
remarkable achievements about GCC Go is that it's released as
part of the GCC package but it's not under GPL. And the reason for that is that
Ian really wants to see someone build an LLVM back end,
or at least he wants the freedom for someone to
be able to do that. And we're just waiting for
someone who wants Go thinks of it as a challenge
to make it work. As far as I know, nothing active
is underway, but it would be whatever amount of work
that is, and should be fairly straightforward unless
I misunderstand something. AUDIENCE: Any plans to create
an official third party software repository like
Python, Pipel, PERL CPAN, Ruby Gems? ANDREW GERRAND: Absolutely. So there's a fantastic site at
the moment called Go Package Doc that was developed by a
guy named Gary [? Bird, ?] and it's a system that allows
you to view the documentation of any Go Package that's
publicly accessible in a web browser, and that's a real
asset to the community. And we've been talking about
taking this further and turning it into a package index
and a search engine, and we've got some really exciting
plans, it's just a matter doing it now. But I think the one notable
difference between the approach we're looking at and
the approach of things like CPAN or some of the other
repositories is that it's not going to be human curated but
rather machine curated, and we feel like that might yield some
advantages in some ways. BRAD FITZPATRICK: The other
important difference is that Go's name space is DNS,
you use a URL to describe your package. So it's not like PERL CPAN where
you upload it and you have some central group of
people that say, you're allowed to use that name. So we don't have a central
naming authority, which is kind of implicit with
a central model. So you can be GetHub.com slash
whatever, code.Google.com or whatever, and that's
your import path. ROB PIKE: And that was a very
deliberate decision for just this reason. We'd like to make it be
automated, and it's an ongoing challenge to figure out how
best to do that, but it's really what we want to see. AUDIENCE: Are there any plans
on adding the ability to call Go from C? In order for me to really use
it as a systems language, I need to be able to bind to
it from another language. Most languages have the ability
to call a C interface. ROB PIKE: You can call
one direction. BRAD FITZPATRICK: You can't
embed Go in C currently. Go needs to be main to set
things up, but it keeps coming up, and people inside
Google want it to. So I think Ian has said he wants
to make it work, and Russ has said he wants to make
it work, so it's definitely on some roadmap. I don't know. ROB PIKE: The issue here, for
those who don't know, is there's a thing called C Go,
which lets you call a C program from Go, and that
works reasonably well. A lot of people use it for
various things and some critical parts of the library
use it to do things like DNS look-ups and stuff. The problem is that the Go
runtime owns memory, owns the stack, and there's a calling
convention issue across that boundary, which means that at
the moment, you can only use it to go one way. So Go has to be running main. The piece that's missing but is
going to come, although I don't know when, is that C
programs should be able to be the main program and
call a Go library. That's the piece
that's missing. BRAD FITZPATRICK: To be clear,
you can still call from Go into C, you just have
to start in Go. You can go to C back to Go,
and that works fine. So you could make a tiny, tiny
Go program that embeds your C code as like the first and only
line of your Go program. That works, it's just
kind of a hack. ROB PIKE: Also, if C++ is the
language you want, there's the SWIG interface, Go is fully
supported by SWIG, but the same kind of constraints apply
there because it uses C Go under the covers I believe,
although I'm not sure. ANDREW GERRAND: There is some
work in the community towards this goal. I know that there's a Python
function call interface so that you can call into Go code
from Python, and it's in the early stages of its development,
but it works. So there's some momentum. ROB PIKE: And you can also call
PERL from Go, right Brad? AUDIENCE: Is there any interest
amongst the Go team in writing a new operating
system? ROB PIKE: No. AUDIENCE: Are there serious
plans to support static linking of libraries
called in by C Go? BRAD FITZPATRICK: It just
doesn't work right now, but people want it. It's just work, I guess,
not by me. AUDIENCE: Which is your favorite
misfeature in Go? By that, I mean, which feature
from other languages are you most happy Go is missing? Inheritance, exceptions? ROBERT GRIESEMER: I think I'm
happy that there's a lot of the [? 00 ?] not present that is in other
languages, because it allows you to think about your task
at hand, as opposed to the hierarchy or type system which
you then have to shape into whatever you want to do. DAVID SIMONS: I like the lack
of uninitialized variables, it's pretty good. ROB PIKE: That's not
exactly the same. I'd like to echo what Robert
said and point out that if you have a program in Java or C++,
you pretty much start by designing your type hierarchy,
and that's something you don't even do in Go, so that's
one point. But a sort of deeper point is
that it's a fair bit of work to do that, and there's a lot of
structure you have to build in order to use the types in
that hierarchy, and that means that if you find out after
a few days' work that the hierarchy's not quite the way
you wanted it, going back and changing it might not
be an option because it's too much work. So Go, by not having that type
hierarchy, makes it much easier to adapt the program as
it develops, because that structure just isn't there to
force a certain style on the rest of the program. Would you agree with that? ROBERT GRIESEMER: I think that's
exactly what happens when you write a large
piece of software. In the beginning, you think you
know what your structure, you sort of design it. It's not quite right. For the first couple of weeks,
you're going to tweak it, you're going to be a good
citizen and refactor and organize, and at some point you
hit 20,000 lines of code or whatever, and at that point,
if a bar comes up that really would require you to do
a massive refactoring, you're just not going to do it, and
your program is going to start to just look ugly and you're
going to hack it. ROB PIKE: Also, another thing
I don't miss is what I call stuttering, where the C style
of declarations maps to object-oriented programming
style, which you see in Java and C++. You get a lot of string string
equals new string kind of thing, except string is much
longer than string. And in Go, the declaration
style, this is one of the reasons we went with Pascal
style, is it gives you a chance to elide a lot of the
noise in the declarations and simply derive the type from the
expression, and that saves a remarkable amount
of typing and a remarkable amount of typing. ANDREW GERRAND: I really
appreciate not having optional arguments to functions so that
functions always have a specific set of arguments and
that's what it takes. I find in terms of readability,
that's awesome. By the same token, things like
this comprehensions, or even [INAUDIBLE] operators, these are things that
make code more convenient to write, but they make it much
more difficult to read. When I first started using Go,
I sort of found myself feeling, oh, I have to
write this for loop again, and so on. But now, the benefits have
manifested really strongly in interoperating with other
people's code. I think somebody else already
mentioned this too, but it's really empowering to be able
to put all your code in one file, and not being enforced to
have header files or have one file per class, or whatever
your import name is, have the file. Just like, you can hack
something up and then structure it later so it's
readable for other people, but you don't have to context switch
while you're writing code, jumping around files. ROB PIKE: There was a question
earlier about the design process, and another thing that
we really struggled with, but you can't tell now looking
at the language, is what a package was. There were endless debates about
the structure of package and how it went together. And it looks like it's sort of
obvious, but it was a really difficult thing to
figure that out. And maybe we were just stupid,
or maybe we were burned by using the wrong languages for
too long, but I think that is something that worked out
really, really well. AUDIENCE: What's the feedback
been from novice programmers? A lot of people using Go, and
everyone probably in this room is very experienced
in programming. But what about people new to
programming when they look at Go programs? What's their feedback been? ANDREW GERRAND: So I've taught
a bunch of classes at universities in Go, and I've
found that most people who have a very beginner level of
knowledge of programming in languages like C or Java pick
it up pretty quickly. The main stumbling block that
people who come from non-C backgrounds have is
with pointers. But I think that's just a
natural reaction when you've been using a language like Java,
which has pointers but just ties them behind the
concept of references, it's very strange to just deal
with them explicitly. But then people who came from
C who were beginners, I actually had a few come up to me
afterwards and say, wow, I actually understand pointers
now after using Go. It's so much easier than doing
it in C, even though just semantically, they're pretty
much the same. But I actually think that Go
is a fantastic teaching language, and I would love it
if universities and other training academies would take it
on as a teaching language. I think it's really well-suited
to that. AUDIENCE: In the early design
of Go, was there much consideration in incorporating
more functional language influence, something maybe
very fundamental, like a polymorphic type system, or
something a little bit easier, like having the API incorporated
[INAUDIBLE]? ROB PIKE: We had to talk
Ken into what's there. Early on, the closures
actually weren't true closures, they were just
function literals and you had to pass in all the parameters. It took awhile to convince
ourselves that we could actually do them efficiently
inside a compiled language, and there was a fair
bit of work. There's even a little bit of
runtime code generation when you run a lambda inside Go. It's not our background
functional languages exactly, I mean, I've written a lot of
LISP in my time, and I really think they're important, a
really important part of concurrent programming is the
ability to launch into little tiny computations, so it's
really important that we have the power, but the short answer
to your question is no. We didn't want to push harder
in that direction, although now looking back on it, I
kind of think we have. But I do think that what's there
is pretty expressive, because you do get true
lambdas and all that. ROBERT GRIESEMER: Yeah, I
think that's pretty much summarizing it. I think having the true closures
is a major boon for the language, and it wasn't
there in the beginning, and I actually wanted them from day
one, but we have them now, so I'm really happy about that. AUDIENCE: I really enjoy
programming with Go routines and channels, but I've also
been reading about data structures that can be accessed
safely from multiple threads in other languages. Is there any interest in adding
data structures to the standard library or to the
language that can be used safely from different
Go routines? ROB PIKE: There is a library,
the Sync Library, that lets you do the protection
yourself. I think the question you're
really asking is whether there's a notion of
immutability on the horizon for stuff? Is that what you're
getting at? AUDIENCE: Well, that's one side
of it, and there's also lock-free data structures that
people are playing with in Java and C++ that might be
interesting, like map data structures and list data
structures that could be used safely, so we don't have
to synchronize explicitly across channels. ROB PIKE: Dmitri Vyukov, who was
mentioned before, is doing garbage collector and scheduler
work, is probably as good at lock-free stuff as
anybody you might know, and I suspect in time, he will start
putting that stuff in. He's actually mooted a few
things like that already. I think there will be some
of those coming in. ROBERT GRIESEMER: I want to add,
there's also of course the lessons learned from Java
perhaps where many data structures were built from day
one so they could be used concurrently, and so they all
do locking, and it's an incredibly expensive proposition
in many ways, and it's not clear that it's the
right way to approach things. AUDIENCE: That was definitely
a mistake in Java it seems, for performance. ANDREW GERRAND: Thanks. All right. Well, we've done a full hour of
questions, which is great. Thank you everybody, for coming
along, and thanks, Go guys, for answering
all the questions.
