Good day So before I before I start with this I just wanted to Actually, I'll tell you later. I'll show you the schedule after but we finalize the schedule for the Lightning talks which are directly after this

There's a bunch of interesting stuff. I suggest you stick around If you go to the girl on Twitter page, you'll see that schedule there But right now I'm going to give a give my talk on the state of go Just basically a state of the union where the project is at At this point in time, so a little bit about what happened last year in December. We released go 1.4

There are some important things about it like we introduced the beginnings of Android support The canonical import paths thing was actually pretty important in a sort of subtle way to do with the community and make sure everybody's using Packages with the right import paths

And the go generate command is also pretty interesting and I think we're only sort of at the beginnings of seeing what people are using that for But really what was going on in 1.4 was a lot of preparation work For future releases of go there was a lot of prep work for the new garbage collector It's a lot of prep work for the conversion of the toolchain from C to go

And so the source code was reorganized and a bunch of other stuff like that You can check the release notes for more details Around the same time as 1.4, but largely disconnected from the 1.4 release process We transitioned from Mercurial to Git And so that means the core go repository

And all of the sub repositories like the tools repository and so on And now in Git instead of Mercurial we converted all the change history across all the data was preserved And that also coincided with moving to new development infrastructure So we're still serving our main repository on with Google technologies

So instead of Google code, we're using Google source.com, which is the same primary repo for Chrome and Android We're using Garrett instead of read valve for code review and which is also coupled with that that source code service and

We're using GitHub instead of Google code for issue tracking and the wiki And this is a big deal for go contributors and some go users But for most go users, it's not really a big deal. It doesn't really affect how you use go or what go is about But those are the the the URLs. I just wanted to touch on why we moved

basically, the reason why we chose git is because We needed to move to Garrett and Garrett uses git, but why do we need to move to Garrett because read valve the code review system We were using was basically unmaintained. It used to be used by

the Chrome project And so the fact that they were using it meant that there were people working on keeping it running But then we were basically left holding the bag And we were the last people using it and we were like, well this sucks And so we decided to switch to Garrett which has a team maintaining it

It has a team actually maintaining the infrastructure as well And so we join large projects like Android and Chrome who you know So we're pretty confident that system is going to keep being worked on and improved for the better And why did we move our issues and stuff away from Google code to GitHub? Basically because now we can use GitHub

It puts us closer to our community which by and large uses GitHub for its source open source development work and It means that other github repos can mention like go commit by hash or a go issue in their issues and go commits and so it means we can kind of have a

Nice more tightly sort of coupled relationship with other projects that use the go core So that's nice There were some pros and cons to the transition The pros are pretty significant. Otherwise, we wouldn't have done it but like more people understand git than mercurial

and Importantly contributors can now use their own git workflows Previously with mercurial we kind of had this rigid kind of linearized Process that you had to follow as a contributor but now because all of the sort of Submission and merging is handled on the Gerrit server side

You can do whatever you want as a contributor in your own git repositories So previously we forbid our committers from using Mercurial extensions that let you sort of stack commits to do stuff like that because we were afraid that you would accidentally push some Big work in progress thing to the master repo Gerrit is like a gatekeeper and so we don't have to worry about that anymore

So now people can go crazy with git as they like to do And that touches on the good integration between git and Gerrit. Previously read valve had nothing to do with Mercurial It was just kind of there was a fast disconnect git and Gerrit are thoroughly Integrated and also now we have automated CLA checking. So the contributor license agreement is a way of

saying as a contributor to go that You have the authority to to give the project the code that you're giving them And so it means that anybody who uses go is protected from any kind of spurious licensing claims down the track Previously we had to check a spreadsheet inside of Google To see whether someone had filled in a form and we even had a tool to sort of automate that somewhat

But now we know If we receive a code review through Gerrit that that person has actually signed the CLA and so us as developers Don't even need to think about that anymore, which is great There are a number of cons though Git has a steep learning curve a lot of people who were used to our simple Mercurial based workflow are now very confused

And I feel bad about that That's just the nature of the beast GitHub has no way to disable pull requests, which I'll talk about why that's a bad thing in a minute GitHub also has no way to star or plus one issues, which I suggest everyone here Just tweet at github and ask them to implement this feature doesn't seem like it would be very difficult to do

But it kind of sucks getting an email notification every time someone says your plus one this would be great to fix it's like yeah, I know that's why it's on the issue tracker and it's still open and we're working on it, so Thanks for the input So actually if you do write a plus one or if you have written a comment like that

We actually have a policy where we'll delete them just because it sort of pollutes the discussion of the issues So don't be offended if that happens. It's just it's get hubs fault. It's not your fault Another unfortunate thing about github is the standard of issue reports has gone down

And it's largely because On the old google code issue tracker we could we've provided this issue template. So when you go to file an issue You would get a nice form Where it said, you know, here are the pieces of information we want. Here's the format that we wanted in Now it's like you go to file an issue on the go project and you get this blank box and you can just Write anything and so people do just write anything like I don't understand why I need to import the file

Commed package to print something and it's like this is not the appropriate form for this for this Question so on So that's a problem. It's a culture difference And finally, it was a ton of work to transition. So that kind of sucked but I think we're in a better place now Which is great

This is my final slide whining about github Why don't I like pull requests A lot of people are really really surprised that we don't accept pull requests And so I think it's important to say why it's not because we don't want to participate in Like the github way or like the the open source community. It's not because we're not

Accepting patches or anything We have our our own system of receiving patches through garrett But there are very specific reasons why we don't like pull requests One of them is that the diff view is terrible. I don't know if anyone's tried to open like a 5000 line diff across multiple files on github

Even on a high-powered machine, it's really slow. I don't know why that should be but it is And like when you're reviewing code you write comments And like I might be reviewing brad's code and i'm like commenting. Why are you doing this? Like this seems weird blah blah blah and then I get two-thirds of the way through the review And it's like oh I understand why he's doing this now and then I go back and delete the comments

And that's what I would do in our old system and that's what i'd do in garrett But in github by the time I get down there All of my comments have already been sent to him by email. And so there's no way for me to like back up and change my mind and you know Whereas in the other tools we're used to you have this kind of atomic Process where you draft all your comments and send them in one big batch

I mean, it's really it's really critical as a workflow thing Um, yeah, you can't sort of look at differences between Editions of the patch set as they evolve their change You can't sort of see how it's changed Uh, yeah, you have to fork the repository publicly, which I think is just weird

um When you accept a pull request, it creates a merge commit And we prefer to cherry pick the changes to the top of the branch instead So we have a much cleaner history don't have all these commits followed by merge commits um And yeah, and in general, I think the whole way pull requests Are created it doesn't actually encourage people to review your code thoroughly

whereas we have a culture of very very thoroughly reviewing all changes So kind of didn't really work well for us I think github actually just introduced side by side diff. Oh, really? Yeah. Yeah, so Yeah

Yeah All right, so that's my wine about github I think they know that they can improve it and they are working on improving it like I think there's a lot of scope for improving developer workflow and that's their business. So I trust they will get there in time I think they're obviously we chose them. So we think they're good. It's not i'm not saying github is bad

Yeah, we have the same So go 1.5 the future I saw a talk yesterday which had this disclaimer and I figured since we're

since we're uh I don't basically it means that anything I say is purely speculative Um, i've covered i've replaced the various names with these things. Maybe you can figure out who that was. I don't know um So the release cycle has changed a little bit we've pushed it out instead of releasing in june. We're now releasing in august

That's because everyone seems to be on holiday in june and also that put our other release in december and so it meant that basically the whole period of when the tree opens again fell during the june holidays and also during the like december january holidays and so the time when we needed people to be doing the most work was also

The time when everybody was away And so we've shifted it by a couple of months. And so now the freeze period is what is during the holidays And so it means that You know while we're not supposed to be doing work. Um, we can be on holidays, which is perfect Um, so one of the major things about the go core in 1.5

Excuse me is um The tool chain being converted from c to go So this started early last year Um, it's been going on in the background largely, um mostly driven by russ And he told me a couple of days ago that it'll be done

By the end of march or maybe in the start of march. He said march um basically, there is New linker and assemblers written in go from scratch And the assembler is actually maybe it's the code generation back end is actually pretty cool Um, it actually reads processor instruction

spec sheets from pdfs and uses that to Generate the tables from assembly instructions through to the actual bytecode output Um, so if you've seen russ's like pdf reader library, that's why that exists and it's It's pretty hilariously awesome, actually

But the main meat of the the go compiler itself is being machine translated Um from c to go and that doesn't mean that we're going to have a c to go translator that anyone can use um, it just means that uh russ is carefully massaging the the Compiler into a c program that looks like a go program

And then we can on like instantaneously convert that to a go program And then we'll massage it from a go program that looks like garbage into A real go program made of several sub packages and so on Um, so that's that's kind of happening and that's what should be done very soon Um, but the upshot is that in 1.5 there will be no c code anywhere in the tool chain

Or even in the runtime all the runtime code had to be converted by hand and that was done by Uh a lot of people on the team and did a really great job of that But what that means is that to compile go 1.5 and later you'll need to have a go toolchain to do that

You don't need a c compiler anymore, but you will need a go compiler um to build them and so uh The way to do that is just to put a directory in your home directory called go 1.4 and put go 1.4 in there Or you can set the go root bootstrap environment variable One downside of this is that for new new operating systems and architectures

You need to cross compile instead of working natively, but that kind of works more easily in some ways anyway But if you use the binary distro of go put your hand up if you download go from going to dog And install that way not one person. Oh wow a few, you know, I spent hours and hours on this a few times a year

I could just not do that apparently Anyway, if you do that, then you don't need to do anything Also in 1.5 we'll see a new concurrent garbage collector whose work's been going on for a while Basically the upshot of that is

We'll have go programs that are guaranteed to only pause For say up to 10 milliseconds on modern hardware And it means that your go program will be running like 80% of the time in a sort of guaranteed fashion So it's we're setting an upper bound on the porters. So that'll be really nice for more interactive applications

Um, if you saw brad's talk on htb2, which is really great You know that that's coming it's probably not in 1.5 Because the spec isn't standardized yet but it It will be in the standard library at some point and it means that if you ever go htb server When the htb2 spec is stabilized, it will become an htb2 server for free. You won't have to do anything

You can just write your service as normal and they'll speak htb2 So that's great And I just want to show this demo once again, even if you saw it already because I think it's so cool In htb1 over a low latency connection It can take a really long time to make all these requests

Kind of in parallel but mostly in serial but htb2 lets you pipeline that and bang and so I think it's going to be fantastic particularly on mobile platforms when this is fully rolled out speaking of mobile a bunch of people

Have been working on porting go to android and ios So in 1.4 it was possible to build android apps If you could work out how to do that with the android build system, which has anyone done android work here It's a bit tricky But in go 1.5

David who's doing this just snorted when I said it's a bit tricky. It's a little bit of an understatement So in 1.5 we have to have some tooling to make the build story much more straightforward Um And much more sort of go-like, you know, you write your code and then hit build and it works. Is that a rough approximation? Let's say let's say that's going to happen

Yeah better support for accessing more of the ndk more of the android apis Better conventions and bindings for calling go from java And also ios is really exciting So there's actually been an ios pod that's kind of been going along in the background for several years now But we're actually looking at merging that into the core for go 1.5

So that's that's really cool And also related to that some new architectures so power pc 64 who has a power pc 64 system They're actually really amazing if you have one and that's why none of us have them because they're huge and awesome

Very industrial kind of settings that they're useful for but also armed 64 is in the works Um, one of our contributors arm has been working hard on that along with other people Um, so power p64 is basically done. There is a builder running it passes the test. So that will probably be in 1.5

Arm64 they have a stretch goal to have a branch in the in the main repo by 1.5 so it won't be available, but it'll be in development and arm64 of course is important for ios development because of 64-bit Um Processes in the newer apple phones

And you can actually see a work in progress of arm64 in that github repo Um, there's a new execution tracer that will be part of the go tool chain So you'll be able to enable execution tracing in your go binary and basically that means your go program will just dump tons of information to disk

About what the program is doing and when and then you can use the the Google's trace viewer, which is a tool. I'm not sure which team built it first, but both android and chrome use this to generate diagrams and explore These kind of logs of of information so this is a

Sort of shrunken down screenshot, but basically you can see which processes are running which code and when and this is like a gc pause And you can see like what's happening there and then You can also see like the number of go routines and all that stuff and when you click on these things You can actually see like which function it is and what it's executing and other information about the stack. This is showing this gc

thing but there's a lot of information in there, so The cls the chain the changes to put this into the core were all sent out over the last week or so um and Yeah, that's all rolling in so there's a design doc you can see at that url if you're interested i'm pretty excited about that

Allen donovan and some others have been working on tools for Getting information about and also manipulating go programs And some of that is already in the tools repository There are tools like call graph to sort of dump the call graph go program

Which is useful for piping into other systems that can visualize that kind of stuff And there are two tools go move package and go rename that can be used to In a type safe or you know file system safe way Change the names of things move things around just to make it easier to like correctly refactor programs

And those those programs are ready for use now I also saw a demo of a program called sock draw which is Still in a in a change that's being reviewed somewhere But basically that allows you to take a package and say I want to move these parts of the package Into another package and it will grab all the internals that it needs

And only take the sort of internal dependencies of those public bits And so that's kind of a that should be quite useful If you find yourself building a util package that just grows and grows and grows and you shouldn't do that But if you do That will be a useful tool for you Brad has been mostly leading the charge on this i've been helping by reviewing his code

But basically we have our own homemade continuous build infrastructure largely because When you're developing a programming language You kind of ever at the very bottom of the stack and a lot of the existing infrastructures kind of didn't work out Well for us at the time But so it's now the new infrastructure is now

Running a lot of our builders on google compute engine And we hope to be running Os 10 not in compute engine on a different farm of machines and also windows pretty soon But the really nice thing about it is we can spin up huge amounts of machines to churn through our builds When they're happening and so we get our results a lot faster

And also we'll be able to test like speculative speculatively test changes and see if they work before we commit them Which will be really nice It's not really any big news, but it's it's good news for us Um It will be integrated with garrett, but it's not right now

Um, but another cool thing that it's given us is this tool called go moat Which I can demo really quickly basically a really common thing for us is um, You'll you'll break something um On you'll you'll break something on open bsd and then you'll be like, how do I fix that?

I need an open bsd machine who runs the open bsd builders you send an email, you know, they give you Well, what's your ssh key you can log in or create you an account something like that Big waste of time instead now we can say go moat create and um Spin up a vm running exactly that builder's environment

Um, and I probably should have done this before I started the talk because it takes about 30 seconds But this is hitting google's compute engine apis um and starting a A new vm, which is running an image that we pre-built and it's stored in google cloud storage somewhere Um, and then once the instance is created it waits for us to boot up

The instance actually pulls down a version of this buildlet program Which is a program that just listens via http and awaits instructions um from From me the user and so now it's created. I can actually say like I can issue commands to it um, so For instance I can say

uh You know just list the file system root and it will run it on that remote server and then show me the the results um more interesting is I can say, um I can put a tar file from my system or even just put a file But a nice thing is I can say I want to put go revision

Um, whatever that is. Hang on I can put this go revision. Um, sorry You can see Oh, oh, oh, yeah. Okay. How can I do that?

Yeah, there you go I'm in screen. So I wasn't sure it would work. Um, but then I can put um A particular revision and it will actually just pull it out of source control. And the nice thing is that revision can be Um any revision that you've uploaded through garrett, so it could be an in-progress change that I have or something like that

um And so once that's been shoved onto the machine It will return and i'll just start typing. Oh I can now that i've put it I can run Instead of bin ls I can run source slash make the bash And actually start building

um You know go on that machine. So now i'm getting the standard output and error of that command running remotely And so this is this is going to be really nice for us as a development thing It may get spun out into something more generally useful. Um We'll see I'll just leave that running Cool

Um right now a contributor can't use it directly unless you're one of the committers and you have a key that will give out And that's largely because it then gives you Being able to use that program gives you access to our google cloud Project and so you could like create instances and start a botnet or something. I don't know use your imagination

Oh Yeah, so the idea will be that you can use your own you'll be able to specify your own project And use it yourself and you just pay for like I think google the compute engine charges you by the minute after the first 10 Minutes or something. So it's actually quite conceivable. That'll be quite cheap to work that way

cool um, so That's the go core As far as the go community is concerned. There's a bunch of go conferences around the world Um and more to be announced there's fosham we're here right now. Hey um There's go for khan india In bangalore and that's what was called bangalore. If you didn't know they renamed their city recently. That must have been really difficult

um There's go khan in tokyo. Um, it's been happening twice a year for the last two or three years So I presume it's going to continue happening Um, there's go for khan in denver. Um Did anyone here go to go for khan?

A few people did yeah Um, so it's going to be like twice the size this time, um, which is a little bit scary for me Um, but uh, that should be great. We had a great time last year. So I suggest you go if you're at all interested Um and dot go will be happening in paris Later in the year, but there's more stuff that i'm aware of that. I that I can't say that'll that'll be cool

And also there was the go for gala Did anyone participate in the go for gala anyone here a couple of people one person So the go for gala was a global go hackathon that happened last weekend um And there were teams that would produce apps that were judged by the usefulness creativity completeness

And how well they showcased ghost strengths Um, they it didn't just happen online. There were also physical locations around the world about 30 of them Um where people got together and hung out and packed on ghost stuff There were really cool prizes. Actually, you could get a chromebook pixel like raspberry pi all kinds of techie stuff github accounts

And a trip to mexico, which I thought was totally amazing Um, and it's like to kalima, which i'm not sure what that's like as a place But basically it's a company is invited is invited Invited you to fly you out so you can hang out with them

And like hack in their office or just go to the beach or whatever I hope it's on the coast. Otherwise that makes no sense um So But the winner is still yet to be decided. The judging is happening at the moment And you can actually check out the entries Um at go for gala challengepost.com Submissions and I just wanted to highlight a couple of entries that caught my attention that I thought were pretty cool. Um

there was um Gofi gophi Set up monitoring of your websites, so you'll have these tor exit nodes hitting your Websites, which is kind of cool might put you on a watch list

I don't really know. Um Use your use your best judgment, but it seems like a cool project Um, I like this one the golang size of tips so um Oh, where is it? No There was a link. Oh, there it is

It's got a cool domain golang size of tips but basically oh You can you put a go struct in and it shows you the packing of the struct So you can see if you want to optimize the packing of your go structs um You know, it will tell you whether it's optimal or not. And so

Oh, it's you ask the gopher. So it says it will explain And so that's well packed if you put something, you know Small in there it becomes unbalanced and so on. So that's that's kind of cool Um I like this one too a go report card And it's a website that you give it your project's import path and it will run like go fumped go lint

uh I don't know what go sick low is and go vet over your your um Repo, so if I put something of mine in there And run it it will tell me that it's 85 that

Oh this text the tests the cyclomatic complexity of your source code i'll have to look at that later. Um But this is telling me, you know that I should definitely be documenting all of this stuff and it's definitely true So put your stuff in there and see how it goes. Actually i'm curious about

Great you got an a Um And this one's kind of cute, um, it's not go related but it's written in go, uh, it's a command line tool Where you can uh record a voice message and it will encrypt it and mail it to someone

And so, you know if you have like some secret love and you want to whisper sweet nothings from the command line You can do that so that's that's awesome Um, but yeah, I definitely there's like 128 submissions, which is a really great number Good enough reason to look at them all each and every one. Um,

So definitely check it out. It's worth looking um and uh Yeah, I had a where did my slide go? Ah, there it is. Um Also, I just wanted to mention who here has gone to a go user group meetup Okay, that's like not enough nearly who here knows that there's a go meetup in their city

But has never been to it aha So You should go to go meetups.appspot.com which francesc wrote and um, it actually lists, uh, It's a machine generated list. So it's probably not complete but it lists go

Meetups and their sizes and their cities and so on so look for your place Get involved in your local go community. Um, if there isn't one then the onus is on you I command you to start one in your town. Um And we're going to kick up a program to start distributing cool things like

These plush gophers and t-shirts and stickers and stuff to all these places so that's a reason enough to uh To get involved Yeah Yeah, please do I mean it's really fun. Like I run the go meetup with dave cheney in sydney and um, you know, we always have interesting talks and fun things going on and

I don't know. It's just a go people tend to be a nice crowd. I like that Cool Oh, yeah Yeah, so that's the URL but that's the end of my talk. So thank you very much

And i'm happy to answer any questions, of course Yeah Right. Um, the question was are there any plans for there to be versioning in Imports or some kind of version control version management system. Um, the answer is no we don't have any such plans

um Peter's talk kind of made me feel bad Um, I don't really know like what I can do as an individual to fix this problem, um I think that You know, he actually mentioned like oh we should Try and export some of the way that google manages this stuff

But the way we manage it is we have one giant source repository And we put everything in that like everything google does and all of our dependencies And so like when you want to update one of your dependencies You import the latest version of that code from its external repository And check it into our big repo and it means that when at the time that you do that you have to update

All of the code that depends on that we have infrastructure to run all the tests and so on um, but like And pretty much anybody i've ever mentioned this approach to just thinks it's crazy like outside of google It works really well for us because we have the infrastructure to support it and because we're just one big company where?

You know, we can have policies that state, you know, you need to not break the build But you can't just tell someone on the internet to not push to their github repo So it's a little bit the the approach that we take is is not one that can actually work outside in a global sense, although

probably what peter was saying is maybe we should try and Make it possible for organizations Like what he was describing the modern enterprise to take a similar kind of approach But yeah as far as like on a on a on a On an open source kind of internet level. I really like the approach that gustavo nimaya took with go package dot in

Which is like versioned import paths. That's one approach The other approach is just vendoring everything when you care But there are caveats with both of those approaches Um, you know, you still have the diamond dependency problem, which is

Theoretically intractable, but we don't actually even have the tools to tell you when that's the case anymore I mean go rather so I think there's definitely work to be done, but i'm not sure what the solution is So I apologize for that wholly unsatisfying response to your question Yeah

Yeah, so you're asking what's the deal with large binaries is that It could be um, it's actually gotten smaller over the last couple of releases Oh, so the question well, the question was why are go binaries so big and are they going to get smaller? Um, and yeah, they have been getting smaller

But the fact is that all gonna go binaries are statically linked if you statically link like sees hello world It's about half the size of goes. Hello world Um, but it sees hello world doesn't do unicode it can uh, you know, if you type function print line Hello, it actually does a ton of reflection and other stuff to make that possible

Um, actually at gopher con last year rob gave a talk where he broke down what happens when you run. Hello world So there's actually a lot baked into that So I don't really feel like it's unreasonably large. We do have a tracking bug to sort of reduce the size but the fact is that When you add more to the go program, it doesn't necessarily grow like proportionate to the size of the source code

There's just kind of like a baseline Large size fortunately disk space is cheap. Um, so Yeah, the internet is fast that's true More questions

Yeah, so the question was how Has there been any progress towards I believe it was ian taylor's go execution modes document where he described ways of calling into go code from

Other host languages and also calling into other languages from go Um and probably david will mention a bit about this In his lightning talk on on android because it's heavily related to uh to the running go on android and ios Being able to do that Um, I I don't really know

Uh, not like not A huge amount has tangibly happened. The tool chain is all kind of in flux right now So work like that is kind of hard to get done In the changing tree right now Anyone else? Wow. Okay. Cool. Thank you everyone