hope going open source on November 10th, which is in just a couple of weeks. This talk is

a little bit before then, so some--there are some future tense for things like links and

so on, but everything should be as recorded by the time we actually go public with this

stuff. You can see we have a website we’re setting up, which will be the public domain,

public viewable domain for that. So, what is it? Well, I’m can talk about all these

pieces but it is new, an experimental, concurrent, garbage-collected, systems, language. Experimental

because we’re not--we don’t believe this is the answer to everything, but we’re playing

and we think it’s gotten to the point where it’s time we should probably tell the world

about it. It’s concurrent because it’s really important in the modern world. It’s

garbage-collected because we have an opinion on that stuff, which I’ll talk about it

quite a bit later. And it’s a systems language in the sense that we intended to be written,

to be used to write things like Web servers and other, you know, system aspects like that.

You have more control over some things and you have another languages like, say, Java

or Python, but it’s--it works like a systems language when you use it. On the other hand,

it's very good at things we find for things like front-ends or just general programming.

So, although, it’s designed as a systems language, it has much broader use than just

that. I can't give a talk without showing you, "Hello, world." There’s "Hello, world"

with the "world" being Japanese, which I want to attempt to pronounce. But you can see that

it looks vaguely C like although there’s some "weirdnesses" about it. I won’t talk

about what those "weirdnesses" are. Who’s involve? Well, I’m giving the talk but it’s

by no means my project. There’s a bunch of people involve and I want to make sure

everyone’s cleared. Some of the names are really important here. Robert Griesemer, Ken

Thompson, and I started talking about doing something to solve the problems we were seeing

with other environments. Some time around two years ago in late 2007, we played mostly

at the Wade Park for a few months to figure some things out. But by middle of 2008, we

had a toy compiler and things were starting to look interesting and we started working

on the stuff for real. And around that time, Ian Taylor joined and Russ Cox joined, and

the five of us did the most of the work, but we’ve had a lot of help from a lot of people

that this slide is too small to name. So I just make--I want to make it clear this is

a collaborative effort and the collaboration is growing. Why? Well, the reason is things

were just taking too long: too long to compile, too long to build, too long to think about.

We want a program fast. We want a program fun. And to make programming fun, you have

to find ways to speed things up and make things work better, not just the code itself but

the process of writing the code needs to be efficient. So what’s happened? Well, you

know, program used to be fun. What went wrong? Well, it’s interesting there's been really

been no new major systems language in at least 10 years or could be longer. But in that decade,

a lot has changed. The libraries have gotten bigger. Professional programming has, to a

larger extent, become a layering process, and so we layer more and more stuff on and

we also broaden out the base. The libraries got really big. There’s a lots of them.

They communicate with dependencies to one another and so the force has become a thicket,

and at some times it’s kind of hard to cut your way through it. Networking has pretty

much taken over the world, that's the way to think about computing. The old son thing

about the network is the computer is pretty much true today, but the languages don’t

really reflect that. There’s a lot of client/server kind of stuff especially in the systems base.

Languages don’t really help you there too directly. Of course, we’re talking about

massive compute clusters now and again, the languages are designed for single processors.

They don’t really work very well in that model. And on a related note, multi-core CPUs

are taking over, too. It’s getting harder to buy a high-end computer with only one processor.

It tends to be multi-core, sometimes multi-chip/multi-core. And again, the languages that we’re using

weren't really designed with that kind of stuff in mind. And it’s also gotten--I think

this is the thing that finally pushed us to try to do something. It’s just gotten to

slow to build software. The tools are slow. They have a hard problem to do, but they still--they’re

tend to be slow and they’re getting slower. The computers have speed up enormously but

the software development process, if anything, has gotten slower over the last ten years.

The dependencies are uncontrolled and the languages don’t help you control them, so

you tend to spend a lot of time maybe building things you don’t even need but you don’t

know it, can’t prove it. The machines have also stopped getting faster. They’ve gotten

more but they haven’t gotten faster. There are more processors, there are more of them,

but the actual clock speed has hardly changed in the last few years and Moore's law, to

some extent, is peering out and yet the software gets bigger and bigger and bigger. And so,

somehow, it feels like if we don’t do something, then software construction is just going to

become unbearably slower and we need to think about the process of making it fast again.

Robert Griesemer observes that a lot of the interesting work in languages in the last

few years is been because a lot of the people using these standards systems languages like

C, C++, even Java are finding the clamp--the type systems are very sort of clumsy or hard

to work with. And as they go to the dynamic languages: the Pythons, the Ruby’s, even

the JavaScript of the world, they have a lot more fun because the type systems don’t

get in the way so much at least as long as the program keeps running. And so, the challenge

here is to try to deal with this. You want typing. You want a good typing because it

makes programs robust, but it can be done badly. And we are given in some ways, there

is--if not done badly, it should at least be done the different way. Sometimes good

ideas, in principle, make bad practice. And a good example of that is the "const" keyword

in C and in C++, which was very well intentioned and seem to address the real need in making

program safer, but it tends to make programming awkward in a lot of ways, so this isn’t

worth the benefit you get back from using. Also, there is this notion of everything being

a type hierarchy in object-oriented programming. And yet, the types in large programs don’t

really naturally fall into hierarchies. We find the way to make them fit, but it’s

a bit of a struggle. In program, we spend so much time re-factoring a code, juggling

type trees around, and that has very little to do with the implementation and lot to do

with the way the language is forcing you to think. We’d like to be--we’d like to sort

of step back from that model. And in short, therefore, with the way type systems work

today, you can be productive or you can safe, but you can’t really be both. And that seems

like a shame; we should be able to fix that. So, why a new language? Why don't we just,

you know, fix what we've got? Well, some of the problems are just fundamental to the way

the languages are thinking, the way the type systems work, the way they’re compiled,

the way dependencies are managed. The languages themselves have these problems endemic in

them, and to fix them, you have to rethink the languages itself. For instance, the libraries

can’t help you, because adding anything to try to fix some of these problems is going

in the wrong direction. There’s too much already. We need to trim down, cut the fat,

and make things cleaner. Fixing it by adding software isn’t going to do it. You have

to sort of step aside and do something separate. And so, we decided: Robert, Ken, and I couple

of years ago that we need to start over. Just take a step away and think about the way programs

are written and constructed and try to make a language that makes that process a lot easier.

So, it’s a new language. What are the goals of this language? The sort of short version

of the story is we want the efficiency of a statically compiled language; that means

truly compiled language, but the ease of programming of a dynamic language. And I think we have

come pretty close to achieving that. You can decide for yourself as we go on. Safety is

critical. It’s critical to the language: the type-safe and then the memory-safe. It’s

important that a program not be able to derive a bad address and just use it, that a program

that compiles is type-safe and memory-safe. That’s a critical part of making robust

software and we just--that’s just fundamental. We want good support for concurrency. I’ll

talk a little bit about that. Communication, I’ll talk about that, too. Those are tools

that can help you build software that runs in the network or in multi-core CPUs. We want

to build--we’re going to garbage like to think, because a lot of the bookkeeping that

goes on inside modern programming, especially in C and C++, has to do with memory management.

And that can be totally automated. And we believe, "believe" is the word, that you can

do that efficiently and, essentially, latency-free that the garbage collection technology is

advance to the point where a garbage collected systems language actually makes a lot of sense,

and so we’d like to do that. And also, we’d like the compiler to just run fast. Everyone

knows this slide and there’s some truth to it. You know, you spent too much time waiting

for compilers. So, let me give you a compilation demo here. This is a directory of Go code. If you look

in here, there’s a 1,300 lines, so I make clean, and then I’ll just do a major. There,

I just built the last library. That’s compiled, efficient code, clean again. In case you wonder

if I can type, okay, time make. Okay. So that’s what two--well, pretty accurately, 200 milliseconds

real time to build the library. That feels about right. For the last years or so, those

who’s working with Go had been getting used to 100 millisecond builds on one machine.

That’s running on my laptop, by the way. That’s not some distributed thing. That’s

one processor, one build. And just to prove it a little better, let me make clean. This

is the complete Go source tree. All of the libraries written in Go, there’s something

of order. I think it’s about 120, 130,000 lines. So, included in here are regular expressions,

flags, concurrency primitives, the run-time, the garbage collector, pieces--oh it’s finished.

Okay. So that was a one processor. I could’ve paralyzed it a bit better. But that’s eight

seconds. That feels long to me now. That’s a long time because this is all the software

that’s there and, you know, it’s a long time to build--you can get a lot done with

that much time. Just to remind you, then we go back here, that’s what you want to see.

You want to have character return time for your compilations, and it can be done. So

let me get that set for later and we’ll go back to this. Okay. So, we think we’ve

got fast compilation and I can’t tell you how much--what a difference that makes to

your life. Sometimes hours and hours to go by when people finally showed up to my office

and say, "Hey, you didn’t answer my mail." I have to look in the mail and actually getting

work done. Okay. So to do this language, we had to have some principles on which is built.

And there are actually some fundamental principles in here that in some ways, I think, differ

from some of the other languages out there, so I'd like to go through them. One of them

is that we try as much as possible to keep the concepts orthogonal. For instance, in

the interface surface, I’ll talk about the concept of implementation versus interface

or completely orthogonal. They’re two separate things, they don’t interact and you don’t

define them together, you define them in separate objects and that makes a lot of stuff cleaner.

And in practice, this is because a few orthogonal features that cover the space work a lot better

in practice than a lot of overlapping lines. That’s a principle that’s a little vague

but I think, I think you know what I’m getting at. The grammar is very regular and very simple.

It’s actually conflict free and can be parsed without a symbol table, there’s no conflicts

in it. That makes it easier to write tools, like IDEs or editor plug-ins, and things like

that, debuggers because the parsing line is understanding and the program is actually

pretty straight forward. We try to reduce the typing. What I mean by that is that we

want the language to work things out. You tend to type too much when you’re programming

in modern object or in languages. You tend to write statements like that. That’s literal.

If you change "Foo" for a much longer word, that’s an example I found in some code I

want to end. And I just, you know, "Foo" should just go away. You shouldn’t have to type

all those "Foos," that’s crazy. So you want to get rid of the bookkeeping, you want the

type system to automatically works the "Foo," but you still want to be safe. You want it--you

want it to be type-safe, but well handled. And also, not only you don't want to reduce

typing, you want to reduce typing. You want to type to sort of melt away into the background.

You want it to be clear, you don’t want to type hierarchy, we don’t want to type

hierarchy, and then I'll show you some examples on why that actually helps. We just think

the program by constructing type hierarchies, is not the way to go. We have an alternate

world. However, Go is a profoundly object-oriented language. Arguably, more object-oriented language--more

object-oriented than, say, Java or C++, and I’ll show you why. So, the big picture,

there’s some fundamentals. We have a clean concise syntax. We have very lightweight type

system. We got rid of implicit conversions, because they’re all inconvenient. They tend

to cause a lot of confusion particularly in the old C rules for things like the, you know,

the usual conversions are actually not all that usual, and now these got right. So everything

is very clear and very clean on what’s going on in the page. Of course, when you know the