Placeholder Image

字幕表 動画を再生する

  • >> PIKE: I’m going to talk about the Go Programming Language, which is going to be--we

  • 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 were 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 were not--we don’t believe this is the answer to everything, but were 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 weve 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, were 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 were 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--theyre

  • tend to be slow and theyre 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. Theyve 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 theyre 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--were 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 couldve 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 well go back to this. Okay. So, we think weve

  • 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. Theyre 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 youre 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 theyre 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

  • conversions, you tend to do a lot of casting or conversions by hand and that’s messy,

  • so we address that by changing constants pretty profoundly. I’ll talk about that in a little

  • bit. You'll never--you won’t see "0x80ULL" in a Go program. The ULL is completely pointless,

  • you can’t even say it, numbers are just numbers. And there’s a strict separation

  • between the interface and implementation. That’s part of keeping the concept orthogonal

  • and the type system clean. So there’s a runtime, there’s a garbage collection, there’s

  • a good support for strings, maps, associate raise, that kind of thing, and also the communication

  • channels, which well talk about, and then there’s really strong support for concurrency.

  • It’s actually some of the best concurrency stuff, I think, that’s out there. It's really

  • good. And then, there’s a package model, which I won’t talk very much about because

  • it’s kind of takes a lot of explaining. But the notion here is that inside the packages,

  • everything is explicit. What you depend on is explicit. Compiler rejects your program

  • if you put in the dependency you don’t need. It’s all very clean and so, it makes tools

  • easy to understand dependencies and then it makes the builds guaranteed minimal. So, that

  • helps enormously. Regarding the dependencies, the linking going faster, the compilation

  • can go faster but--and there’s actually a notion in here that I think is important.

  • The compiler actually pulls the transitive dependency information up the tree as it’s

  • compiling, simply to reduce the number of files it has to look at, which in turn speeds

  • up the compilation process. So, if you have a program, A.go, that depends on B.go that

  • depends on C.go, which is pretty standard kind of thing. You--in the usual way, you

  • have to compile them in reverse order, because you got to build the dependent stuff before

  • the depending stuff. But the point is when you go to compile, A.go, it doesn’t need

  • to compile C. It doesn’t need to look at C.go at all. It doesn’t even need to look

  • at the object code for C, because everything that B need from C has already been pulled

  • up into B.go. And that doesn’t sound like a big deal, but when youre at scale, it’s,

  • literally, exponentially faster at building software when you get in to this huge dependents

  • situation. For concurrency, we sort of have a model. I’ll touch on it today. There’s

  • a lot more stuff online about it. But we have a suggestion for how to write systems and

  • servers as concurrent garbage-collected processes, which we called, goroutines. Well have

  • good support from the language and the run-time. We change the name because they're slightly

  • different from what you're used to. If you use the words like thread or process or goroutine,

  • that’s not quite the same, so we have our own word, goroutine. The language takes care

  • of managing the goroutines and managing the memory that they use and the communication

  • between them. Stacks grow automatically. That’s taken care of by the language. You don't have

  • to declare how big the stack is going to be. If it needs a bigger stack, it gets the bigger

  • stack. If it needs a smaller stack, it uses less memory. And those stacks are multiple--I’m

  • sorry, the goroutines are then multiplexed on the threads. That’s all done automatically

  • for you and [INDISTINCT] transparently. And, one of the feature--one of the reasons for

  • needing garbage collection is that concurrent programming is very hard without garbage collection,

  • because as you hand items around between this concurrent things, who owns the memory? Whose

  • job is it to free it? And there’s a lot of bookkeeping involved that the--if the language

  • or the system doesn’t take care of that for you. So you need garbage collection to

  • make concurrency work well. On the other hand, you need--to get the garbage collection to

  • work well, you need a language that makes garbage collection a feasible thing to do,

  • which is another argument for doing a new language. So, I don’t have time to explain

  • all of Go to you. It’s a significant language, it’s--I’d say probably bigger than C but

  • not as big as C++. Enough time to go through all of it, but I want to give you the flavors.

  • I’m going to go through about a dozen slides that are--I hope sort of representative of

  • the kinds of things that go on, but I’m going to leave out quite a bit. Lexically,

  • it looks a little bit like C, actually a little more than like C than this slide, we let you

  • believe. There’s usually a keywords involved, introducing things, you see const and var.