The Robustness of Go • Francesc Campoy • GOTO 2018

[Music] so before we start I wanted to just general shout out to Ashley McNamara who is in the doctor hospital and I'm wearing a super nice t-shirt she designed so if she sees the video hi Ashley cool let's continue I don't have enough time for anything else so today I'm gonna be talking about the robustness of code I propose this stock thinking that go was robust and then I started thinking more about it and I'm going to be talking about how actually maybe not that much and then as soon as I started thinking was like well if Co is not robust what is robust and I tweeted about it and people were like see and I was like no for real people actually think that C is robust which C is amazing but it's also super fragile and it's super easy to break things so people then were like oh you should check out our line so we're gonna be talking about those two languages and runtimes and environments talking about robustness so we're gonna be talking about first what does it mean to be robust what are the robust features of the features that make go something at prom language that I consider to be quite robust what are the ones that actually kind of break that robustness which is sad but they exist then we'll give up on trying to make robust programs because who cares anyway and then well actually Erlang is robust so we'll talk about how is it that it is robust I go to is a great place to talk about it because you know Erlang was created by Joe Armstrong that's walking around there and then we'll talk about a new hope not the movie so if you want the slides there online you can follow up you can use this beautiful QR code I should have thought about actually using a link for those that read letters but it's on speaker deck under my username campoy so you can find it there and real quick about me I'm Francis Campo I worked that sourced even though I used to work at Google for quite a while I was a developer advocate at Google platform doing go and machine learning and also as someone said Joseph funk is a go YouTube channel that I post every two weeks except when my Mike Briggs which is like last time so I didn't post the video but it will come one day about CORBA because I hate my life okay so what does it mean to be robust and this is kind of an interesting question because when you think about robustness there's many many things that you could think about like one of them is like something very very strong and very hard to break right but something very strong are very hard to break could also break for some some of the reasons right so when I think about robustness in the context of machine learning of computer science what I'm thinking about is not about really how it is when things go well but how it works when think things go wrong it is the reliability how easy it is to break something intentionally or unintentionally right if I'm running a program how easy it is for me to write something that eventually will break by itself or how is it is for me to write a program that when things are run that go wrong the connection I the network connection fails or a disk fails or whatever my program still runs or fails graciously whatever that means in that situation and what is the opposite of robustness the opposite of robust this is fragility and it's when when things go wrong they go even worse right the typical example it's this and if you've ever seen this kind of errors an error happened while displaying this error Thanks what are you going to do about this right like it is not about making something that works all of the time it is about working about creating something that works most of the time and when things go wrong it handles those as well as possible which is better than this so let's talk a little bit about go itself the first thing is if you if you go to Y go exists you will see that it was created by a group of three engineers Robert Whismur Rob Pike and Ken Thompson while they were waiting for C++ to compile which is kind of a joke but kind of true at the same time and one of the things that they were annoyed with C++ was not necessarily how long it is to compile but actually the fact that there's many things that are very fragile and one of them is the way you handle memory it is very easy to write programs that are wrong right actually there's a very good talk about B the prom language which they talk about how hard it is to write out and actually robust HelloWorld in C++ it's amazing it's actually really hard like go and rust try to solve the same problem with different approaches go what it says it's like oh I'm going to basically protect everything around yourself everything is gonna be like very very very soft and no heart no sharp edges so that way you will not hurt yourself rust is actually I'm gonna make it a little bit more complicated so the language the type the type system of the language will avoid these issues right so there different approaches to solve the same problem memory safety go has pointers but there's no pointer arithmetic but does this mean well pointers are useful because if you have one object that is 1 mega buddy in memory you don't want to copy that object over all the time right so maybe what you want to do is actually say you know I'm going to pass the address to that that is a pointer sure what is that address plus 4 who knows right so that is the thing that is not allowed and go memory pointer arithmetic is it just simply doesn't exist unless you use the package and save which is called unsafe for a very good reason so you should not use it in general there's also something really cool which is escape analysis and the scapin Alison go is very interesting especially for those that come from C and C++ it solves a very specific problem that most beginners in C and C++ will make that mistake and people are now beginners they will eventually also do it so I'm gonna show that in a minute also there's garbage collection which means there's no dangling pointers the dangling pointer being a under that you still hold that pointer but what it's pointing to doesn't exist anymore or is not something that you should be playing with and automatic bond checks which is very important to all of these means that it is basically impossible to write a programming code that will corrupt the memory which is amazing the only two ways to corrupt memory ingo is using unsafe using c go which c go is not go so doesn't count and the third one is to have a bug in the compiler right which is act on the runtime which is kind of cool because it means that once that bug has been fixed the problem has been removed from all of the problem screening go right so basically solving classes of problems at a time rather than solving a per problem so what does that mean that scape analysis well it means that when you call new and you allocate something it doesn't mean that this is allocated in the hip you may be allocating the stack right in here for instance what we're doing is well you're calling Neil sure but then you're who this is wrong and I cannot edit why cannot add edit okay I cannot edit so I'm gonna ask you to imagine that that is actually returning star V so it's returning the value of what its pointer right on the pointer right which means that the pointer itself the eye area memory does not escape is not accessible from our other program therefore that value can be axed can be stored in there on the stack which means that the problem will be faster this is good for performance on the other side if you're allocating a viable int 42 that looks like something you're located on the stack right because you're not doing new but then if you're returning the others to that that would be wrong if you do this same thing in in C that will be wrong because the pointer to V will be an address that you should not be accessing after the function value has finished so that is a problem and go what it will do is it will actually recognize that and just simply allocate it in the stack automatically you do not care about the you know think about it which is something very nice of someone coming from sitios class and finally the bound checks which are important for correctness if you're doing this so you do a slice of 256 bytes integers and then you access the position 512 who knows what that is so this will actually panic it will say no no no this is not correct right this means that you are doing extra checks all the time which cannot brings performance a little bit down but actually correctness is way more important performance and in some cases the compiler will be able to deduct that those checks are knowing not necessary and they will be removed after memory safety let's talk about type safety so type safety we have static typing so as many other languages basically once you give a type to a variable you cannot just change it if a variable is an integer you cannot put a string in there that that just doesn't work similarly we don't have implicit type conversion for in for numeric types so if you have a float and an integer and you try to add them that will not compile but also if you have an in 32 and in 64 and you try to add them that will not compile if you want to add them you need to say explicitly I'm trying to I'm going to convert this value to that other type in order to have two types that are compatible this is important because that otherwise we would have type coercion type coercion is what javascript has right where like the what videos they're basically all about type coercion where you have a string plus an integer any word and a string man is an integer that's something completely different which is always confusing so go just doesn't allow that right more things are about interfaces we do have interfaces but they they work in play there the satisfaction is done implicitly something like Python basically where impact on the duck typing will say that if you have all of the methods that the algorithm requires then you're good right but that is checked at run in gold that is checked a compilation time we will say for instance f println expects the rider so there's a method right if you pass something that doesn't have the method at computation time it will say it you can deduce the type int as an rider in argument f println it does not implement writer because it's missing the write method which is very nice this is one of my favorite errors in go it's super easy to understanding clear similarly you can do something like in C the void star or the crazy pointer has anyone used void star okay void star basically what you're saying is yellow of types it's who knows what's there once you say it's void star you forgot everything about it right in go we have the empty interface which is kind of similar because you can put anything in in an empty interface but we're keeping the type we keep in the type information so afterwards if you try to say V which was 42 that integer I'm gonna use it now as an empty interface so I forgot what it was and then I'm gonna say and now I'm gonna use it as a string that will not work and that will not work and it will be a check at run time no compilation time because that'd be basically impossible to do but I run them will say no you can't just not do this if you down C++ and give done things like I even forgot the name the brain interprets cast those kind of things were basically you saying just let me know I know what I'm doing let me do it I know what I'm doing you can do also let it go and save package again one more thing that even if it looks weird it actually helps with with detecting errors early is the fact that Ingo if you never read a variable a local variable you will know compile and it's interesting cuz this is an error in this error it's something that lots of beginners and go write very often what you're getting when you're looping over s which is a slice and which is actually an image it's a matrix so you're looping over that and you're getting a copy of the rows and then you're copying you're getting a copy of the cell then you are sending something to that cell turns out that that is a copy that isn't a reference so when you try to write something there you're actually no modifying anything so you're declaring a variable never reading from it that's suspicious that doesn't compile this error is the kind of thing that if it wasn't like this it'd be super hard to see because when I'm reading this code this looks super nice I don't see any problem with this the compiler will tell you then the famous thing in gold there's no exceptions instead we use errors and if you bring any go you know if error is not nil then something right so we do those checks all of the time they're part of how we write good code and this is something that I could give a whole talk about it right but there's actually a really whole talk about it which is very good by Dave Jenny call handle errors gracefully which is a really good talk explain how to how we do errors and go the important thing for robustness is what happens when you have exceptions and exceptions are been at Google for C++ therefore it cannot make sense that when they create new language they also banned exceptions but directly by not adding them to the programming language if you see this code where you're saying oh I'm going to provide this function where whatever you can going to do I'm going to do it inside of a mutex right mutual exclusion only one function at a time could be called no matter from how many places you're running this what happens if F throws an exception well the mythix will never be unlocked the program will block forever and the system is down right that is a serious problem so that's why in go there's no exceptions and if you know go you'll be like but we'll get there later so what about channels why are these part of robustness writing correct concurrency concurrent programs is really hard really really hard and I'd say that actually the way go works and the concurrency features that it provides allows Gophers to write better code that is easily correct so in very quick the way it works is we have goroutines which are the cute golfers the cute golfers communicate with each other using channels which are basic like Linux pipes but they're typed and concurrently safe to use and then there's one more thing which is select for when you want to do multiple things over channels those are the three concepts you need to know about concurrency and with this you have everything right so these actually really go okay so we've talked about all of the things that are good let's talk about things are not that good just want to make sure I'm on time okay yeah cool cool so let's talk about the things that are that make go fragile mutable state mutable state that is shared that is very very wrong if you ask any functional programmer they will tell you that mutable shared state is the worst single thing you could have in a foreign language so what happens here what we have is we have a function ticker that every second is printing the value of a counter and then we have a web endpoint for a web server that every single time it's hit it just adds something to the counter so when you run this it works but this is wrong right why is this wrong does anyone know you know yeah so there's two things this every single request will be handled by a different girl routine so you can have two different go requests adding one at the same time and only one of those will actually work even worse the behavior might be undefined because all of a sudden you get a data race at the same time you could be writing at the same time that the picker is reading which is also different kind of data race but when you run it you don't see this when you see this well actually when you have enough high load and all of a sudden you start missing counters and good luck figuring that out right luckily we have that race which is the data race detector which is super nice and when you when you run the same program with the race detector enable which you only need to add - race super simple you will get warning data race and it will tell you exactly where it was reading where it was writing or if to go routines were running at the same time word were those lines what were the ID of the girl routines all of these things in order to be able to figure out what's going on quite easily now the problem is that the data race is not free it's it makes your friend go slower so in my personal opinion you should run your test with data race enable every single time I don't care if it's slow make faster tests I don't care it should be data reasonable because it's really important and maybe in production when you're deploying a cannery you could actually also deploy with their Airways enable see if it's working and once it's working then redeploy with the data is enable and send production traffic right that way every single warning data race that's an issue that's something you need to fix before you deploy to production neo pointers I gave the whole talk about neo pointers nail pointers are the 1 million dollar mistake or 1 billion dollar mistakes I don't even remember this very expensive mistake right the I forgot the name of the person that invented pointers now but he said actually yeah see her he he bent the pointers and he said it was the worst mistake he's ever done and then the gold creators come and they're like you know what let's not have nail pointers but also neo slices me channels new maps and malfunction all these are gonna be Neil so yeh everything is gonna tell I gave a whole talk go freak on in 2016 about this and I invite you to watch it the whole idea of this talk is yes Neil pointers have bad sites but actually they're very useful and go if you have a pointer to a type calling a function in it doesn't necessary fail which means that Neil values are actually useful and go especially for slices and not functions but slices and channels and receivers and all this Neil values are totally fine for some others like Neil Maps they're actually the way they are they're not great but they're there and lack of generics yes go does not have generics which is good in some sites in some ways because it makes the primary language easier to understand and simpler to learn and all of these things which is great but when you don't have generics there are many things that are hard to implement one of them is bonnets one very nice way to handle errors is by using Monat the error monitor or the maybe monad are great for this and I gave a talk at door go in 2015 long time ago so in 2015 I gave a talk about what did we try to do monads and go so I tried and it works but it's so painful that it's not worth it it is a really bad idea but the whole point is that the API you end up having is actually quite nice so I'd say that if go had generics they're handy we do would be nicer and easier to to manage there be old downsides problem will be the primal language be harder to understand but I don't know where I don't know what we should do I'm not saying we should have generics I'm just saying there's good things about them I also said go doesn't have exceptions instead eheh it has panics sure what are what is the difference not much they're actually basically same thing panics are the same thing as exceptions they're just not called exceptions because panic it's more about this is when you're really panicking literally there's nothing else you could do right so for instance I don't know you try to allocate memory turns that there's no more memory what are you going to do you can return now and that will fail later or you could just fail now there's no point there's no point in trying to continue right so that the point where you panic I like to say that panics are used exceptionally I like exceptions exceptions are a thing that you see all the time right panics are really really and the way you recover from them is by using recovery function the recovery function what it will do is will we be called always inside of the first function which means that that will be called at the N of main and the function were you defining it no matter what right so even if there's a panic deferred functions will be called in there you can go recover and that will check if we got there because of a panic and then it would give you that value so that's how you can handle this errors which is pre next because then it means that yeah we have panics but we can recover from them so you know we can still keep our program running which is what we want so another HTTP server this HTTP server is simply whenever you call when it receives an HTTP request it panics saying boo what happens well the HTTP package actually recovers from that mistake and it will print a message saying hey there was a panic but don't worry we'll keep going we're fine and it just continues going the HTTP server will not go down nice now you do this go panic boom now panic happens in a different go routine so the call stack that we're going up does not include the HTTP package which means they it does not include a recover which means that the panic will not be caught which means that everything will crash the whole HTTP server will crash right so no matter how safely you read your code anyone can write go panic and take your server down so go is not robust which is sad but at the same time if you think about it no matter how robust your brahmin language is if your computer catches fire who cares and by catching fire on ned silly say catch fire but i'm plugging the computer the network goes down whatever could happen to the country or even for some reason the CPU stops working like these things happen right it had if they don't happen really often until you have billions of computers and then it happens every second so these are things that you cannot really do it so so there's no point in trying to do robustness so we should just give up and go so thank you now just kidding now that this is an important point right because no matter how good your primary language is it will not be robust there's no way you can do that but Erlang is robust Joe answering gave a talk about how you can make incredibly robust programs that run forever self-healed they're amazing miracles of computer science and not only that but they achieve nine nines of availability which is by the way totally false you can search it and find that this not correct but still even if it's not nine nines and it's only five nines that's still amazing right so Erlang gets it right so how do they do it well these I spend a lot of time doing this photoshop of Joe Armstrong because I really his position on this image I did actually a or chimp I actually know how to pronounce it anyway there's a really good talk that he gave it's called system the run forever self hill and scale and I definitely recommend everyone to go watch it because it's one of my favorite talks it's an info cube and in those he talks about six rules that make there are necessary for prom language or a system in general to be robust the first one is isolation right which means that if something fails it's fine that component will fail but the rest should still be okay right so in go if you have a guru tinder panics and that panic is not cut the whole system goes down so go that's not provide isolation so boo concurrency Erlang provides concurrency they have processing which are actually very very similar to threats to sorry to threat to go routines super cheap and you can run thousands millions of diamond in a single in a single machine this is very nice the system of concurrency is a little bit different and go we have channels airline has pro actors is that if there's a really good interview which I forgot to add but there's a very good interview at two with Joe and Joe Armstrong and the creator of the actor Proctor model talking about how the actor model is better than communicating sequential processes which is the one with channels because you can implement channels with actors and not the other way around so it's pretty powerful that they're really similar so I'd say go concurrency pretty good failure detection so when something goes wrong we notice it right in Erlang do you have things like monitors so basically when a process fails you can get a notification from somewhere else saying hey that that fell right and then you can you can ignore it or you can do something about it in go well we detect it because the hope the whole program fails right so it's easy to detect but there's no much more than that they'll have fault identification and faulty different indentification is also quite interesting because it is not about knowing that something fell is about knowing why it fell and this is quite interesting because in so in go you could parse the panic like maybe I do not recommend trying to do that at all like please done in Erlang when you pan when you when a process fails you can actually say hey I'm failing this is the reason why which could be something from a stack trace to a string or any other value Joe Armstrong and T star talks about you could send a whole database which I do not recommend either but you do you and then you can act on it right go doesn't really that the let life got upgrade this is something that I have never used with Erlang but it's basically of being able to deploy a new chunk of a program while it's running and not take it down and just refresh them update the code it just keep running which really reminds me of this picture because it's it sounds really dangerous but it actually works really well go does not do this I don't like don't even think about having this ever I do not think that anyone wants using go so you cannot do this what's the point of this well if you need to stop the program to upgrade it it means that in between that part where you stop it and you start again you might miss requests so you have a little downtime in there right so that's why the live code upgrade is important and finally he also talked stable storage and I would like to talk to him about this because I'm actually not that sure about what he means stable storage is a storage that allows you to basically do transactions so when you do something on it either it works completely or either or it fails completely but there's no like me meat stays right so for instance if you have sequel database when you do a transaction you have that if you have other databases you might have the same but for instance if you have wearing two if you're running to a hard disk unless it's a transactional file system very often if the program fails you may end up with corrected corrupted files right that is not stable so stable storage is important to have a distributed system that is robust in all of these these six rules allows you to then say let it crash which is something that Erlang proposes saying if something's wrong just crash thank you if something is wrong just crash don't worry about it someone else will fix the mess right this is only you can do it once you've you've actually figure out the six rules before gold doesn't do it therefore let it crash forgo is a bad strategy so who wins Erlang versus go okay or a nine versus go good I said at the end filler detection yes because keine life got upgrade therefore not in stable storage I mean her like a stable storage because they use in Asia which is a database in go you can also use that database so for right why not like that's fine in my book that means that we have stable storage for got you and this my best slide look at this work come on now there was a beautiful animation in there wait a second there you go thank you I spent a lot of time doing this so why is the new hope the new hope is kubernetes why well because with kubernetes you actually are able to satisfy the rest of the rules that go doesn't bring by itself kubernetes so installation that's kubernetes provided solution yes lots of it like everywhere first of all it runs on containers so if a container goes down it doesn't bother anyone else there's namespaces so you can even isolate those containers from interacting with each other you have multiple nodes so if a machine goes down nobody cares because there's other machines and not only that but you have multiple clusters so if a whole country loses electricity well there's another country where you have another data data center you find right so installation perfect amazing concurrency well we already had it with go basically the only thing we're getting is you have more parallelism you'll be able to run more replicas around different machines and stuff like that but doesn't really add more from that point of view failure detection these actually where kubernetes is amazing because it will monitor your your containers for free right so you will actually be checking all the time are you okay are you okay are you okay you're not okay by new one right that is what you want if something fails it will just be restarted automatically which is what airline also does also restart policies allow you to even detect those things and do things accordingly when something fails it doesn't need that it should be restarted automatically maybe you want to do something else you can also do those things fault identification you luck stuff so you can go read the logs no don't do that I mean Locke stuff for sure but do not read the log so the tech but happen like with a machine that's really bad either yeah I consider but there's definition log which I had no idea it existed but when a container goes down you can write to that file and that will be part of your container specification of your pot actually so if a pot goes down you can right there and then ask hey that pot fell what happened and you will get the message so you get exactly same idea as in Erlang you have that concept of being able to leave a message I'm about to die but this is why right live code upgrade sure we have liners Pro liveness pros and radius probes and the life running updates what is this we have rolling updates which means that you can yes I got it you can migrate from v1 to v2 or be 11.2 v1 dot you by saying hey I had three parts in version one and I want to end up having three parts on version true please figure out what Q&A is going to do is start a new pod for version two and once it's not only live but ready imagine that you have a system that takes one minute to start it's running but still not ready to answer requests that is the difference between lightness and readiness so once it's ready it will take down one of the version one then start new one wait for readiness stop one and continue like this this means that if for any reason something is wrong the deployment will stop so you will not have any problem of downtime because a new version is broken unless your readiness probe is also broken and then you're out of luck and finally stable storage sure we already had it before so why not but also kubernetes comes with that CD which is a very good example of stable storage you can also use sequel databases or any other that is that you want so in conclusion so airline and go if you compare them or like clearly wins but Erlang is not robust beam yes and if you convert to that and you compare err lying on top of beam versus go on top of kubernetes you will see that one I don't know how to do animations but second that is actually exactly as robust as beam so kubernetes is not something revolutionary for those that were already using beam if you're using airline or using a mixer that's amazing you're already using a system that has been incredibly robust for many many years but for those running different program foreign languages so just go but you could also be writing any other language literally you could be writing in Java you could be writing in JavaScript kubernetes will provide that extra layer that allows your programs to be more robust I like to end up thanking two women that helped me write this talk Veronica and Miriam Veronica is really good a little sir Miriam is really good at her line and they made my talk much better so thank you to them and I'm done so thank you very much and we have some time for questions [Applause] all right yeah thanks Francesca oh and yeah if anyone has the app feel free to submit questions through the the go to Chicago app or raise your hand if you have something to ask I have one to kick it off just cuz I don't know the NGO ecosystem well off the top of your head what do you thinks the most robust commonly used go program or even just that you've seen like you know can you get to five 9s with a really good go program so I'd say that probably kubernetes the fact that he's bringing go abscess I'd go with a bust somebody's not about the fun that he's bringing go it could be raining in any other language and still be as robust because it's the architecture that counts right kubernetes is a rewrite an open-source version of an internal version on the internal system in at Google called board that is bringing C++ right so it's not about robustness of the language itself it's about the architecture that you write cool um we got a question on the app asking about sort of dependency management and versioning and go sort of comparison to like nodejs or maven or something like that and asks why didn't go sort of embrace the sort of no I think no I think things are going in a different direction now why didn't go should make the choice that a lot of other languages that came out in the early 2000s to have so version dependencies and distributed source control and everything so I guess the most important thing to know is that we have not really decided yet we've been playing we so go to very long time to have a version management system because it comes from Google where we have one repo so we don't have versions that's pretty easy right now not everybody should do that it's a not very good idea if you have multiple teams and don't have many engineers to maintain your repo so we started doing it by vending because it's the simplest way where you have all the power to do whatever you want basically you copy that piece of code that you depend on you put it inside of your repository and then you want to upgrade well you go you get a new version and you put there the problem is that upgrading that can be painful so that's why we we create tools around that DEP is the tool that I still use personally that allows you to manage this in a very simple way basically you're able to say hey find all the dependencies that I have once you bring your program it will store them and then when you want to upgrade to something near you just added one file saying actually I want to add to go to the next version and it will do it by yourself there's a new thing called Vigo which is what everybody is supposed to be trying out now I have not tried that yet and it's similar idea but the most the most important difference is that no js' and MPM and all these package managers very often what they do is they are you to have lots of power on what version you want to run but the default is the latest version which is dangerous so in Vigo what we do is the other way around so you'd say if you say 2.10 but to the one dot nothing we're going to try to use zero as long as it's available and if you want to upgrade to something higher then say it because otherwise what happens if a new version comes you're just deploying and without even noticing you're deploying new code right so Vigo and there the main difference is that is Vigo is much more conservative for people who don't know the ecosystem well would you say there's a talk or a blog post somewhere on like hey these are the best practices this is how you should actually use like no dapper Vigo so for that I'd say I made the documentation of that is amazing but also there was a really good talk by the creator of the app which I forgot his name he's gonna kill me Sam Boyer he gave a keynote gopher con last year about that explaining how it happened and the decision taken during the process and stuff like that very good talk for Vigo there's a true blog post brand by Russ Cox from the go team that explained this very cool any other questions from the audience I've got one so let's let's imagine that go-to comes out and it has Erlang style like hot code swapping yeah you could magically swap out function implementations on a live go routine or something yeah would you use that idea yes and yes yes it is a terrible in the I'd say but yes I would definitely use it because I love so I'm sure you also a sonic PI so I'm a PI based on the idea that you can actually refresh a function and keep running in God that's impossible simply impossible right now I'd love to be able to do that because this static an compiled yes and we have plugins but those plugins are loaded dynamically but only once so then I bro that thing that is disgusting so please I have not even going to say what it is but basically what it says is whenever you try to load on your file it will say I'm going to compile it and load it and I'm going to going to give you a random name so that way you have a new thing the problem is that of course there's no garbage collection for that so after a couple of minutes your program crashes but that's ok yeah a lot of people really praise goes like small static binary outputs for things like building like scratch docker files that is cool stuff like that yeah do you feel like that's the future do you feel like a slightly more dynamic like hot loading thing has benefits like real benefits for like sort of future so systems I've seen a system that got me really excited which is so go and its run time have a pretty clear API right and what someone was proposing was saying well why don't we use this API and the runtime brethren see they say it's a Windows runtime or a Linux run time or whatever it's a distributed runtime right so that's in program whenever you're running a new girl routine Danny girl routine might be running in a different machine which we wouldn't make go be more like Erlang / beam that is super interesting but it's a research problem right now so if that happened I think be really interesting because then it would allow go to be as robust as go Plus kubernetes without needing kubernetes and I think that the runtime below go could actually be kubernetes which is kind of ADA but it could work and I think that's super interesting that's something that I would like to see one day so like kubernetes would basically become a go routine scheduler and nowhere yeah yeah and it knows everything so if you have channels between two routines because they're going to communicate so you should be running the same machine if possible and things like this what's the name of that project it's actually something that I heard internally at Google but it was open source and I know I can talk about it because I don't work at Google know but also because it was a public blog post but I don't remember the name cool well thank you so much Francesco good you

Channel: GOTO Conferences

Views: 31,667

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, GOTOchgo, GOTO Chicago, Francesc Campoy, source{d}, GO, Go Programming Language, Erlang, Robustness, Robust Programming

Id: 40d26ZGfhR8

Length: 44min 31sec (2671 seconds)

Published: Wed Aug 08 2018

Reddit Comments

[u/rsc]

I watched this because it was Francesc, but I was a little disappointed that it's not really about Go. Posting a summary so others can make a more informed decision about whether to watch.

[My take on the background state of the world]

Based on experience with Erlang, Joe Armstrong suggests there are six requirements for building robust long-lived systems:

1. Fault isolation, so that a problem in one part of the program doesn't take down the whole thing.
2. Concurrency, because that provides the unit of isolation.
3. Failure detection, so that you know when a fault has occurred.
4. Fault identification, so that some other part of the program observing the fault can take appropriate action.
5. Live code upgrade, because that's how you deploy fixes to the faults.
6. Stable storage, because you need your data to outlive the faults and the upgraded code.

Erlang is almost unique among programming languages in that it has all of these built into the core language / runtime. (Reusing this infrastructure is one reason Elixir is so powerful.)

Typically these features are built into an execution system separate from the programming language. For example, PHP scripts running on LAMP stacks are not robust because PHP is doing anything interesting. They are robust because Apache is running each request in its own separate PHP (at least logically), providing isolation and concurrency; because you've got integrated, always-on logging, providing failure detection and fault identification; because Apache takes care of letting you do live PHP code upgrades, without taking down the server; and because MySQL is providing stable storage that outlasts any particular PHP script execution and hopefully is mostly immune to faults in the PHP.

Like nearly every non-Erlang, Go leaves these features to the surrounding environment. You could at least imagine running LAMG stacks where Go binaries or perhaps on-demand-compiled Go programs substitute for the PHP scripts, and that would be one way to get the robustness. But Go is not doing any more than PHP in that case, not really. And while LAMG is not an acronym I see often, certainly many people do run Go programs with, say, nginx as a load balancer / fault isolator / concurrency generator and a hosted SQL database as stable storage.

[Summary of talk]

Francesc spends a bit of time talking about ways Go is more robust than C/C++, like not having dangling pointer errors, and then talks about how Erlang satisfies the Armstrong requirements while Go mostly does not (no fault isolation, little failure detection and fault identification, no live code upgrade, no stable storage although Francesc gives Go credit for SQL bindings). Having demonstrated that Go by itself is not robust at all, then at the very end of the talk he suggests that Kubernetes would be a way for Go programmers to achieve robustness as defined by Joe Armstrong. Absolutely true, although just about any other popular execution environment seems like it would work too.

[u/playa_1]

Great talk! Too bad the Q&A got hijacked by dependency management questions. A bit off topic for robustness.