Why Go Is Successful (aka Simplicity is Complicated)

obviously NGO is successful if you look at this room look at what's going on here yeah and a lot of people have asked why NGO is successful or ask me why NGO is successful and a lot of people have answers that involve tooling or the language or things about it but I think those are all sort of superficial reasons I think the real reason is simplicity NGO is simple at least compared to a lot of other languages that are running around at the moment and so but simplicity is actually a complicated subject and there are many ways to think about it last year about May I think I went to a conference hosted by Microsoft called lion got mixed and I saw a number of actually quite interesting talks many of which were the leaders of a particular language talking about a new version that was coming out like JavaScript PHP C sharp and so on and I really was struck by one thing about these talks and these languages which is most of the talks consisted of features being added by taking something from another language and adding it to this one so you know Java scripts getting classes and that kind of thing and I realized that what's happening is all of these languages are turning into the same language there's a concept called language relativity in linguistics which is also colloquially called the sapir-whorf hypothesis although neither sup here nor Worf quite agreed with it and the idea is basically that language influences thought and the sort of cartoon version is you know if you speak French your your your more amorous and it's pretty obviously controversial there's some evidence that there may be some truth but not very much but I think it's really obvious if you think about it that computer languages this very much applies if you're in a logic programming language you write a very different kind of program you think a different way than if you're using an object-oriented programming language or a concurrent one it's very much like disciplines in mathematics you don't solve calculus using linear algebra even though they have some structural comparisons and so I'm worried about this trend in the languages because they all converge to the same language we're all going to be thinking the same way and that would make life very very uninteresting you want to have different languages for different problems you want to have different domains we solve by different ways of thinking and different notations in other words you kind of want a tool that's optimized for each particular way you're working now these tiles that line next we're about things like Java eight equi script six which has been a long time coming c-sharp C+ was 14 and the few others that didn't quite fit this mold but let's just talk about the ones that do as I said these languages are evolving by adding features that means they're becoming more complicated their complexity is growing while they are simultaneously becoming more similar to one another that's a very strange situation for a field to begin I would summarize that is bloat without distinction go however as I hope you appreciate isn't like that goes a different language in this respect it doesn't try to be like these other languages because it's not taking features it doesn't try to compete by saying oh if they have that feature we better have it or people will be unwilling to use their language in fact as of goal one which is what three years old now the language is fixed you know you may have noticed that the features that have gone in since then are absolutely tiny there's really been no significant change to the language since it's go one and that was the point of go one however many newcomers to go start by asking can we add this feature of the language can we make air handling different can we change the way arrays work or something like that but the language is fixed those things don't get to go in but it's not just that the language is fixed it's because adding features will not really make go better and why is that true it would just make it bigger but it would make it less different and both of those are worse in my opinion but obviously you need features you can't have a programming language without some features in it but which ones well obviously the right ones and so we picked the right ones how did we pick the right ones well one way is that the original language was designed by Ken Thompson Robert Greer and myself and we all have very different backgrounds Ken and I had worked together at Bell Labs quite a bit but we also had done very different things and you know ken is a God so when we came to talk about what was going into the language we insisted that all three of us not only agreed with the feature going in but agreed that it was the right feature to go in and with our different backgrounds and different perspectives that dramatically narrowed the number of things that went into go but you still have to pick what to put in and our overriding thing for doing this was readability and here's how we think about this if a language has too many features or even more than you know you might need you've spent time programming thinking about which features to use if there's really a lot of features you may look at the line of code write it one way oh I could do something different I could use this feature I use that feature you might even spend you know half an hour playing with a few lines of code to find all the right ways you could use different features to make the code work a certain way and it's kind of a waste of time to do that but worse when you come back to the program later you have to recreate that thought process you not only have to understand this complicated program programming language doing whatever it's doing you have to understand why the programmer who might be you decided that this was the way to approach the problem from the feature set available and that is just I think bad engineering the summary summarization of this is the code is harder to understand simply because it is using a more complex language you want to have just one way or at least fewer simpler easier to understand ways so in other words features add complexity we want simplicity features hurt readability we really want readability and readability is by my opinion the most important feature of a programming language because readable means reliable if you can read the code and know what it means then you can it's easier to understand it's easier to work on it's easier to extend it's easier to fix when it breaks it's easier to understand why it's broken these are all good things and that is why readability is so important if the language is complicated on the other hand you have to understand more to understand even where to start working on the program and you have to understand a more complicated model in which the program is being written these cost time and make the language harder to use but there's a trade-off obviously making more features in a language gives you more fun things to play with and so there's a fundamental trade-off ingo that was made in a different direction from most other languages and the trade-off is what do you want a language is more fun to write in or easier to work on and maintain and for the most part the decisions in go about what went in were about long-term maintenance and in particularly in the context of large-scale programming although that's a little off the topic today no the thing is you put features in to make languages expressive you obviously want to not have to type you know hexadecimal numbers which would be a very low feature way to write code but obviously very hard to use you just be careful because you make something too concise it can become just unreadable this example here is a real working program in a dialect of APL called dialogue and an implements Conway's Game of Life and I think you could argue even if you're an expert APL programmer it's not very readable APL is famous for being easy to write and hard to read but and I think it's very we have to be very careful we don't write software like this in the modern distributed multi programmer you know open source world but there's a more important point I think well maybe maybe an equally important point which is when you have features that add expressiveness they typically add expense for instance a lot of people have asked for things like map and filter to be built in to go and we said no one of the reasons we said no is that if you if you have things like map and filter they're going to use them that's why they're there but they may be more expensive than a simple for loop and when the features are there to make life easier and more expressive they tend to generate more expensive in terms of computer time solutions to problems that have much simpler solutions so they're also they may help the programmer although not always but they'll almost always hurt the computer unless the implementation is extremely smart and believe me the implementation of APL is extremely smart so that actually is a modestly efficient implementation of the game of life but you wouldn't you could do much much better if you wrote a simpler program but you gotta be careful because if you make everything too expansive and explain everything in detail you get a very verbose language I won't name any but you know the ones I'm thinking of where it just seems like you're writing too much to say a simple thing so you have to balance this no so what we did was we tried to make the right selection building on the ideas that we're familiar so that a programmer with a background in procedural programming like with C or Java or even you know Fortran say could read a go program and get a pretty good idea right out of the box what was happening and not be confused by strange notation so you have to balance you have to be concise but be expressive make sure that the program is easy to read you have to pick the right fit set of features in other words not just features for features sake way I like to think of this is to think of the entire world of programming is a vector space of very high dimension and what you want to do is to find the basis set that covers that vector space so that you can write the program's you want by combining the appropriate orthogonal because that's what basis that is orthogonal set of features and what happens when you add features for expressiveness or for fun is it tends to add more non basis vectors into that space and so there become many paths to get to a particular solution so that's when we say features are orthogonal that's what we mean we mean that they cover this space but we also mean they interact really well so if you take feature a and feature B and you write a program that uses them they work exactly the way you expect feature a and feature B to work they're not as some weird diagonal that causes all kinds of complications you have to worry about again I won't mention which language I'm thinking of so you have to keep all of this in mind when you're designing a language and also think about what the goal is what are you actually trying to achieve what is the problem domain that this language is being done for well in gos case we were trying to write code for Google because that's what we do and go is software that at least the parts that we work on are mostly infrastructure server infrastructure what we now call cloud software but used to just be called servers and to do this you have to find enough pieces to build the software and so the fundamental components we started with were ideas like concrete data types you know integers structures floating-point numbers functions and methods interfaces packages concurrency and then the sort of guiding engineering principle of having a really good fast implementation with the ability to have a really good tooling and with that's sort of all with all those guidelines which is a fairly complicated set of considerations the fesus sort of fell into place and actually ended up being kind of simple in practice and in fact simplicity can be expressive this is a very simple drawing when Rene drew this a while back and yeah he's expressive right he's not really a gofer and I'm not talking about the Magritte version of Sistina buzzing gopher I mean he's just the representation of a gopher very much like like shreves talked earlier with the horse right and so this for me is what is part of like the ethos of go here's this really simple drawing that represents what Gogh is like we can put more features don't we make it more like a gopher we could give them lots more detail and we get something like this right but mostly what we've added is ugliness and hair we haven't actually made embedded right its complexity without clarity so but I want to make a really important point here which is I've said go as simple but it's not it's very complicated I know I worked on it it's one of those complicated things they've ever worked on and yet it feels simple and I think that's a really important idea and it feels simple because these pieces fit together orthogonal and that requires a lot of design a lot of thinking a lot of refinement and implementation and re-implementation and to put a very bluntly simplicity at least in this context is the art of hiding complexity so let me talk about a few simple things and go and why they're really complicated garbage collection goroutines constants interface and packages each of these things is very simple and very complicated but at the same time there's a lot of other subjects I could pick but let's quickly go through these garbage collection is probably the best example of simplicity hiding complexity what is the programmer interface for garbage collection there isn't one can't get simpler than that the empty set is as simple as it gets right and yet look how hard it is to implement all that incredible code to deal with stack maps and you know the copying the stacks on when you need to grow them and tracking all the references down pausing it running in parallel with the with the mutator it's a tremendously complicated problem that fortunately I didn't have to work on we have some really good people in the go team who did but I think it's amazing to consider how much code is there for something that has absolutely no user interface there isn't even a free function in go there's nothing but garbage collection memory and it's remarkable to point out that it isn't even in the spec the goal language does not define that it is garbage collected in the specification the only mention is in the introduction was a throw throw away property of a feature of language that's how small and therefore how simple the spec is I mean that the garbage collection is and you how complicated it is behind the scenes and it also makes code simpler because you don't have to think about who owns the data who's going to free it how to manage it for you you can think about implementation details and efficiency but for just straightforward go programming garbage collection hides everything it's fantastic and one of the things that people love about go is the concurrency I think it's arguably one of the simplest concurrency models available in a programming language not that they're that many but there are some others there's several components to it go routines channels and select and I'm gonna talk about go routines for a minute you start a go routine with the go keyword you say go space geo space and then the function call so three keystrokes you can't make it much shorter than that yeah I can imagine one or two changes I can take but three keystrokes and you've just started a sub process in the general mathematical term and so it's like garbage collection because it's extremely simple UI there's nothing in the UI about the size of the stack or a thread ID or managing goroutines show them down things like that there's there's no completion status there's no type a lot of people ask for these things that in fact some other languages or thread packages provide the equivalent functionality of some of those things but we didn't put them in we wanted to go key word to be so simple that had the minimum possible UI here's a function call run it alongside my other things three keystrokes and that's part of this minimal design and then Crossley's talked earlier today he talked about one of the reasons I think you can appreciate now why Frances are no ID on a goroutine internally of course you have a lot of complexity managing this managing the relationship between the goroutine implementation the runtime stack and the garbage collector for example credibly complicated behind the scenes stuff but three keystrokes constant this is one of my favorite things about NGO that most people don't even think about and they don't think about it because it's incredibly simple when we decided that go ahead to be strictly typed that meant that numeric types could not be interchange freely that was a very common source of bugs in C and C++ you were not allowed and go to take an int and put it into a float 64 or anything like that but that can be very clumsy you don't want have to say float 64 zero every time you want to use a floating point zero so we had this idea which is one of those I think relatively novel ideas which is that we made constant just be numbers they're just numbers even though the language is strictly typed and this means you get to throw around things like 1e9 dividing into a time dot second which has a strict type and to get this to work was really art is one of the hardest things in designing language not in implementing it so much but designing it we had to worry about what infinite presented and precision integers means what infinite precision floating point means what happens to the promotion rules if you divide an integer two versus divide a floating point 2 and you get corner cases like this crazy shift which I can't run but what do you think the answer is to this what does this program print it's got a 2.0 and a 2.0 shift is zero and asking the type of both of them you have to think don't you this is a place where the complexity comes up you get an you actually get a float 64 in an INT and that's not a good thing it's just a consequence of the rules that we've eventually converged on to make constants work right but for the most part you never see these kind of words when you're using constants they just feel like numbers and it's fantastic so I'm not totally satisfied but I think it was a really good example again of simplicity hiding complexity and I wrote a blog post called on blog that golang.org slash constants that talks about this stuff and much more detail interfaces one of those favorite features for myself and I think for a lot of programmers a very simple idea all there is is a set of methods people ask for data as well all the time not going to get it it's just it's just functions very simple you also need a variable of type interface you can program with these things but even here you get some funny things happening because you for instance can assign OS dusted into a reader no problem you can assign OS dusted into an empty interface no problem but if you have to narrow the interface you have to do a dynamic type check which we call the type assertion and one of the things that's not well-known about go is that was not in the original design we realized a few months into it that we needed type assertions to make the program work right the addition of effectively dynamic typing into a statically programmed language was a complicated thing that we had to deal with and make it work and it's I'm not totally thrilled with how it worked out but I think it's pretty good and it does in the end do its job but for the most part what you have again is a very simple idea an interface is a set of methods and with again a quite complicated set of rules behind them that mostly just do what you want but it was hard in fact interfaces are probably goes most distinctive and powerful feature I think concurrency is talked about a little more but you don't write as much concurrency in a typical program as using your faces interfaces have a profound effect on the library they've enabled the very structure of go programs to be the way they are with a I think the most component oriented architecture of any programming language I've used and so they in fact I think can safely say they are simple to use even though they add complexity they're worth it and finally packages packages are one of the hardest things we had to deal with in design the language it doesn't seem like there's anything there what do you have you have packaged big there's the name of the package you have import stringing the client we're gonna what's there it took us months to figure this out because it interacts with things like scoping naming information hiding isolation linking compiling cross compiling and getting all those details right took a very very long time and but on the other hand you guys never think about this stuff right they just work somebody earlier today said import was this favorite keyword that's great I love it and all that complexity which is fantastically intricate when you start talking about working across multiple language implementations of you know four different architectures and different operating system it's all hidden behind this simple package idea that has basically two concepts and that includes things like GoGet which is a fantastic enabler for open-source based on the fact that the import string is literally that a string with no semantic meaning within the language so again very hard to implement very complicated under the covers extremely simple to use and I think after garbage collection packages are actually the most the best example of simplicity hiding complexity let me show you here's a simple example it's just the sort of standard hello world server it's written with some Japanese in it because why not but you I think and recognized as competent go programmers very quickly what that program does I don't need to run it it does run it does what you think very simple right it's hardly anything they're just a few lines of code starts a server runs it okay here's what's going on inside this program first of all most visibly it's doing unicode utf-8 working flawlessly it seems porting some magic packages and they're being used from flog net HTTP HTTP being one of the most awesome packages there's an F printf directly to a network connection which is interesting and unusual there's a function being promoted to a method that with the handle func in there which is a bit of a mind blow to people knew to go was mind-blowing to me when it was pointed out to me about rust that we could do that it's also truly concurrent this server won't block as long as there's enough resources on the server hardware you can have zillions of people talking to this service simultaneously which is to say it's production ready there it is a production ready web server in just a few lines of code it doesn't get much simpler than that right so in summary simplicity is complicated but the clarity is worth the fight I don't want to hang out with the gopher on the right I want to hang out with the guy in the left he's much more expressive and fun and much less hairy so in conclusion simplicity is very hard to design it's very complicated to build it sounds strange to say that but it's true making things simple is hard work but if you get it right you get something that's very easy to use and I think the success of go and the fact that you're all here listening to me proves that there's something there thank you [Applause]

Channel: Coding Tech

Views: 111,315

Keywords: golang, go, go programming, software development

Id: k9Zbuuo51go

Length: 22min 26sec (1346 seconds)

Published: Sun Feb 25 2018