Erlang Programming Language - Computerphile

I'll give you a quick introduction to Erlang a programming language which was developed by the Computer Science Laboratory in the late 80s and then released as open source in the late 90s actually this is oh it's the Erlang give comment let it crash you know so so crashes are good with their long run yes because what you do is you sold the problem that way most programming languages the history is completely irrelevant but in the case of airline you know the team who invented it we're actually out to solve a problem they were out invent a programming language and whatever instead task to do was figure out how do we build the next generation of telecom switches you know back then near the telecom switches with only systems which were massively scalable so this was before the internet they had to be reliable they could never fail there were incredibly complex this was happening at the same time as the hotel car industry being in a state of transitions they were going from single service networks where you had a phone network only thing you could do is fall you had internet you know and the only thing you could do was basically your connect to the internet or mobile networks no anything you could do is call other mobile phones and what was happening was that they were all merged the systems were all slowly being merged into a kind of multi service network developing these systems you know with the deregulation of the telecom markets time to market became critical so you know the large telcos didn't have all the time they wanted to develop the systems as they had in the previous decades if you know now all of a sudden whose competitions in the market so if a provider telco provider couldn't couldn't you provide a particular system they go to the competitors and and the same applied you know two to two users if you weren't happy with bt in the 80s you were stuck with bt in the 90s you could change when they're trying to solve the problem of developing next generation of switches what they did is they took all of the existing that or many of the existing languages at the time and you know the prototype telecom at vacations and after few years came to the conclusion that no all of these languages had a lot of desirable features but there was no one language which had them all and that's when they decided to start inventing a programming language and you know spent another you know three four years prototyping what eventually became Erlang one of the main features which increased programmer productivity were the declarative was the declarative aspects of a language declarative programming gives you a much higher level of abstraction and it gives you smaller concise programs which are easier to read but also most importantly to maintain let's not forget yet they will look at how to reduce the maintainability costs of of their systems and yeah actually studies later on discovered that you're comparing say Erlang to C++ or Java academic studies showed that airline consisted of 4 to 20 times less code than their counterparts in imperative and object-oriented programming languages and these are your similar numbers near which you'll see in Haskell and others and it is an it is an attribute of functional programming so just to give you a quick example a little taste over what an airline program it looked like let's just do factorial of 3 we'll write a little program so factorial of zero returns 1 factorial of n when n is greater than or equal to 1 returns n times factorial of M minus 1 so n here is a variable it's an upper case and what we do is we use something called pattern matching to understand which of these two function clauses we execute it so if we call factorial 3 we try to pattern match 3 to the 0 it fails so we go on to the next clause and n is a number variable so gets bound to 3 3 is greater than or equal to 1 so we call 3 times factorial of n minus 1 so it's free times factorial of 2 2 will fail patter magic appear we'll pass a match here and it's now gets rebound 2 to 2 is greater than equal to 1 so we call 2 times factorial of 1 and it won't had a match up here it will pattern match here so we end up calling 1 times factorial of zero 0 now we'll Pat a match in the first clause which is our base case we return a 1 and at this point we do 1 x 1 x 2 x 3 and return 6 note a few things here the variables inner length or single assignment that means that once you've bound them to a value you cannot change them so they're immutable this shouldn't actually be called variables because you can't you can't change it but whenever you call them in you recall the function it's considered fresh you know whenever you re enter the function clause and also there's another property in here which is that of defensive programming defensive programming is not encouraged so if we call factorial of negative 1 for example it will fail pattern matching up here because negative 1 is not equal to 0 we will be bound to end here but negative 1 is not greater than or equal to 1 so this Clause will also fail at this point there are no more clauses but one of the function clauses has to always succeed if it doesn't the actual process executing this particular code terminates and it terminates because of a bug I mean you shouldn't be calling factorial with a negative 1 so by not encouraging defensive programming and instead letting the process executing the code crash if your state gets corrupted results in very compact and concise programs which are very easy to rain you program for the positive case and we'll see later how we handle these errors we don't ignore them we just have them slightly differently than what you might be used to so now we've looked now at the declarative aspects but your actual program your main building blocks when working with variant programs is concurrency their processes and you know process is an airline don't share memory so they're based on immutable state and your there's action another video where we look at you know concurrency models with a mutable state and mutable state as well now processes are lightweight processes so they're detached from the underlying operating system back in the days when we could have a maximum of 16 or 32 August Fred's the virtual machine could actually handle near hundreds or even thousands of processes running and running concurrently and that's near that that was a very wise decision to detach the concurrency model from the underlying operating system as it allows you to design for scale irrespective of the target architecture so that means airlines handling the threads is that right that is correct so divert airline runs in a virtual machine and the virtual machine can be seen as an operating system on top of the operating system so I wouldn't call them Fred's but lightweight processes the virtual machine itself runs on one or more threads you know depending on if you're running on a multi-core architecture so we've got processes in Erlang and your processes are created using spawn building functions so we call spawn where we pass in a module a function and a list of 0 or more arguments and in less than a microsecond in the sub microseconds a new process is created which is running this function in this module with these arguments and you know initially this process takes up very little memory just a few K and so it just changes the way you model your programs because for every concurrent activity in your system you'll actually go in and create a process so imagine an instant messaging server what you would do is for every message coming in coming out every login request every status update sex telling your buddies I'm online or I'm gone offline will actually be a process executing that particular code and you know once it's executed you know the process terminates a virtual machine today can handle you know tens of millions of processes in the VM itself and it makes reasoning about your program very easy because you just need to think in terms of a single message and then the VM itself will allow you to scale you know way beyond that processes yeah do not share memory they with each other through message-passing and so you know when when we spawn a new process the spawn built-in function will return a process identifier which we here bind to the variable pit and this process here now can send a message to this other process so here we're sending an atom hello an atom is just a constant literal it's what you see is what you get so it's used for comparison and it's used for mainly readability and so a copy of this atom gets made and stored into the process mailbox of this other process the key points here is these are lightweight processes they are they don't share memory and they communicate with each other through message passing and your virtual machines are incredibly powerful and can can scale you know to tens of thousands and even millions of processes if need be so I was saying earlier that you try to avoid defensive programming in Erlang and if something goes wrong because of a bug in your program because your state is corrupt you let your process terminate and you know when a process terminates you basically lose that process and you lose that state but all of the other processes around it will continue executing so you imagine a phone switch where each process represents a phone call a bug in your program would cause you to terminate one process which is handling a phone call you drop one phone call but all of the other thousands of phone calls going on and in parallel in your system wouldn't be affected and so it's a form of isolation of isolating versus saying you know you get a bug in a Fred you're a Fred usually will handle many more phone calls you know that Fred terminates all of the phone calls in that Fred will be terminated even if they were not the cause of the of the bug or the corrupt date in the first place so you know this this isolation however needs to be controlled and we do that through something we call supervisors we use supervisors to encourage the whole your program for the correct case paradigm and learning processes crash or terminate when something goes wrong and the whole idea behind supervise it is that of layering so we will have a site top level supervisor which is a process here I'll denote it as a little square and supervisors have a property of being able to monitor other processes and if they terminate catch and exit so you know assume we've got a process here which is monitoring 200 processes one is just a regular process that is a supervisor if one of these processes terminates the supervisor which is trapping exits will receive an exit signal and based on this X is signal it can decide what to do it could either restart the process so assume it's a process storing some data was a phone calls ongoing but it's actually not responsible for that phone call we restart a process so when that data is needed other process can go in and access sou we would just restart it or if it's a process responsible for a phone call it would just terminate that process the phone call would be dropped and it wouldn't restart it and what would then happen is when you know you soak the phone calls dropped you blame it on the network you redial and then a new process with a fresh state will be will be created and hopefully you're nothing's going to go wrong at that point so it's the whole idea of isolating but there will be times when you know the supervisor realizes that just restarting the process won't solve the problem so what they do is it will go in and terminate all of the other processes in its sub tree and then terminate itself sending an exit signal up to its supervisor and the top level supervisor then decides what to do it could be that this process down here is crashing with of corrupt state in here so you know this supervisor might then decide to terminate this process and then restart it then restart the sub level supervisor which you know when new phone calls and come in would get added here and if the top level supervisor realizes that a can solve the problem it will itself terminate taking down the whole supervision tree and the program with it and at that point that's maybe when you go in and you reboot the Machine you reboot or restart the virtual machine you know as the problems might be see the whole error handling mechanism as an onion we're on a smallest level you've got aid your sequential error handling your sequential code you then do it on a process level you'd then do it on a supervision tree level then the next core is on a virtual machine level where you restart the virtual machine and then you've got it on a machine level Aaron Lang is you know the first programming language I'm aware of which actually embedded distribution into the semantics of the language so we've got two processes which are running on a single machine here and process a communicates to process B you know my message passing we'd seen earlier that you know we use the exclamation mark hello to send a message to that process now using the same syntax you know we could have process C running on a separate note and you know we've got the network in between and what process I could do is take the process identify err of C and send it the message hello and this message now will be sent straight to C so being the same syntax by writing a program which runs on a single machine with very little changes or by doing it right from the start you can actually distribute it across a cluster of machines without you know we are having to do any major changes in the business logic of your system as soon as you solve the problem of distribution what you automatically get is the ability to scale on multi-core architectures and because in effect the multi-core multi-core is yeah it has very similar principles to to distribution and you're guessing I assume we've got two cords and we've got five processes running you know we put three he throws it on one core and to first to another they communicate with each other through message passing and it doesn't matter if your discourse are on the same chipset or under learn different chipsets on the same machines or they're actually on separate machines all we need to do is you know used a bang hello to communicate with this process be it on the same core or on different course and the concurrency model earning has is based on no shared memory you're the biggest problem to your scanning on multi-core is memory lock contention you know it's the the feature which slows down the whole scalability on them and so what you do is you pick a programming language with a concurrency model based on no shared memory and that solves a problem for either this is going to be an iterative process and what we want to do is move these things around and permute them so if this is our data path with our columns by sharing bytes around with different columns when we combine it with the mixed column step which we'll do in a minute you'll see that actually we're mixing everything up so within just a couple of rounds everything is very very jumbled up

Channel: Computerphile

Views: 246,252

Keywords: computers, computerphile, computer, science

Id: SOqQVoVai6s

Length: 16min 5sec (965 seconds)

Published: Tue Dec 17 2019