How GO Was Created - Less Is More | Prime Reacts

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
the command center less is exponentially more I assume this is a talk about go I can just I feel it I feel this is about go by the way I my my shaver broke if you're wondering why I'm turning into a bearded man I don't know what to do with my life okay I I want to have a mustache but I literally have no availability to have a mustache here is the text of a talk I gave at the Go SF meeting in June 2012. this is a personal talk I do not speak for anyone else on the go team here although I want to acknowledge right up front that the team is what made and continues to make it go happen I'd also like to thank the go SF organizers for giving me the opportunity to talk to you I was asked a few weeks ago what was the biggest surprise you encountered rolling out uh ago I knew the answers instant instantly although we expected C plus plus programmers to see go was an alternative instead most go programmers came from languages like Python and Ruby very few can uh come from C plus interesting their original goal was C plus plus huh I wouldn't have expected that I actually thought it was python I I genuinely thought python was the target market they were going for because go has this like python-esque feel to it and it just feels like a natural transition you know what I mean wrong I would have I literally would have never guessed that um all right we Ken Robert and myself were C plus programmers when uh when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote it seems almost a paradoxical that other C plus programmers don't seem to care this is hilarious really this is so good they wrote a language solving problems of the language they're used to and then no one else agreed with them oh dude a hot take that's because people who program C plus plus like to program C plus plus they're kind of like wrestlings right I don't think people that love rust could go to another language right they're kind of like sucked into the rust hole and I feel like C plus plus is kind of that you have to like you have to copy I'm super hard to really love the language don't worry I have copy I'm tired myself okay and uh and there comes a point where once you have that hammer and you're really good with the hammer you can do anything oh camel by the way is the greatest language ever created even though I haven't done a lot I actually have an opportunity to do some language server stuff for my job maybe and I I want to explore what is the best language to write out that it'll probably end up being in Rust but it would be really fun to uh consider go or uh oh camel uh the answer can be summarized like this do you uh think less is more or less is less here's a metaphor in the form of a true story Bell lab centers were originally assigned three letter numbers one one for physical research one two seven for computing research or Computing science research and so on in the early 1980s a memo came around announcing that all the understanding of research had grown and had become necessary to add another digit so we could better characterize our work so our Center became one one two seven Ron Hardin joked half seriously that if we understood our world better we could drop a digit and go down uh from one to seven to just to seven oh that is super good I like that of course management didn't get the joke nor were they expected to got him stupid management but I think there was wisdom in it less can be more the better you understand the pithier you be you can be the best here you can be um keep that in mind okay I like this I like I I love this philosophy right I actually really do like this philosophy back around September 20 uh or back September uh 2007 uh I was doing some minor But Central work on an enormous go C plus plus program one you've all interacted with and my compilations were taken about 45 minutes on our huge distributed compiler cluster she an announcement came around that there are going to be a talk presented by a couple of Google employees uh serving on the C plus standard committee they're going to tell us on what was coming up with a zero plus yeah yeah right um as it was called at the time it's now known as C plus plus 11. oh damn this was pre-c plus plus 11. ew well I mean obviously it's pretty pretty but either way see before C plus plus 11 C plus plus was really just I feel like at least with you got like some smart pointers and stuff in there uh but I guess they probably used boost and they had all the all the things they ever needed uh in the span of an hour at the Taco oh we heard something like 35 new features that were being planned in fact there were many more but only 35 described at the talk some of the features were minor of course uh but the ones in the talk were at least significant enough to call out some were very subtle and hard to understand like our value references still don't understand it the others were especially the C plus plus like like variatic templates and some others that are just crazy like user defined literals cholastic C plus plus what does the world need more features features will continue until morale improves that is that is a that is literally it I'm tweeting it uh C plus plus uh uh a lang designer uh features oh we'll continue until morale improves this feels like a good this feels like a good tweet I feel like I could say it better but we'll keep it there we'll keep it there you know you don't have you don't want to overthink tweets right you just want to have the one that kind of comes into mind right uh let's see at this point I uh I asked myself a question did the C plus plus committee really believe that uh was let's see that was wrong with a c plus was that it didn't have enough features this was this was almost 20 years ago how funny this article ages like a fine wine uh surely in a variant of Ron hardin's joke it would be a greater achievement to simplify the language rather than add to it of course that's ridiculous but keep the idea in mind just a few months before that c plus talk I had given a talk myself on what you can see on YouTube about a toy concurrent language I had built way back in the 1980s that language was called new squeak oh beautiful uh and of course it was a precursor to go I gave that talk because there was there were ideas in new squeak that I missed in my current work at Google and I had been thinking about them again I was convinced they would make it easier to write server code and Google could really benefit from that and I actually tried and failed to find a way to bring the ideas to C plus plus really it was too difficult to couple the concurrent operations with C pluses control structures and in turn that made it too hard to see the real advantages plus C plus plus just made it all seem too cumbersome although I admit I was never truly facile in the language so I abandoned the idea I mean this is a cool idea the fact that he tried to take these good ideas and then put it into C plus to try to make it like a you know instead of creating a new language can you create a library or something that kind of fits the mold and does the right thing I mean I I can appreciate that but the C plus plus hex talk uh got me thinking again the one thing that really bothered me and I think Ken and Robert as well was the new C plus memory model with atomic types it just felt wrong to put such microscopically defined set of details into an already overburdened type system it also seemed short-sighted since it's likely that Hardwell will change significantly in the next decade and it would uh it would be unwise to couple the language too tightly to today's Hardware Great foresight by the way right there uh I really like this is such good wisdom when thinking about things right like I I know this talk is is damn near 12 years old at this point or 11 years old almost on the dot but it's shocking house it's shocking how wisdom remains unchanged but ideas can change quite a bit it's a beautiful thing all right anyways uh we returned to our offices after the talk I started another compilation to turn to my chair around to face Robert and started asking pointed questions before the compilation was done we roped in Canon and decided to do something this sounds like every single time I've compiled a long compilation I get sidetracked and I just get off and oh man the race begins right we did not want to oh we did not want to be writing C plus plus forever don't blame you I believe that's called purgatory and we me especially wanted to have concurrency at my fingertips when writing uh Google code we also wanted to address the problem of programming in in the large head-on which uh about which more later okay we wrote on the Whiteboard a bunch of stuff that we wanted uh what is this word I don't think I even know this word desiderata does it deserterada what is this word I don't even know it man this guy is just just things that are desired it's about life okay I never read this poem okay well note to self read that letter uh desert uh Desai Desai dirada designer wow that's a hard word to say I'm sure I I'm sure I missed saying it if you will we thought big ignoring details syntax and semantics and focus on the big picture that's good I still have a fascinating male thread from that week here are a couple excerpts Roberts starting point C fix some of the obvious flaws remove crud and add a few missing features okay Rob name go you can invent reasons for uh for this name but it has a nice properties it's short easy to type tools go see go L go uh go a and there's interactivity debugger interpreter it could just be called go the suffix is go this is good Robert empty interfaces interfaces these are implemented by all interfaces and thus could take the place of voidstar I like this but I think this is a failure of a of a complete enough type system I really have never been a huge lover of the interface thing the whole that that's one thing that's always turned me off from go that's why I say I feel like tight unions have always just been something I really want our tagged unions this is something I've always really wanted is just give me some tagged unions give me tagged unions in a basic way to manage memory in some sort of way other than GC which they did with this whole Arena idea and you have like most of it kind of completed um which is very very exciting for me and then just throw a little bit of Syntax for handling errors based on the convention that's now there for 10 years and you literally have a language that I think is just beautiful uh we didn't figure it all out right away uh for instance it took us over a year to figure out arrays and slices but a significant amount to the flavor of the language emerged in that first couple days notice that Robert said c was the starting point not C plus plus I'm not certain but I believe he meant C proper because uh especially because Ken was there but it's also true that in the end we didn't really start from C we built from scratch borrowing only minor things like operators and Brace brackets and a few common keywords and of course we borrowed the ideas from other languages we knew in any case I see now that we re uh reacted to C plus plus by going back down to Basics breaking it all down and starting over isn't that pretty much what happened with C plus plus to begin with they didn't like C broke it down made some changes boom made a horrible language you just did it again we weren't trying to design a better C plus or even a better C it was to be a better language which overall for the kind of software we cared about and in the end of course it came out quite different from either C or C plus plus more different even than many realized I'm in a list of significant simple simplifications and go over CNC plus regular syntax don't need a simple table to parse garbage collection only yep no header files this right here explicit uh dependencies no circular dependencies constants are just numbers uh Anton n32 are distinct types beautiful uh letter case sets visibility I hate this this is I I would I really wish that one wasn't that uh methods for any type no classes um yeah this is good but I mean in a sense you kind of create classes this way I mean I like what they've done I I prefer the Go version of classes if you will I like this no subtype inheritance this is always just a good decision package level initialization as well-defined order of an initialization isn't this largely considered a failure uh in it any init functions are largely considered a failure I'm pretty sure that's true files compiled together in a package package level globals presented in any order uh no arithmic conversions constants help I always like a just uh automated uh upscaling events right so if you do like a 32 plus a 64 it just goes to 64. that always seems like a reasonable that always seems like a reasonable cast up can we all agree with that one it's like I get why you'd never cast down or cast sideways to like a float right like I would never want a 32 to a float I can see why you'd want explicit to be explicit about that just because you you change the underlying underlying binary representation I'm on that team and so then doing binary operations would then necessarily have to do what JavaScript does which casts your number type which is a 53-bit minus one amalgamation of dumb ideas into a 32-bit signed integer for just that simple operation right so I can totally get why you'd want these things uh interfaces are uh let's see if interfaces are implicit no implements declaration and what I mean by that for those that don't understand what I'm saying right there check this out sorry I realize that node thing's like pretty specific if I go like this one uh one uh 30 you get this if I go 131 you go negative which is probably surprising to a lot of people and if you go 132 you go all the way back down to one because there's actually an implicit casting so if I go like this one uh if I can I can I go even further look at that look at those fun things that can happen you wouldn't expect a lot of these weird things to happen right and can we go like this and then or zero look how beautiful that is like you can just get these weird results right on the end because you don't realize that there's a signed integer that's happening underneath the hood and if you're doing anything in this region it can be very surprising right and so the first time you encounter this you're like why is that happening I don't get it and it's because you're just getting hit with the two's compliment right you're just whoopsie daisies you know what I mean so uh interfaces are implicit no implements okay I love that embed embedding no promotion to superclass okay methods are declared as functions no special location methods are just functions yep interfaces are just methods no data type methods matched but uh by name only okay I like it I do like that because that means no I go back and forth on function overloading do I want overloading or do I not I go back and forth because you either overload it by name right then you have like Foo with float Foo with this flu Foo with that I never know I never know if I like which one uh no Constructors or destructors I can buy um uh post increment and post-decrement are statements not Expressions okay nice no pre-increment or uh pre-decrement a sign uh is not an expression of valuation in order to find an assignment function calls no sequence points no no pointer arithmetic that's probably a good idea no pointer arithmetic memory is always uh zeroed I think this is always probably good you should give an escape hatch for unsafe Alec but this should always be the default I think that this is just a safe beautiful way not to f yourself right that's why I think I think node actually did end up doing it right with their mistake of a buffer class uh but that uh Alec unsafe I think was a really good move right I really do think that that was one of the best design Decisions by the the the node team dopa for being a a mistake right uh legal to take addresses from local variables uh know this and methods yeah but then you I mean you effectively recreate it by having a named version and which is now just a single letter and I don't know how I feel it segment and sex beautiful no const or other uh type annotations no templates no exceptions no templates beautiful but then they kind of they kind of went back on that with generics in 118. I like generics I wish they had a little bit stronger generics but I also feel every time I do a generic I have I I have to ask myself twice am I really building the right thing because I have to be sure uh built-in string slice map beautiful array bounce checking beautiful those like these last two this is just like it's crazy if you don't have those right uh and yet with that long list of simplifications and missing pieces go is I believe more expressive than C or C plus plus less can be more but you can take uh you can't take out everything you need building blocks such as an idea about how types behave uh and syntax that works well in practice and some uh ineffable thing that makes libraries interop well they never even mention anything about errors as values which I think is one of the Go's greatest contributions is errors as values I mean I already know is the thing and there's other languages that did it but go is a very mainstream language and for it to kind of bring that idea forward it was beautiful I just wish they would have thought of syntax and I still wish they would consider syntax around it we also had some things that were not uh like uh in C or C plus plus like slices and Maps composite literals Expressions at the top level of the file which is a huge thing that mostly goes unremarked reflection garbage collection and so on concurrency to naturally concurrency their the model ghost concurrency model might be the best ever uh one thing that is uh conspicuously absent of course is type hierarchy allow me to be rude about that for a minute please be early in the rollout of go I was told by someone that he could not imagine working a language without generic types as I have reported elsewhere I found that an odd remark to be fair he was probably saying in his own way that he really liked the STL does for him in C plus for that purpose of the argument though let's take his claim at face value what is uh what it says is that he finds writing container lists of ins and maps of strings and unbearable burden I find that odd I find that an odd claim I spend very little of my programming time struggling with those issues even in languages without generic types but more importantly what it says is that types are the way to lift that burden types not polymorphic functions or language Primitives or helpers or uh or other kinds but types that that's the detail that sticks with me programmers who come from go or come to go from C plus plus this is a really interesting statement by the way I probably shouldn't have glossed over that so quick it's a really interesting statement huh programmers who come from go uh come to go from C plus plus and Java missed the idea of programming with types particularly inheritance and subclassing and all of that perhaps I'm a Philistine about types oh what I don't even get what that means uh but I've never found that model particularly expressive yeah I find well the problem is is that it's an extremely constrained way of uh being expressive and it always ends up being just a burden uh my late friend uh is it Elaine Elaine of thornier once told me that he considered uh the lowest form of academic work to be tax on taxonomy uh what do you let's see and you know what type hierarchies are just taxonomy you need to decide what piece goes in what box every type's parent whether a in hairs from b or B from a it is a sortable array an array that sorts or a sorter represented to buy an array if you believe that types address all design issues you must make that decision this is a very interesting argument because I almost feel like it's the antithesis to like uh Russ argument or Haskell's argument right is this like an is this like a a purely anti-lisp rant code is data data is code very interesting oh no I believe that's a Preposterous way to think about programming what matters isn't the answer uh the answer okay yeah he's specifically talking about that okay yeah then I I'm fully on that team uh what matters isn't the ancestor relations between things but what they can do for you that of course is where interface is coming to go but they're uh part of a bigger picture the true go philosophy and if C plus plus and Java are about type hierarchies and taxonomy of types goes about composition Doug mcclory mcglory uh well uh the eventual inventor of Unix pipes wrote in 1964 we should have some ways of coupling programs like a garden hose screw in another segment when it comes necessary to massage the data in another way this is the way of IO also the the man is way ahead of his time oh is that an i oh that is an eye McIlroy way ahead of his time beautiful I love that I thought it was two L's that's why I was like mcclory McCoy okay it's uh it's a it's the prime machine yeah uh that way uh of go let's see that is the way of go also go takes the idea and pushes it very far it is a language of composition and coupling the obvious example in the way uh interfaces give us the composition of components it doesn't matter what the thing is uh if it implements method M I can just drop it in here quack uh another important example of how concurrency gives us the composition of independently executing computations uh and there's an let's see and there's even an unusual and very simple form of type composition embedding uh these compositional techniques are what give go it's flavor which is profoundly different from the Flavor of C plus plus or Java programs you know the surprising part about all this he hasn't really talked a lot about concurrency I think concurrency is their greatest feature of go maybe it wasn't as big as it like maybe the initial phases weren't so well thought out but the asynchronous part is just so like there's so many things to love about it and we read that red blue article not too long ago I love the fact that go is colorless you don't like you don't have to handle a lot of these Concepts like that there's something about that that is just so good and I love that I truly truly love that uh there's an unrelated aspect of ghost design I'd like to touch upon go is designed to help write big programs written and maintained by big teams there's this idea about programming in a in the large and somehow C plus plus and Java own that domain I believe that's just a historical accident or perhaps an industry accident or an uh but the widely held belief is that it has something to do with object oriented design agreed thank you Bob Uncle Bob I hate clean code uh I don't buy that at all big software needs uh methodology to be sure uh but not nearly as much as it needs strongly a strong dependency management and clean interface abstraction and superb documentation tools none of which is served by C plus plus although Java does noticeably better yeah uh we don't know yet because not enough software has been written and go but I'm confident go will turn out to be a superb language for programming in the large time will tell we have huge programs at Netflix that are written in go they're very successful they're very fast moving and we get a lot of stuff done uh now to come back to the surprising question that opened my talk why does go a language designed from the ground up to do what C plus is used for not attract more C plus programmers this is what I want to hear jokes aside I think it's because go and C plus plus are profoundly different philosophically uh C plus plus is about having uh it all there at your fingertips I found this quote on C plus plus 11 frequently asked questions uh the range of abstractions that c plus can express elegantly flexibly and add zero cost compared to handcrafted specialized code has greatly increased that way of thinking just isn't the way go operates zero cost isn't a goal at least not zero CPU cost goes claim is that minimizing programming effort is more important consideration long as you're like 98 I feel like that's fine right uh go isn't all-encompassing you don't get everything built in you don't have precise control of every Nuance of execution for instance you don't have a ray ray a resource acquisition is in the initialization uh instead you get garbage collector uh you don't get a memory freeing function by the way they actually are going back on this potentially in one 1.20 did you see that the whole Arena allocations I think that that is a beautiful like not middle it's not even a middle ground it's like just one step from a collector saying hey you're still collecting but I'm gonna give you a handle that all the things go under so you can collect all at once that is so good I really hope that they continue down this uh what you're given is a set of powerful but easy to understand easy to use building blocks from which you can assemble compose a solution to your problem it might not end up quite as fast or as sophisticated or as ideologically motivated as the solution you'd write in some of those other languages but it's all most certainly uh be certainly be easier to write easier to read easier to understand and easier to maintain and maybe safer to put it another way oversimplifying of course Python and Ruby programmers come to go because they don't have to surrender much expressiveness but gain performance and get to play with concurrency yes yes C plus pro uh C plus plus programmers don't come to go because they have fought hard to gain uh Exquisite control of their program domain and a programming domain and I don't and don't want to surrender it uh surrender any of it yep that's what I thought to them software isn't just about getting the job done it's about doing it a certain way bold claim but I think I could buy it the issue then is that go success would contradict their world view and we should have realized that from the beginning people are excited about C plus 11's new features are not going to care about a language that has so much less even if in the end it offers so much more thank you this was an incredible talk I cannot believe in a Talk 11 years ago can still be so dang relevant today you know it's one of the things um it's one of these things that I've been I've been kind of harping on a little bit about typescript is that it's such an expressive type system I find that you will crew technical debt really fast and it's it's and it's a hard technical debt it's so expressive and so incredible that I have never had more problems with technical debt than I've had with typescript just saying uh maybe people don't like that maybe people hate that one but I I just I'm I've just always had this problem where I think that there's this idea of just enough typescript you know what I mean typescript is too much for me it's why I stick with go you need uh you need a million well yeah I mean that's just that's that's not really I mean that's just an ecosystem that's an ecosystem right even if node came with a singular tool that did everything compilation build everything it's all in a single step I would still think typescript is too expressive even if there was no problem with building ever I would still feel the same way yeah I think oh Campbell's biggest problem is ocamel is functional functional is 100 harder to read for the average person and I and I think that's probably just a starting point problem but I also think it might just be a procedural problem procedural is really easy to understand it's it's just really easy to understand so I think it's such a natural way people can express programming and I think that's why it's such an easy way to start but to be able to solve things recursively requires you to see things in a very vastly different way almost counterintuitive a lot like Vim like Vim is counter-intuitive but in the end it's better I think so can I believe that in the end functional is better yes I can do I believe it is it is just a no-go for starters I think it is a no-go right I think it is a no-go for starters sorry shirai I think that it's a very very hard thing to just start recursively recursive is one of the hardest ways to start thinking probably when are you gonna roast reason to ml instead when you're gonna try reason MSL I do want to try it I do want to try it I'm I'm dude I'm D to C okay I'm D to C the name is the prime again
Info
Channel: ThePrimeTime
Views: 131,088
Rating: undefined out of 5
Keywords: programming, computer, software, software engineer, software engineering, program, development, developing, developer, developers, web design, web developer, web development, programmer humor, humor, memes, software memes, engineer, engineering, Regex, regexs, regexes, netflix, vscode, vscode engineer, vscode plugins, Lenovo, customer service
Id: 4EMcm9vzlnI
Channel Id: undefined
Length: 28min 15sec (1695 seconds)
Published: Mon Jul 24 2023
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.