 So, as I said, my name is Andrew Gerand, and I'm from Google in Sydney, and I work on Go, the programming language at Google in Sydney. And today I'm going to talk to you about some part of the Go programming language, not a comprehensive overview, only of a short time, so I can't go really in depth. But just to give you a brief overview of what Go is about, Go is an open source, BSD licensed, and it's a general purpose programming language being developed by a team at Google. There's some of us in Australia and some in the United States, quite a small team. And it's also developed by a team of contributors from the public. There's been over 100 people not from Google who've contributed code, and there's about 10 to 20 regular contributors outside of Google. So, what Go is, is it's a simple language, meaning it's very easy to understand, it's very simple in its specification. It is syntactically lightweight, it feels like a scripting language to use, but it's a compiled language. It compiles to native code on 32 and 64 bit Intel architectures and on processors. It's statically typed, as distinct from Python, Java, script, et cetera. And it is memory managed, so unlike C or C++, you don't need to actually manage your memory, like Java or the dynamic languages, all that's handled for you. And it's a highly concurrent language. I'm not going to talk about its concurrency features today, but one of the big selling points of Go is that it has some really neat primitives for launching lightweight threads and communicating between those threads. And it's also one of its design goals is to be very, very fast. So it's very fast in its execution and particularly very fast in its compilation. And as of November, the start of November last year, it's one year old. So just to talk a little bit about the design goals of Go. So the key goal of Go was for simplicity. If you look at any of the sort of major languages, the mainstream languages that exist today, there are countless numbers of corner cases. And it's very difficult to understand exactly how a particular feature set works. But we thought that every feature of Go should be easy to understand in and of itself. And to go hand in hand with that is orthogonality. So each of Go's features need to interact with each other in predictable and consistent ways so that you know what your code is going to do when you see it written, there's no sort of guesswork. Well, it's very difficult to construct those kind of trick programs where you're not sure what it will do. And thirdly, Go is designed to be highly readable on that note. So when you look at a piece of Go code, you should really understand exactly what it's going to do. You don't need a lot of context from the surrounding program to comprehend a particular piece of code. And finally, we wanted it to be usable, which is really a combination of all of the above points. Like many languages force you to make a lot of decisions about how you're going to structure your programs before you begin. You have to think a lot about typing and design considerations. Go sort of gives you the opportunity to write out some data structures, write some code, some actual code that does something before you start massaging it into an actual structured program. So in this talk, in the brief time that I have, I'm going to talk about Go's type system and the package system, which organizes all of Go's code. And I'm going to do it in reference to Go's tar file reader and write a package from Go's standard library. So this is the Go documentation and this is the package tar. So it's a simple package that will read and write tar files. Does anybody not know what a tar file is? We're at Linux Comp, so I presume you will do. So first off, Go's type system. I might as well start with what Go doesn't have, rather than talking about what it does have. Go is an object-oriented programming language, but it doesn't have the familiar notion of classes and all the baggage that comes with those. So it doesn't have abstract classes, static methods or variables, the concept of protected or subtype polymorphism as like a design philosophy. It doesn't have implements in terms of explicitly implementing interfaces. Doesn't have constructors on objects, and it doesn't have a concept of this. So what does it have? Well, Go's type system is based around several built-in types. So we have the numeric types, integers and floats, complex numbers of various precisions, bullions, strings, struct types, which are just concatenations of various other types. Pointers, arrays and slices, which are fairly self-explanatory, and maps, which is a built-in hash map type. And finally we have channels, which is one of our concurrency primitives for communicating between threads. And functions and interfaces are also types, which I'll go into in a little bit. So when you make a type definition, which is the fundamental way of specifying a user-defined type, you just give a name to any of these built-in types. So this first type definition here is the type year, which is an integer. And so if I want to use a year, I have a variable that accepts a year, it's just accepting an integer behind the scenes. Similarly, like this type person is a struct type. It has two struct elements, a name, which is a string, and a birth year, which is a year. And so in memory, if I have a person, that is literally just a string and a year, which is an integer, next to each other laid out. And thirdly, I have this person list type, which is a slice of pointers to person. So we'll see how this becomes useful in a minute. So here's a type definition from the tar package. This is a tar file header record. So it's just a struct containing the name of a file and all of its associated metadata. So a tar file is basically just a concatenation of header records and file data. And this header struct is used by the tar package to represent that part of a tar file. So I described how types are implemented. You can declare a method on any named type. So these are the types that I've defined before. Here's a method, star date, which is a method on the type year. This is just a normal function declaration, but this here is the receiver, the methods receiver. So y is a type year, and then my method name is star date and it returns an integer. And all it does is multiply the year y by 13, which is a rough approximation. There's no real connection between our years and star dates, unfortunately. I realized after I wrote this example. So, and this second example is a method age on the person p. And what this does is takes the current time in nanoseconds, reduces it to seconds, and then divides it by the number of seconds in a year to give us the current year and then returns the difference between the current year and p dot birth year. So what I'm doing is the receiver person is referred to as p, which is something that I've specified within the method, and I'm returning that value. And the third example is just a method that returns, that's a method on person list, my list of person, and it just returns the oldest person in that list of people. So it just iterates through, I'm using a range statement, iterates through L, finding the oldest person in the list and then finally returning it. So to look at a real world example of a method, in the tar package, there's a reader type which reads from tar files, and it's a struct type, and it has a method next so that when you're reading through the file, you can call the next method to skip over whatever file you're reading and go to the end. So yeah, so this leads me to interface types. Goes interface types define behaviors and they do this by defining a method list. So when you have an interface type definition, it defines a set of methods and any type which implements those methods satisfies that interface and can be used anywhere that that interface is expected. So in this example, I have absa, which is an interface type which contains one function definition, abs, which returns a 64-bit float value. And so here I'll define a type point which contains two 64-bit floats, x and y, and then the method abs on point will return the hypotenuse of a right angle triangle made by x and y, the absolute scalar length of the vector xy. And then if I'm in use in this example function main, for example, I can have a variable a, which is a type absa, and I can store the value, a point value in there because point satisfies the absa interface. And so then when I print a dot abs, it will indirect through to the underlying point and call points abs method. And so to give you a more concrete example of how interfaces work and go, the IO package, which is part of the standard library, defines reader and writer interface types. And many types, both in the standard library and out of the standard library, implement these reader and writer interfaces. And so they can be used interchangeably wherever reader and writers are expected. So the reader type definition is just this, it defines one method, read, which takes a slice of bytes and then returns the number of bytes read and an error value. And then there's a broad array of types that implement reader and this is just some of them. So in the standard library, there's like a buffer of bytes in memory. So you can use that as a reader or a GZB compressor or an HTTP connection or a TCP connection files, our tar file reader, for example, and like a WebSocker connection as well. And so all these things can kind of be interchanged. So in the archive tar package, the new reader function, which is what creates a new tar file reader, it takes an IO reader value. So if you had a file, which was a tar file, you would pass it that file and it would use it as a reader and read the data from it. And similarly, the reader itself, because it implements this read method, it in turn is a reader as well. So just a bit about how code is organized in Go. These are the fundamental sort of building blocks of any Go program or collection of Go programs. So at the top, you have the largest single element is a package. And within that, you have variable constant function type and method declarations. And then with it, and so that's your global package scope. And then within a function, you have a local scope in which you can define variables, constants, functions and types. And the definitions of those at the global level and at the functional level are the same and the rules that they bind to are exactly the same. So it's very predictable and comprehensible to see how these various things work no matter which scope you're using them in. And there are only two compared to the much more complex scoping rules that you have in languages like JavaScript, Python or Java or indeed C++. So a package in itself, a Go package, is a place where you group conceptually related types, functions, constants and variables. So it's kind of like a Python package. But it's sort of a more of a looser kind of collection of things. Packages can consist of multiple files, but they all share the same namespace. So I'll give you an example then in a second. But it means that you can effectively organize blocks of code without having to make explicit decisions as to where you think things should be. Because within a package, the particular file that a function is in doesn't actually dictate how you address that function. As far as things being private and public, Go has one simple rule as to whether things are available inside or outside a package. And that is if the name begins with an uppercase letter, then it's considered public. Otherwise it's inaccessible. So you can immediately see whether something is an exported method or type or variable or whatever at a glance. And the only other errata is really that circular dependencies have been, so you can only import in a non-circular graph. And the top level package of any Go program is always main. So to give you an idea of how you might actually lay out a package, the tar package consists of three files, writer.go, reader.go and common.go. And all of these files share the same namespace internally. But writer.go contains all the stuff relating to writing tar files like the writer type and its associated method definitions. The new writer function for creating a new writer, all of the write-related error values. So if a writer encounters an error, you can compare it against these publicly shared error values to understand what's going on. And also all of its unexported implementation is also in that writer.go. Similarly, this is the same story for reader.go. You have all of its public implementation stored in there and also all of the implementation details that are unexported stored in there. And common.go has the header type that we saw earlier, which is used by both the reader and writer types. And it's exported constants and also some unexported helper functions. So it's kind of like a loose amalgamation of all the tar writing stuff in those three files. And to give an example of one of the unexported like helper types that is used by both the reader and the writer, there's this ignore writer type, which is because it starts with a lowercase i, it's actually only visible to the tar package itself. And all it does is it implements the IO writer interface by defining this write method and it just acts as if it's written data somewhere and then throws it away. And the way this is used is there's a method on reader where when you're reading through a tar file and then somebody says, and then you get partway through or you wanna skip to the next file, you basically wanna skip over all that data and throw it away. So what we do is we do it, there's a reader on the, we perform a copy basically from the reader source into this kind of null ignore writer. And that just skips over or reads all of those bytes into DevNull effectively. But these kind of like help types or wrapper types are very common in Go to just build something and then it's effectively like a throwaway thing. I've been told I'm running for a long time so I have to wind up. But just to the key points of what I'm getting at in this talk is that so the orthogonality, as I mentioned at the start, the concepts of exported or unexported are completely orthogonal to like variables, constants, functions and types. And it's natural and easy to like expose or hide or rearrange various parts of your Go program, move them between packages and reorganize things as you're going along, which is kind of unusual for a statically typed language but goes kind of loose enough that it lets you do that. But the real benefit of that is is that you build everything, both your public stuff and your private stuff in the same state of mind, so that the part where you're actually coding and making code that works is distinct from the part where you've fashioned something into an exported interface. And so going from the version that just works in the very beginning is to the production quality version that's worth sharing. It's usually not a big deal to get to that point. It doesn't usually require major rewrites. And yeah, so there are generally fewer barriers to refactoring and so just like in summation, Go has become for me. I've been working on the project for a year since it was released. I didn't work on it before the release and it's quickly become like my language of choice for pretty much everything for some of the reasons that I've outlined here. In giving the talk, I kind of realized that I probably haven't communicated as well as I could have my enthusiasm for how nice this is, but it really is and I encourage you to give it a try. We've got a ridiculous amount of documentation up on this website, so check it out. Right, so sorry for keeping everybody from lunch. But first let's thank Andrew for the talk. And now if there are some people in the audience who'd like to ask some questions, please raise your hand or run a mic to you. Okay, you then, you. I just want to ask what the state of the library is like, whether or not I can database access, blah, blah, blah. All those other things you depend on when you do something. So the standard library itself is very mature and there's also a really broad range of third party libraries written by people in the community that do a lot of what you might need to do. I mean, it depends specifically what you want to do, but in terms of database connectors, all of the major ones are supported really, like MySQL, Postgres, Redis, CouchDB, all those kind of, all the open source ones tend to have connectors, which is nice. Other than Google, are there any other companies that use Go extensively? Instinctively, internally. Externally, extensively. Well, I mean, as far as extensively, I don't know, but I know that at Atlassian, they're using Go for some stuff. We're definitely using it internally in some production applications, but it's still like very early days for programming language, like Python's almost 15 years old now, I think. Closer to 20. Well, yeah, closer to 20, but it's still only just seeing adoption in the industry. So, yeah. Okay, so we'll take one last question from up here. It's a really horrible one. Issue nine in the bug tracker is related to the name collision of Go, your Go, and everyone else's Go. What's everyone else's Go? Go away. Well, there's only one other Go that I'm aware of, and that Go didn't even have a Wikipedia page until a week after our Go was released. And I've never found a program written in that language. So, I'm not aware. And the reason why we closed that issue is because we said that we haven't actually noticed any kind of confusion between the two languages. Nobody posts on our discussion forums about that Go and presumably vice versa, so I don't really see an issue with it. We all have a slash though. Right. Yeah, no, it's just, I don't know, it's... Well, Rob Pike, who's the team lead on Go, has had, as invented, three other languages before, all of which were, have had subsequent languages called the same thing on him. So, maybe it's like a reverse karma thing or something, I don't know. Righto. So, everybody please thank Andrew for his talk. Thanks for coming. So, we're resuming here at 1.30 with John Cruz talking about Avoiding Development and Honor Culture. Love to see you back here. So, yeah, see you then.