Rob Pike: Thank you very much. Oh, I have a very big voice. I'm not used to sounding
that big except in my head. I'd like to change the subject
a little bit and talk about why we're doing
what we're doing here. There's not enough time
in a keynote and it's not really appropriate
to reintroduce the wholelanguage, so I thought I'd talk instead about
why we thought it was worth doing. Here's a quote by Dick Gabriel
and I apologize for, I'm gonna actually read it
because it's really important. "I'm always delighted by the light touch and
stillness of early programming languages. Not much text,
a lot gets done. Old programs read like quiet conversations between a well-spoken research worker
and a well-studied mechanical colleague, not as a debate with a compiler. Who'd have guessed
sophistication bought such noise?" I resonated when I heard that. I thought that was a very concise
description of what I think is wrong in a lot of the software
world we're in right now. I'm not sure exactly
what Dick meant, but I have a pretty good idea. This is one kind of sophistication. This is a paragraph from
the C++ OX draft Standard, and what it describes is what function
you're supposed to call when you see the name of a function. That's a little more sophisticated
than I'm prepared to deal with. It seems like it shouldn't be that hard
to describe something so straightforward. Another kind of sophistication is that
C++ doesn't have garbage collection, at least as part of the standard language because it's apparently
more sophisticated not to. And so, we have to choose which of
these seven Boost templated pointer types we're gonna use in order to
manage our memory for us. And again, this is a little
too rich for my taste. I think things have gotten a bit
too sophisticated for anyone but the most expert programmers. And OK, those are both C++. Maybe it's too easy a target. It's a complicated very large language, but it's not the only language out there
that causes issues for people. Here's some of the noise that
comes with this sophistication. The first one is someoneís chat status a friend
noticed online once a few weeks ago. And I'm sure exactly what it says,
but I think that's the point. And I'll just quote that his response
to this somewhat garbled declaration is "Dear God, make it stop." And then at the bottom, this is actually a simplification
of an example because the real example was far too
large to fit on a reasonable line of text. Somehow if you have to foo that off, somebody's not foo-ing right. Why do languages look like this? I mean, the languages I'm talking
about of course, are C++ and Java. They're not the only language
in the world, but they are very important languages and they're primarily, particularly Java, the dominant language of education. So, how did we get here? How do we have stuff that
like this happen in what is essentially the standard way
of computing as taught in our schools and, to a large extent,
is used in industry? So, I'm gonna give you a short
version of my take on this, my version of history. It's personal. There's a lot of detail missing. It's probably wrong in a lot of ways, but this is what I think happened. I think C and UNIX became dominant
particularly in research and academia; a little later in industry. And C was not the language
that everybody wanted to use. It was a little low-level. It was successful partly
because of its simplicity, but people wanted richer stuff. And so, Bjarne Stroustrup took some of the
ideas from Simula and grafted them onto C
to create C++, which made it possible to have a high order and more sophisticated
in both senses, language available on Unix. And so, C++ became a standard language for developing large software
in research and academia. But then, because that was what people
were supposed to be educated to learn but it was very difficult, once Java came along
as essentially a simplified C++, Java became the standard
language for teaching. And so today, when we interview
people fresh out of school for jobs, they tend to be very good
at Java programming and they think that the way
that those languages make them think is really the right way
to think about software. And I disagree with that. I think these languages
are too hard to use. They're too subtle. They're too intricate. They're far too verbose. And both their subtlety, intricacy, and their
verbosity seems to be increasing over time. They have a standard model
of programming, which is a very successful
and a very good one, but it's not the only one that
people should know about. It's not necessarily the best model, even for object-oriented programming
to think about this class-based stuff. And in fact, I think it's oversold. I think it's used far too broadly and it doesn't solve every problem
particularly well. It solves a lot very well,
but not all. And evidence that it's not perfect is we tend
to graft theologies on top of the model and create things like patterns. And well, people love patterns, but I think the idea of a pattern is, as Peter Norvig has expressed
very well, just evidence of a failure
in your notation. Thirty years ago a subroutine call,
no, maybe 40 years ago, a subroutine call was a hard
thing to think about. And if we had the terminology then, we would've called it a pattern. But now, a subroutine call
is a standard part of a language and we don't think of it that way. And I think the object-oriented
pattern community has missed the fact that if the languages were any better, we wouldn't be even talking
about those things. We would just be using them. Programming has become very
bureaucratic with these languages. Every step in the program
has to be justified to the compiler. You do this repetition. You say the same things
over and over again. And I think part of what's happened
is that repetition has become confused with
a kind of safety and security. It looks like it's gotta be right if you gotta insist that this is
really foo we're talking about here. Then, you know that it's the right foo
and it's all gonna work. But your programs become
looking very, very ugly. This is an example. This is a real example, dramatically reduced I might add, that we found on a code search
on a very public place. This is not some fake code. And I'd like to point out that this
is very repetitive and very silly. And I'm gonna be a bit facetious here, but for instance, you see the phrase "new Integer (80)." Well, one might ask, "What was wrong
with the old integer 80?" [laughter] And there's a Boolean.TRUE because presumably there's
a non-Boolean TRUE somewhere and we don't wanna get confused. Now, as I said, that's facetious
but there's something wrong if you have to write code like that. It's not reasonable to have to explain
which "80" you mean, or which "TRUE" you mean. Or even why it takes so many
characters to build a table. Why isn't it just a data declaration? I mean, what's going on here? Well, this is the look of
industrial programming. This is what it looks like
if you work in a big company. This is what--. And I think people have convinced
themselves that if you're typing all this stuff in,
it must be good. This is real. This is robust. And there's no question that it works, but there's something wrong with it. Why don't the languages help you
not have to do this kind of stuff? How did we get to this kind of situation? Well, somehow it's become this institutionalized
bureaucracy about programming. And yet somehow, I don't wanna sound too negative, these languages are very successful. And they're very powerful. And they're very useful. So, there's good stuff in them. But somehow, we've lost
sight of the picture. I think this is the main point
I wanna drive home here. Because these languages
are so clumsy, they cause a reaction. And a lot of the common language, particularly in the Open Source
community that people love to use, Python, Ruby, JavaScript,
things like that, are very different in character. And I think it's partly because they're
rejecting this standard approach. And then some secondary languages
that are more rigorous and beautiful like Haskell and Scala
and things like that, have a similar kind of--. They have a different nature
in their reaction to this. And so, recently as the emerging
languages camp today has shown is this renaissance
in language design. And I think it's partly in response to how unpleasant these other
languages are to work in. And there's a real thing going on here. These outsider languages,
for the most part, are interpreted and
they're dynamically typed. And the languages that we're trying
to displace with them are not. They're compiled and
they're statically typed. And because of that, I think there's a confusion
in the programmer community of a real difference here
that isn't true. I noticed in an emerging
languages camp yesterday, everyone got up
and they basically said, "Hey, my language is dynamic. This is really good." Well, dynamic itself is a good idea, but dynamic typing is
not necessarily good. And what's happened is there's been
a confusion developed that over here we have the dynamic, interpreted languages. They're nice. Over here we have the compiled,
static languages. They're bad. And that's a false dichotomy. So, these languages,
these standard languages, are very strong. In the hands of experts,
they do a really good job. There's no question about it. But they're hard to use. The compilers are slow and fussy. They take forever to run. The binaries are enormous. Programmers really don't like
to use them for the most part. They're also very old and they don't reflect a lot of modern
hardware and modern software that, things that we've learned
in the last ten or twenty years. They're not even very good
on multicore machines. And so as a result, people have run away from them and have used these new dynamic
languages, which are a lot more fun. But those languages in turn,
because of this false dichotomy, tend to be slow, they're not type-safe, which means you get static
errors at runtime which you should really be able
to catch at compile time. And they don't scale very well. And plus, they don't have
the modernity either. And so, I argue there's a niche. There's room for a language to succeed
in a place that dispels this dichotomy and gives you all the good things of
the statically-typed compiled languages and all the good things of the dynamic, interpreted languages. To do that, it's needs
to be easy to understand. It has to be statically-typed. It has to look good on the page. It doesn't have to look like
a credit card application. It needs to be very fun to work in. It has to be easy to write
code quickly, scale very well, and not depend on tools for success. I mean, to be honest, if you're working
in Java and particularly C++, you tend to live inside an environment that makes the language a lot more palatable
by filling in the forms for you. And we shouldn't need them. They're great to have. But you shouldn't need them
for everything you do. And also, it needs to be more modern. It needs to be able to
deal with modern hardware, have good networking capabilities,
understand multiprocessors, make it easy for programmers
to use with modern hardware. And of course, Go programming language
is an attempt to fill that niche. And as I said, I don't have time
in this talk to go through it all, but there's lots of stuff on the web
and I'm giving a talk a little later. So, very, very quickly, what is Go? Go is an attempt to combine
the safety and performance of statically typed compiled language with the expressiveness
and convenience, and the fun, of a dynamic typed interpreted language. And I think it succeeds. You'll have to judge that for yourself. But also, as part of the design, it's intended to be suitable for modern,
large-scale systems programming-- things like browsers,
web servers, real code, even compilers and stuff like that. And how does it do this? Well, it's a good, general
purpose language. It's nice to work in. Just take my word for it,
or better yet, try it for yourself. It's got a very concise impact. It's got an interesting,
but very expressive type system. It's object-oriented, but in a very different way from the
type-heavy model of Java and C++. It has very strong support
of concurrency, so it works well in modern equipment. It's garbage collected. The compiler is very, very fast. Some people are startled by
how quickly it can be compiled. And because it is a compiled language, it runs fast. So, a lot of Python users, for example, say that it feels
as nice to use as Python, except the resulting program
just runs so much faster. But you get the best
of both worlds there. And of course, really important, it's entirely an Open Source
implementation. So, I have a talk coming up
after the break downstairs. And I invite all of you who can fit to
come and hear me talk more about that. But for those of you who can't
make it there and others, golang.org has a lot more information. Thank you. [applause]
00:12:27.333,00:00:00.000
Anyone have a link to his go talk afterward?