Meet the Authors – Go Language (Cloud Next '19)

I have Megan Santa key I'm an open-source strategist for Google cloud and I am really excited to be here to lead this panel where you can meet the authors of go and well why don't I first just let them introduce themselves to you hi yeah my name is Ian Taylor I've been working on go since 2008 before it became public I'm a Google employee and I work on the tools and the libraries and many other things my name is Robert Van Kent I am not actually one of the inventors of go but I started programming ago about five years ago working on machine management tools inside Google I converted a bunch of machine management applications from Python to go and I joined the go team last year and since then I've been working on the go cloud development kit a set of tools for making cloud application and go awesome hi I'm Robert Griesemer I've been with the go team since 2007 when it was started which is like 12 years ago which seems like a crazy long time I've written a bunch of tools that some of people a few guys might be using like Gotham so if you're not happy with that you can complain with me I may not help though and more recently I've been working on trying to get go into that go to phase I am a Brad Fitzpatrick I've been working on gos since 2010 and I work on the standard library a lot things like the HTTP packages and the build system I wrote like go imports it's just kind of I bounced around to lots of little places hi my name is Tyler Bui Paul Sulak I work on go on Google cloud so my goal is to make it as easy as possible to use go with and on GCP so I just kind of like Robert said if you have problems with go on GCP you can maybe be annoyed at me it might help excellent okay so these are wonderful go experts will be the panelists and I just want to get a sense for the room before we get going can you raise your hand if you have never used go before all right well welcome we're excited to start teaching you more about go can you raise your hand if you've started using it a little bit all right and then raise your hand if you're using it a lot all right excellent we love that good so we'll have a little bit of answers for each stage that you're in and as I was mentioned before this is going to be interactive we have some questions that I'm going to ask that have come in but we are going to take questions from the audience so if you do have a question you can just start making your way down to the sides both of these team members are going to have microphones where you could ask your questions you can just queue up okay so why don't we just get started with a nice easy one so tell me what is go best at doing like what are all great ways that you should be using go so it's good for everything of course of course it's very good for a cloud it's a simple language it's easy to write code it's easy to write code that runs very efficiently it's easy to write code that runs very concurrently a lot of the core infrastructure of the cloud is written in go itself like kubernetes is an easy example and I mean yeah it's it's well designed for web servers good for a lot of things I was just gonna say I like I said I started using go when I converted a bunch of large Python applications where they were pretty performant sensitive and the scale of Google's machines was just getting so large that Python wasn't working anymore and go was what's really gate great for concurrency and also for just managing a large application having a type safe language it's a lot easier to manage and then title something that we hear a lot from people is how easy it is to learn though so it's probably not an exaggeration that if you know how to program within a week you can be productive in though I mean it's been a number of years since I was like super religious about go but at the time I was always telling people how I hated the trade-offs of all the other programming languages were like if you wanted to write performance you know sensitive code you would have to write kind of a tedious language and if you want to write like in a fun language then you would have to deal with bad concurrency or lots of you know callbacks or bad performance or like you know runtime failures due to like you know missing type information and so it was really nice to write in a language that was both fun and fast and then like let you get going and write code right away so I'm still kind of in love with it I haven't found anything that's as fun and like just productive I think one other thing I'll call out is part of one of our one of the goals of designing go was to make it easy to develop in large teams over large amounts of time or long amounts of time so stuff like go pump and go imports and kind of standardizing the language and how it's used makes it so that when you're looking at go code in one spot made by one person it looks very similar and hopefully easy to understand as go code you've seen somewhere else good so do we have any other questions from the audience just to remind you to come down yeah go on over hi my name is Pablo I have a question for you what do you think about a basal bill system for go what do I think about the basil built system for go I think I think it's very good for complicated programs I mean go go comes with its own build system in the sense that it's easy to build pure go programs with the tools that are provided by go but if you want to work on a multi language program with many different parts also if you want to deal with a lot of generated code then I think basil works really effectively it does have full support for go these days and I mean lots of people use it we use it internally we use Google's internal version of it so yeah it's a good system wait you say it has full support but there's a lot of things in like X tools like the package loader and stuff that's kind of like in development so like a lot of a lot of the tools that that exist in the go ecosystem kind of historically assumed that you laid out your code on disk the way that goes built-in build system works and so there's an increasing amount of work recently about making our tools agnostic about whether you're using basil or you're using the go tool so it's getting better like only in the last maybe year okay that's a good point especially for generated code okay great and I think we have another question coming in so I didn't do what Tyler was talking about the benefits of go or what is what it is good for I feel it's very good for collaborative development where you can it's so easy to import somebody else's github repo and their libraries and Cobra is something that almost everybody who develop some CLI or the other might have used so that's that's one thing that I wanted to kind of point out the other my specific question that I had was is there plans of importing like commonly used github repos into the standard library on the contrary we want to get rid of things in the standard library we even have a FAQ entry about it I mean right now stuff exists in the standard library just because initially there was no like gogit and so if we wanted to put some code somewhere it had to be in the standard library I mean there used to be like a space Wars game there was a nntp like using that client there was I mean there was like tons of crap in the standard library and right before go on we deleted a ton of it and we forgot to delete like even more of it so there's a lot of things that are in there they're kind of an accident and like we didn't have internal packages or like you know like private packages so there's a lot of crap that's in there just for like TLS that's only public because of HTTP and so there's a whole lot of like low-level crypto networking details that are like we wouldn't really want to expose on their own we might want them to live on github or something anyway so I don't I don't think the trend is to like put more stuff in the standard library it's really to make it smaller and more modular but I want to add to that with the go modules work that's going on actively and go right now we're making it much easier for a program to pull in a reliably determined set of sources from an external library and we're also developing better module discovery and package discovery tools so that people will be able to find the packages that they want and also have a way of knowing that these are packages that a lot of other people use and are therefore highly reliable and it's tempting to move everything into the standard library but it doesn't solve the problem of who's going to actually maintain it the go team is not particularly large and so we don't want to put something in the standard library which we can't take care of ourselves but what we do instead want to make it possible is that you can build your go program and know that you're pulling in libraries written and maintained by other people that you know are high quality because other people vouch for them that's the direction we want to move in that's great okay we have another question over here my question for Tyler seems that God have been lunch and near me about ten years ago as well as Google cloud me about 10 years ago and but from my point of view support off go in Google cloud and google appengine flexible environment still looks that as a phishing from my point of view are you guys prefer Java aren't you yeah I think this is something that we've really tried to improve in the last couple years so a couple things that are new our App Engine standard second gen runtimes so these like this idea applies for all of the App Engine supported languages but specifically for go if you ever use the App Engine standard before and you had to import App Engine like anyone raise your hand used okay a couple people so now you can use whatever library you want kind of before one of the issues that would come up is you had to use a special package to make HTTP requests so you run your service on App Engine you need to make some API call you can't use net HTTP you need to use URL fetch which was this other package that we maintained now latest version of go that's not something you need to do anymore much much nicer to use and that's all based on G by Z that same technology was used for cloud functions and so we released cloud functions support for go about a year ago I want to say starting with an alpha and beta and go 111 for cloud functions just went to G a so those are some of the ways that we've tried to improve support and then the one other way to run your go code is cloud run and that's you can run whatever language you want whatever language version you want and as long as you're using the cloud client libraries hopefully that's a nice experience and then you mentioned app engine flex that's kind of for someone who hasn't used it it's similar to App Engine standard you can also provide your own container images that you want to run it will scale up for you but it has a minimum instance count of one so you're kind of that's the default level and then if you're comparing that to cloud run which so how many people saw that announcement it was in the keynote today ok a lot more people so cloud run is like surveillance containers so you define whatever container am in g1 and that can bundle whatever go version you want and then that scales up and down really quickly if you deploy it literally takes a few seconds it's really really nice so where we're working on it I hope it's much better than it was say three five years ago and I wanted to put it in a plug for my project the go cloud development kit we're an open another open source project and we're trying to make go a great language for developing cloud applications not just died not just on TCP but on any cloud including on pram or running on your local box so we've developed a bunch of portable api's for cloud services like blob or pub/sub things like that and then we have implementations for different cloud providers so you write your app once using our api's native go api's and then you kind of plug in with simple config or initialization time changes you plug in whatever implementation you want if you want to run locally on your box you use that implementation if you want to run on Amazon you plug in s3 or SNS for pub/sub and so that way you sort of have flexibility and good development workflow okay anything else bad Oh if now we do have a question coming in I just have a question with regards to webassembly what is the road map for you know integrating go with what assembly is will there be one day where we can do away with JavaScript and have go replace it I hope so by now I mean it's getting better none of us are really doing the web assembly back-end there's some people in the NGO team that are reviewing it but it's mostly done from external contributions there was just a change that landed that made it smaller and faster the output the status today is you could take programs and compile them for a web assembly and you could run it on you know alongside node.js stuff where you can run it in the browser and there's kind of a ecosystem of kind of UI framework stuff so you can write it front-end web apps and you can you can write it all today without any JavaScript at all so um you know it's nice –nt but it's coming along and actually I just want to see if we're hearing a little bit through these questions what's new with modules and other aspects functions you know could you just tell us a can one big arcing story what is new with go there's a lot happening well I can talk a little bit about the changes to the language so until the most recent release to 112 we have made almost no changes to the language after an initial phase where we made small minor changes so for the last couple of years we basically have frozen the language even when it comes to smart small minor adjustments that would have been fully backward-compatible but now we're trying to move forward towards what we call sort of go to and as part of this process we've started to look at the incoming proposals that they come from the open-source community and we review them and we identify the ones that seem promising and so for 113 for instance we have started making the first significant changes to the language so now you will have with 113 assuming we're going to actually say yes at the very end of the development cycle we'll have binary literals there's gonna be extra that small floating-point numbers another thing is we can do now shifts without non constant shifts without you int conversion which is probably going to clean up a lot of code and that's what comes tomorrow and literals can have underbar so if you have very long numbers you can have now underscores in there to space them out apparently something that people really want it and there is probably gonna be some changes to the libraries which I probably not have the best overview at the moment I was also going to add that all these language changes that are coming are kind of like warm-up ones for us to work on the process so they're kind of boring and they're kind of small but it's we're gonna do a couple additions to the language we're gonna do a couple removals to the language and kinda like get practice with that process there's a couple constructs in the language that we would like to maybe remove and so modules lets you specify wanna give on the granularity of a module what language version semantics you want so if you say like you're targeting go 112 we can remove something and go what 13 as long as your module still declares 112 that language feature exists but once you want some like new feet shirring go 114 and you say that then you lose the features that we removed and go 113 so well it lets us like slowly evolve the language without breaking anyone so there may not actually be a go to ever we say go to as in like new stuff but it may just be that like you know generics or something fun lands and like go 117 and so keep that in mind whenever we said go to it's probably more of a marketing expression than actually a thing and just to call out the three main things being looked at by the team for go to our dependency management and so modules are the go solution to that came out starting in 111 now again in 112 and then hopefully on by default and 113 and then the others are errors and generics so errors the goal there is to make it easier to develop and respond to and check errors and then last one generics of basically deciding should we include them should we not if we do in what form thank you I think we have a question Brian actually just answered my original question so a different question I think one of gos strengths as you mentioned is how few features it has and when could you give an example of a feature in another language that you really like that wouldn't make sense and go it was a good one you get a plushy well C++ for example is a very complex language but it has a number of features that are very nice for example in C++ you can template eyes based on a constant and use that to compile different versions of your code based on constants that are passed into the template and you can combine that with very attic templates so you can actually redesign your data structures based on how the template is expanded to make them more or less efficient depending on the exact features you need from the data structure you can actually change how much memory it requires at compile time so that's a cool feature and I've used that feature myself when I've written in C++ in the past but the complexity of understanding how that feature really works I don't think it's appropriate for a language let go which is designed to be you know as Robert said earlier it's a language you can learn very quickly if you're familiar with other programming languages even if you're not familiar with other languages it's a great language to start with we don't want features like that I think and go but it's a great question though I mean in general go tries to give you like 80% of what you want to look like 20% of the complexity because you know every time you try to solve a little bit more get it closer to 100% of what you want the complexities ramps up like way faster than the what you're delivering there's one feature that's relatively easy to understand a thing which is macros which Co doesn't have but and you know there's plenty of times when I really really really wanted to have just write a macro but the problem with a macro is it's it's possible to write code that's almost undecipherable afterwards so it's easy you know it's it's like right once understand never so it's it's so it's a feature that definitely is not part of the language that we don't want to have in the language because we put a lot of emphasis on readability of go because code in our experience is read much more often than with and so that's a that's a valuable feature to maintain great I think we have another question coming in yeah so go is about ten years old now so if you can comment a little bit about what the motivations that drove you to develop go ten years ago and are these drivers still valid today so this is a question that's been answered many times on the web but let me sort of try to shortcut it so in 2007 there was a lot of code to be written at Google still there's a lot of code to be written at Google and some of us really felt like at that time the choice of programming languages was somewhat unsatisfactory so we were somewhat stuck between a rock and a hard place if you will some people call it Java and C++ but so we there was a strong desire to have something better and so we we embarked on coming up with something that felt like a much better solution at that time to the kind of systems programming that we wanted to do because it seemed that a lot of the problems were actually solved many many years maybe decades before but were not actually solved in programming languages that were available at that time and so I think a lot of those things are still maybe a little bit less true today because there's actually a wider variety of languages but when it comes to things like concurrency I think go is still like way in the forefront it's I don't know of any other language where it's so easy to write concurrent code in terms of compactness I think go is still extremely small language and very easy to you know grasp and understand so I think many of these things are still valid and of course that language is not just compact and small and clean but it's also very efficient and I think that's still true I mean we're still we're maybe not at C or C++ level but we are close enough for you know 99% of all applications and I want to also allude to something that Tyler mentioned earlier which is that go the language was designed for as much as possible for programming in the large for many people working together on one program and a lot of decisions about the language were made with that in mind you know how well we succeeded at it I'm not sure but I think it was an important goal at the time and I think it's even more important now especially is open-source has continued to get larger and larger and larger languages that help people work in larger groups I think is very important very important goal for modern languages and I think au has aimed for that all along okay I know we have a very patient person over here who's waiting to ask a question one of the things I've really enjoyed about Doh is the community and I'm wondering how you all stay engaged with the community and help build baths especially in the face of contentious decisions or changes to the language so the question is about the community and how we well how we work with it I guess yeah the community for NGO has been has been incredible we've had so much support from you know from all of you from people all around the world working and going contributing to go and then you asked how do we deal with contentious decisions I think we try to I think we try to be as open as possible about how we're making our decisions and I shouldn't even say as open as possible we try to be completely open about why we're deciding the way we're deciding and they do things Nuka contentious at times there are disagreements in the community of course there have been disagreements in the past and we listen to them I mean an easy example is for the product you know the language added a feature type aliases maybe three four years ago and before type aliases were introduced we actually had a separate proposal which was a different kind of aliasing proposal and we designed it Robert and I both worked on it and other people within Google we put it out there saying this is something we think will be useful that we'd like to add language and there was a lot of pushback in the community it did become contentious and I think we tried as hard as we can't could to listen to it we withdrew the proposal we put out a smaller and simpler proposal which did get then get added to the language also we explained you know the use cases for it and so I think it's been a learning process for all of us to work with the community but I feel like you know the answer really is just to be just to be open to explain why we're thinking what we're thinking we can't take every idea that comes in we don't agree with every idea that comes in ultimately you know a small group of people is going to make the very final decisions about what's going to happen but still most of the best ideas have come in from outside so yeah that's great you know things important any other comments on that one okay then I'm gonna take a question on this side all right so you guys are great at keeping stuff backwards-compatible but if you go if you could go tomorrow to work and just change something completely without thinking about it what would that be so um if you can go back all the way to the beginning of go the original go look very very different than the one that we have now and in the early days we had the luxury to actually make a lot of changes for instance the very first version of God you had to write semicolons and now you don't have to write them anymore actually you know for last ten years didn't have to write them and there's a whole bunch of things that we probably would like to remove some of which we can't remove right now one of them again a simple example is right now you can convert it you can say string off an integer and that gives you the corresponding it doesn't give you a string version of that integer value it gives you the corresponding Unicode code point as a string so to speak and that's very confusing and that's that was there just for historic reasons because it was convenient in the beginning and that's something we want to write I want to take out but we can't because it's very potentially things and there's a there's a lot of other things probably I don't have a good list in my head at the moment but ranging over a string giving you the UT utf-8 code points rather than the bytes of the string which is inconsistent with a slicer by its there's things like when you do a arrange loop and you want to capture you have a closure that captures one of the variables the variables are is like the same variable for the whole loop brother than every iteration of the loop so you can't safely start a go routine with a closure in the middle of a loop and that bites a lot of people so there's a lot of little things that you know we realized after the fact but we can't really change it Eric get rid of return statements that don't list the values that are being returned from the beginning we tried to make go really platform-independent and so most of the language is actually platformer any better you can write some code and you can run it on any platform but some basic things like the integer type int or you int they are platform dependent you know if you're running on a 32-bit platform II you get a 32-bit in and if you're running on a 64-bit platform you're running you're getting potentially a 64-bit in maybe maybe a 32-bit in so that's actually something that I think in retrospect was probably a mistake because if you actually move from one platform to another you might incur problems so you may have to change code and things like that so we nice if we'd had a better solution for that and one approach could be or could have been maybe that an int is arbitrary size you know and the compiler does the right thing and you never have to worry about it that's something that would be much much harder or it's going to be much much harder to do now we have a few minutes left so we've got a few questions people are queuing up so we'll see if we can go quickly answer some more chairs really quickly uh what would you say has been the biggest challenge in creating go or just a programming language in general I mean is it the intricate technicalities or is it understanding user behavior and creating something to adapt to user behavior so what's been the biggest challenge and go I'd say that for me at least the biggest challenge is keeping it simple it's always so easy to add another feature and you can see so clearly how useful it would be to have this new facility in the language but if we add every new facility in the language then we got something so complicated that is very difficult to use like some existing languages today and so I'd say the biggest challenge has been to say no okay okay over here it's mandatory to pass the context No what do you think about it and also I've read in the internet somewhere that contact will be removed in go I don't know there are no plans to remove context if anything will become more pervasive in my natural regime of passing the context in the first argument do you think everybody should do it outside Google yeah probably so inside Google a lot of it was kind of implicit with like magic thread local stuff and so it was kind of great when it worked because your context was threaded through automatically because all all functions just kind of picked it up from a thread local storage but once you start to do something tricky a lot of people didn't know how to stitch together their threads their context and they wouldn't even know that they didn't do it until they had a production problem and they went to look at like the the the global trace dashboard and then they noticed that none of their stuff was stitched together properly so if you make it explicit you get it right from the beginning so when you have a production problem it's you know it's usable the the traces and as far as whether the context is the first argument or not it's convenient to have it to be the first argument it just makes it the code be stylistically consistent but it doesn't have any meaning beyond that it just helps if the code looks similar in different parts of Google one thing I'd like to do is maybe make context context be less stuttery because right now you write you know C T X and so if you're reading it it's like context context context and if right now we have one built-in type in the language that one built-in interface type which is error which is just an alias you know for anything with an error string method so it'd be kind of nice maybe just make context first class too and make that built-in so at least then it would be used to be context context or something okay so why don't we just get add we can get one maybe two questions and we'll start on this side I for such a new language I think my math is right but there's like over 50 years of experience and knowledge just on this stage can we get maybe one tip from each of you on like for writing and go and getting into the go mindset I'll start and I'll take an easy one run go funk and require it on submit you should run it on save as you're writing your code same ways go imports small functions lost lots of tests flava Teton the in the playground and you know experiment be careful with contacts I've had a lot of bugs with using the wrong context in the wrong place be explicit about what you're trying to do keep your functions you know don't use implicit information pass between functions okay great we're gonna sneak in one last question and then we'll wrap it up hi everyone I have a question for Brad you started writing the second iteration of the net HDTV package can you talk a little bit about the problems you have with the your original iteration of it and maybe what the status is well I have a long wiki page about all the things I kind of dislike about the first one which kind of grew organically over ten years or so so I don't really have time in 30 seconds to go over that but the current status is I got distracted and you know there were other fires and stuff so I it's still my goal it's like probably the highest priority thing I should be doing is finishing up the the new HTTP client we're all looking forward to it okay well we're out of time but thank you so much for joining us and all your great questions all the credit goes to these great experts in the community and it's building go

5 thoughts on “Meet the Authors – Go Language (Cloud Next '19)

  1. Great talk team. The generics proposal is great, even without contracts. Looking forward to seeing that in the language!

Leave a Reply

Your email address will not be published. Required fields are marked *