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