José Valim - Idioms for building distributed fault-tolerant applications with Elixir

thank you in good morning everyone so Alex here April really anguish that runs on top of the elevator machine the goal of this talk is not to you know tell teach you elixir in particular the title of the talk is actually idioms for building fault dollar in distributed applications and that's a big part of what I want to explore sorry exploit the stock exactly if you're going to write systems for rent write software in air link and elixir what are the different words that you need to learn what is the way you need to think about software when you come to this platform and this top is going to be divided in three parts so the first one is a little bit of history background why did why a new programming language okay the second one is the important part when we are talking about the idioms and the new vocabulary that we learn when we move to the second system and the third one is a little bit more specific about Alex here and what Alex in particular brings to the fold so let's get started so to me this journey started about almost 10 years ago so this I was used to program in Ruby and there is a web framework called Reuben rails that was used to be part of the team and about 2008 they released the new version and one of the big things in these new versions that rails is thread safe okay and what was happening there is this a story that we are hearing all the time now that concurrency is becoming more and more important so there was some pressure from the community to be able to get your application put it on a server in production and for that application to be able to use all course and then the rails team decided to work on this feature and today and when I look back at it right treads safe is a very funny word because so why thread safety so in Ruby the way you get concurrency is using threads and safety means that they are going to get your application run it with threads and that's not going to blow up and the reason why thread safety is a very funny word for me today is because like the lowest guarantee you can give me software right that's not going to blow up it's going to be fast yeah is it going to be maintainable right no it's just no I the only guarantee I'm going to give to you is that things they're not going to fail and this is actually trying to be true because later when I joined the project we would have blood reports from well when I actually put a new server in production because I having a spiking load I get some concurrency errors and those would be very very hard to to the bug to reproduce to fix so a couple years later when I was trying to fix those bugs and it was a very frustrating very hard process I thought to myself well which concurrency is becoming more and more important I need to have good tools the tools we have here right now they are clearly not enough and I have to say that today right it's even more important than before like last year Apple announced the Apple watch with two cores your wristwatch has two cores writing code that runs on a single core today is a special case write everything you do in your computer your programming environment should be using all chords so so yeah I started on the journey to see what are the other alternatives other options we had out there and I like to say I had two points of no return two points where when I got there I said ok this changes everything right like I cannot write software it was writing before and the first one is functional programming and we could have long discussions about what is functional programming but to me at the time okay it was two things that called my attention so the first one is explicit state instead of implicit state so by having the object right sometimes you have objects that encapsulate the object and capsulate another object and then we have the state inside and then we would have race conditions that would be really hard to detect because we'd have two cores right chip rats trying to change the same state that is hidden inside an object inside an object is Russian law of objects and then it was really hard to find those cases and then now by making everything explicit the state needs please is no longer hidden away seeing those cases where I could have raised condi Shayne's just became much clearer to me and then this was the first thing I thought well if the software was riding was using this principle everything would be much clearer and I would be and I would find those issues that I'm trying to debug and trying to fix much easier and then the second one is that even if the state is explicit what if we transform things instead of mutating them so Alex here the data structures are immutable if I have a list and I try to delete an element of the list I get a new list I don't mutate the previous one right so you know we could go a lot longer talking about functional programming but those are the two things that caught my attention at the time and that was the first point of the return the second one was when I met Aaron Lane Darryl England times our inverter machine so we have a bunch of functional programming languages I decided to play with them use them and get acquainted with them and there was one that I like to say that I fell in love with which is air lane which is a virtual machine a programming language and a runtime okay and what really caught my attention about Airlines was exactly how it came to be so air named is a as I said programming language runtime that was built by Ericsson which is a telecommunication company and when they were designing it they have a very interesting set of use cases in mind for example one of the things that they wanted to do is to build telephone switches and what a telephone switch needs to do is connect person a to talk to person B but in want a telephone switch to handle as many connections as possible as many people talking at the same time so we start to get this idea of concurrency right you should be able to handle many connections many people talking at the same time another thing that they had that in there since the beginning was exactly the idea of distribution because have telephone switches they're connected telephone switches maybe you want to call someone that is already busy talking to someone else through another telephone switch for another way and then you need to exchange this information and have this kind of routing through the system and and there are bunch of volume testing features we could talk about so I like to talk about hot code swapping which is the ability to upgrade the code that is running live in production without to bring the system down because if you are building a telephone there's always someone on the phone we cannot just say oh we have a new version that just bring all the new switches up and turn off all this which is not you can't do that right the calls are going to drop that's not an option so we need to upgrade the code live and we have a bunch of interesting features that was designed for this use case and handling was used a lot in the telecommunication area until people started to realize that this case here that we have right now it's very similar to the Web today right where you have servers and you're connected to a bunch of devices within browsers or Internet of Things embedded devices mobile phones and you want to be able to handle as many connections at the same time we are talking a lot about having persistent connections that have information coming and going all the time you have into internal endpoints you need to talk to write to have other systems that you wrote and you want to communicate with them so once they started to become clear a lot of companies it started to use Airlink more and more so we have Amazon and Facebook we have teleportation companies they still like Ericsson a Motorola and you know newer companies let's say like which today is not influenced as Heroku so if you ever deploy an application to Heroku every time access or application on Heroku you are passing for a rerouting layer that is written in Erlang right if you ever use the right database that's written in Ireland as well and there is a case that got a lot of attention in the last I think three four years which is what's up so what's that is a messaging application installing your phone and can exchange messages with your friends and you know every every year there is some interesting new coming from whatsapp so for example in the last year or the year before they were handling more messages than the whole global SMS system and it's already knurling and they would go to airline conferences and talk about the architecture and how everything works so this one is a bit old for now from 2012 but they were saying how they got to minim connections on a single node so they have one node in production and they had two million devices connected and this is not a synthetic benchmark you know the devices they were connected we're sending and receiving messages and when you go to run when you look at the machine it's a quite powerful machine at a time it's a mission with 24 cores 90 gigabytes of RAM and even for with that look that load to million clients it was using only 40% of CPU memory later decided they got the same machine to get to three and a half million clients and this is exactly what I wanted I want to be able to write software that is going to run on my machine with four cores of two cores as efficiently as possible but when I put it into production and it has 24 cores wait to fly as well okay alright that was a very quick story of how I decided to create Alex here it was really I like to say 95% of it is exactly because of their analytical machine Alex theory would not exist if there was no where language our machine so if you want to leverage everything that airline has to offer right what those companies were using to build those kind of systems with Erlang we need to learn new idioms we need to rewire how I think we need to learn new words and that's the second part at the top that I want to go into now so when we are when we go to most mainstream programming languages now I have today this is the code that we write we write sequential code right it's just a huge chunk of sequential code that's why triads are so hard right because we need to think how those threads they are going to interleave the same with chunk of sequential code okay and in a lecture and in Erlang it's not much different we have sequential code except that we put it into something very very small that we call a process so if are talking about idioms we just learn a new word processes from now on to the rest of the talk when I say process I do not mean an operating system process I mean a very cheap very lightweight thread of execution did I say in the whatsapp case they had two million connections they had at least two million process at least one process per connection okay so they're very cheap very lightweight we can create a bunch of those and those processes they are isolated one cannot affect each other by default so it means that we can get all of them running at the same time and we're already starting to have an of how we get concurrency we have those isolated processes that are all running at the same time and whenever they need to actually work together or have a common goal or coordinate we do that by sending messages okay so we are learning about your interesting things are now thinking about in terms of processes that are isolated and concurrent and we are now starting to talk about message passing which is what we use our communication communication coordination between processes it's always explicit via messages and that's the macro view but we can actually even zoom a little bit more okay and try to get more information so let's imagine that we want to get four processes here imagine since I was talking about that applications and imagine that all those processes that is running on this particular node on this particular machine this particular instance of the VM they are related to a web application okay so and then if it's a web application we are going to have things are going to have a DB process that is responsible for you know talking to the database so if you need to do a query the DB process is going to actually send that query to the database and give you the results back we are going to have a web process which is something sitting in the TCP level waiting for request and serving those requests we're going to can have any statistics process that is just get information about the system and how the system is running and we can have a mailer process as well okay that's free magic every time the user sign up we want to send an email saying welcome so what is interesting is that if we go back to those most of them in string languages they have today there is something very because we have just that huge chunk of sequential code what can happen is that if there is something wrong while sending an email it could actually bring the whole system down and when you think about it it's really really weird right why something that is sending a mail can bring the thing that is sitting on the TCP socket expecting requests why can it bring it down because we have that huge chunk of sequential code right and the only reason we don't see it happening practice is because we wrap the call right so every time the web server is actually calling your code it wraps it in a try-catch or not begin rescue you say my errors rascally exceptions and for us for our line developers this is a very weird idiom right because exception is a way of the software to say hey something went wrong and I just think oh I think you just continue doing whatever it's doing right it's a weird idiom what if the exception that are getting is because a state got corrupted asking it to continue run is not going to magically fix that state okay so that's the idiom that we don't like we like to do something different if something goes wrong with the manor remember those are processes and because those processes are isolated if something goes wrong with the mahler it's not going to affect the other entities in our system so what we say that well if something goes wrong when I try to send an email something that was unexpected happen what we want to do is let it crash let it fail because what we are going to do is that we're going to define supervisors that are going to observe the processes in your system and then if something goes wrong the supervisor is going to notice and start a new process in place of that one to continue doing the work of send emails and why this EDM is so important I like to give the example with our computer sometimes our using our computer and then there is a twitch in the corner of the screen or you know something happens in the operating system and it doesn't work at all and what you do is that you go you restart a machine and the problem disappears you continue using that machine for three years five years and the problem never comes back again right and we're starting fix it because we go back to that initial state the initial state that's guaranteed to work right if there is something that the manufacturers of our computer they cannot mess up they are the boot structions okay those are the ones that are being test every time your application when you start a test to it you're going back to that initial state so here is the same idea if something goes wrong with a process sure crash away we have a supervisor the supervisors going to observe that and it's going to act on end and sometimes this supervises themself they have supervisors which may have supervisors so we end up defining the supervision tree which at the end of the day with packaged into something called an application so if we're talking about idioms for talking about vocabularies right we're not talking about processes supervisors applications and I understand that this can be a little bit too abstract in engine we need more concrete examples so I want to do a very quick pause on the presentation and show an actual live demo of a system and how we can actually see those concepts all right so great so what I have there here is a terminal and and I just started interactive Alex Rochelle here we type regular Alex your code I don't have time to go into the language demo that's not the focus for today the only thing I want to do here so here is a web application so we have a web framework called Phoenix and here is a web application that is running on top of the Phoenix web framework so I'm going to start it - called observer one thing I like to joke about that the names in Erlang they're also really good like the supervisor supervises and the observer observes so when you do observer start it's going to start this beautiful beautiful beautiful graphical user interface here where you can see a bunch of tabs that brings all kinds all different kinds of information about your system so the first one is the system tab right is just talking about you know how much memory is using it give even gives you an idea of where the memory is being used how part of it will be allocated to processes you can see how much the code itself is taking of memory and it gives information how many cores you have for how long it's running and so on and so on okay and then we can get information like load charts because it just started to snow nobody's accessing it we're going to have to get any information here you can see memory locators is where the memories are located and a bunch of interesting stuff I can I'm not going to go through all those pains they are two that I really love and I want to talk about so the first one is the process so the process shows all the processes that are running our system and how can this be useful so imagine that you have a memory leak in your application okay and and then what you can do to try to find this memory leak that it can open up observer and you can come here and say well I have our processes here let me order those processes by memory and then if you order by memory then you see process that's always growing memory saying huh I guess my memory leaks there you can double-click it and then it's going to open up another window where you can see what that process is doing what code is is securing what is it state what are the messages that it still has to process stack trace and so on okay so we can see that you're starting to get a lot of disability into our system when we are designing with processes very nice in here here's something else that we can do with this pain and this is an actual true story so we have this Phoenix web framework and one of the things that they wanted to do that they wanted to reproduce the whatsapp use case where they got two million connections on a single machine so in this case is going to be slightly different because they want to do that over WebSockets so the Phoenix team they got like 40 clients to send requests to this big production server I think it had 96 128 gigabytes of RAM and 40 cores so you get all those clients set up and they started hammering this production server and when they started to do that to to to measure their system for keeping all the clients connected the first time they did it they could only get 30k connections which is way way lower than 2 million that they were hoping for and how did they solve that they open observer and then they came here and they asked her to order by message queue so what is the message queue every time processes they send the messages those process they go to a message queue on the recipient process and then the process processes those messages in order ok so it's basic process that is a bottleneck that everyone is trying to talk to its message queue is going to grow and grow and grow because it cannot keep up with everyone's requests so it just did that and then they came and they ordered by message queue and they could mediate see where was the bottleneck in their system and then they said okay there's the bottleneck let's fix it they remove the bottleneck they did it again I think they went to 100k and then they did the same thing found the next bottleneck and then they removed that one and they did God and they got to 2 million connections they were able to reproduce that case that was simply using observer to find you know which process everyone's trying to talk to where the issue is so this is very exciting the process paying and also like a lot the applications pane so when you run a system in airline or an Alexia you actually have a bunch of applications running side by side so this Phoenix application you can see here on the left side you can see all the applications that are part of the system so Alex here itself we can find it here elixir itself is an application and you can see that it has a very small supervision phrase so what we are seeing here on the right side is a supervision tree there's not much interesting that is happening with Alex sharing things of processes but if we open this application itself which is called dev app so if I select it we can see that it has a bit more interesting supervision for here so you can see that we it has a supervisor here you can see you can see that it has a repository so if you want to talk to the database we have this repository Fink and we can see here what is repository this is that it actually has a connection pool that I'm clicking here and you can see that this connection pool has a bunch of other processes because when you want to talk to a database in programming languages what you do is that you have a pool that holds a bunch of open connections to the database and when your application needs to do a query you get a connection from this pool you do the query and then you put this connection back to the pool right and we can see this very clearly here each connection to the database different process we have the boot process and because we can see it here we can actually try to reason for example what is going to happen if things go wrong imagine that there is a bug so I'm picking the process at the top and you can see that some processes have names because you are able to give process names but if you don't give a pass the name it's using this term which is in this case like 0 285 0 this is the process identifier so you consider that I have a process identifier that is representing a connection to the database I can say well what if something goes wrong in this process what if what if there is a bug I can double click it and I can say I want to kill this process and then what we expect to happen is that if that process is supervised something's going to notice that that process is gone but we said somewhere that we want a push 10 database connections so something should notice that and start a new connection to the database and we should go back there we can see that 285 is is gone and then here at the bottom we got a new process identifier for that where we just add it to the end of the pool ok so the supervisor acted and react on it so we can even do more interesting things what if there is a bug in the connection pool right what we don't want to happen is for the the part to have a bug in the connection pool and then the connection pool process goes away and we leave a bunch of dangling database connections that would be a nightmare right because eventually you're going to have 1,000 database connections because you're leaking connections and we can kind of already get the intuition that this is not going to happen I don't know if you can see with detail but we have a bunch of blue lines connected connecting the probe process with the connection process and those lines they are linked which means that if the pool goes now all those linked and process you're going to go down as well so let's see if that's what actually happens let's cue the pool process and when we do that because the pool process itself has a supervisor we are going to start a new pool right and we can see here that we've got a bunch of new connections so the old ones they're all reclaimed right they're all killed as well their connections of the database were terminated and we started a bunch of new ones so all right that's not butter was hoping for beautiful so if you're talking about applications now right this new world that we just got it right we are talking about introspection monitoring we see how a lot of information that we can get from our system we can start to visualize how the code that we wrote is actually going to behave at runtime we get visibility of the application state because the state exists inside those processes you can actually go through the supervision tree clicking those processes and see what is the state what it's doing what it's running it's easy to break into components so imagine that you're working on that application and the tree starts to grow larger or start started to grow deeper what you can say is that well what if I get this branch and move it to another application we can have a bunch of applications running side by side right and or what if I get this sub tree and move it to another application so we have a lot of disability of how we can break it apart and it gives us reasoning when things go wrong so if you are talking about idioms right where we learned about processes sorry we learned about processes we learn about supervisors we learn about applications we are talking about message passing now and we've got a lot of interesting characteristics out of it so now we're talking about concurrency we ditch the catching errors catch exception idiom by something like fail fast or or let it crash if something goes wrong sure let it crash because a supervisor is going to notice that and is going to act on it right and this is extremely important because it allows us to build system data fault-tolerant systems that when there is an error it's going to view itself and go back to a working state because it doesn't matter which programming language you're using it can be the most advanced type system we are going to get errors especially if we're talking about systems that run over the network the database just disappeared for five seconds right so we need to have this ability for the system to Hue itself and go back to a working state the creators of Erlang so if you talk to Joe Armstrong he's going to say you know how they were using airline to build systems with nine nines of reliability right exactly because ability to hear itself and there's something more that is actually in the title of the talk that I haven't explored yet which is distribution so how do we get distribution out of all of this so if you go back to this example or have processes that are all running at the same time and they are exchanging messages the message passing is abstracted away by the runtime that it actually doesn't matter if the process they are on the same machine or they are in different machines as long as I have the process identifier I'm going to be able to send a message to it okay and that was one of the things that really fascinated me about air link back then when I was exploring it because we're having this race for concurrency and not language is focusing on concurrency but what happens when you're already using of the 48 cores on your machine you need to have multiple machines working together towards a common goal we need to start thinking about distribution and airline is they're really thinking about distribution in erling concurrency is a special case of distribution where it just happens that all processes they are running on the same machine alright so that was really what fascinated me and that's what I wanted to talk to you about when we think about idioms so this is the way we approach thinking and writing software in Ireland and in elixir cool so that was the second part of the talk and you got this idea that in I was and everything I was saying there it's actually it comes from airline nothing about it is a specific to Alex here so you may be wondering why Alex er then why not why don't I go in his airline so that's the last part of the talk okay I want to talk specifically about Alex here and what I believe it brings to the virtual machine and the ecosystem okay and every time I'm talking about elixir I like to talk about it under the perspective of three goals the first one is compatibility the second one is accessibility and the third one's productivity compatibility is easy you just say is that everything have said so far about airline it just works the same in Alex here a process in their length it's a an elixir a topo in Erlang at least in Ireland they're going to be double the listen elixir we can call air link from Alex here in this versa with no performance cost so that's the first go of the language compatibility the second one is extensibility and there are different features that we have that I believe make the language more accessible and I want to talk about two of them and before I go into the features themselves I really like this quote from guy Steele he gave a talk growing a language in 98 it's one of my favorite talks and at the end he says now we need to go matter we should not think of a language design as being a pattern for language designs a to for making more tools of the same kind and for Alex theory we express as I said accessibility in different ways so one of the ways expressed that is meta programming with Lisp style macros so I want to show two examples I won't be able to go due to time constraints into the details of the macro system but it's nothing new you know when McCarty published the list papers he talked about Emily's a nice list and the idea here is very similar to Emily in the sense that we have on language that has a very straightforward translation to ast and then we have macros that work on the desde just that almost nobody talked about Emily's plater right everyone's when we talk about this everyone's thinking about the s Lisp but in this case we went to a language that has a straightforward translation to ast and the macros work in zesty and here's an example of how you're using macros in Alex here so here's a manicure code it took a while for you to see some a lexer code and here is how we write test cases in alex here and what i want to show in this example there is nothing fancy happening here right but I want to show that one macro in this example which is there a certain macro depending on the programming language or the test framework that you're using this is a logo you should never write a certain one plus one week oh shoot because if you get an error if that thing is not true you're going to have to get a report like expected true but got false which is not really helpful but in annex e assert is a map as a macro it has the ability to look into the cold to look at the environment at compilation time so that's why we can write this code like this and Alex here when there's something wrong in your tests you're going to get reports like this one so we're going to say well I actually could see that we're trying to compare two things the thing on the left is this the thing on the right is days and here the value by the way here is a diff between those values and here is her is where it happened if you have complex expressions when you're doing assertions assertions with variables we've tracked all the variables and India reported say and by the way this variable that you are using our assertion has this value this value and this value so it's a simple macro that can look at the assertion and try to extract a lot of information out of it to make your life more to make a life better more joyful right so you don't have to change in the book the code we are giving you all the information to you so this is an example of getting the language and extending it to the task domain and make that making that a really productive experience here's some other example so if you want to talk to the database in a lecture we have this project called active and inactive here's how you write queries and it's very similar we got a lot of inspiration from link that you know we have in dotnet and Sitia c-sharp but linked it's literally language integrated query but in annex Siri because they have macros we can express our queries this way without being degrading to the language is just a macro from at the beginning is a macro at all allows us to write well for each from each post in post I want to get the post that were published before now that I am the author and order by the time they were created and because it is at compile time we actually look at this and we compile it as close as possible to Seco during compilation time so when it gets run time and actually to run the query we're not wasting CPU cycles are doing network so those are very small examples of you know how you're getting the language and extending it to some particular domain in this case we are it's going to protect you from psycho injection attacks and everything that expect something that runs runs queries against a database to protect you from and if you go to the community you can see a bunch of other interesting examples as well and that's one of the ways we do we make the linkage more extensible by having matter programming with list style macros and the second one is by providing open and hoc polymorphism with protocols and before I go exactly what I mean by this let's see why we need this so let's go back to Airlines a little bit so imagine that someone wrote a library called JSON and the go of desire is to encode different serialization sterilization to Jason to encode different data types that you have in the language to Jason and the way you would do that in Erlang for example is that you would define a mean cold function and we say well when that item is a list okay that's how I'm going to encode that item to list when that item is a binary that time watching code that item sorry when the items are listed how I'm going to encode that leads to Jason when the items are binary that I called a binary to JSON and so on and so on and then after you define those clauses okay you you're going to define this in a module in a module called Jason and you're going to put the first code online okay and then imagine that what it did is that you got this source code and you put it online and then someone in your team is working on a particular problem let's call him Bob and Bob he realized that for that problem if he uses a particular data structure it's going to make his life much much easier so he decides okay I'm rich men's data structure and then when he comes to and say well that's great but I need to encode this data structure to Jason so I can send that information to the client and then what bob says well but the JSON library doesn't know about my daily structure right because that's an internal data structure here for our company this product JSON library doesn't know how to encode it so what Bob does that is when say well I'm going to fork that library and I'm going to add a new class to that list of clauses in the same module that we just saw that knows how to handle this thing and that's great but there is some Nell's Joe working on some other feature where he uses a different data structure doesn't matter which and then he's like well we also need to encode this to Jason and then joe says I'm going to work this JSON library and then he adds like claws he goes back to that code he adds it claws at the end and says here's how you handle my data type and now in the new to incorporate incorporate the changes from Joe and Bob what do you do you create a third fork that is going to incorporate the change from Joe and from Bob and maintain that that doesn't work it's not extensible right so you either need to change the json library to allow you to pass functions around that's going to carry that information right and the reason because of that is because the module Chaisson right it's it's close for extension right after I write I save that file on disk I can no longer extend it I'd only wait for me to do that it's by 4k and copy that file and adding new clauses and the issue here is that we are trying to have all this logic about encoding those different data types in a single place in a module but the truth is the data type is the one that knows how to convert itself to JSON we should not centralize it there we should ask the data pipe a how do I represent yourself in JSON and in Alex Erie we do that with protocols so we define a protocol for example the JSON protocol that has an encode function and then we are going to call it as we would call any elixir code and that's it we define the contract and now we just implement the protocol for each data structure that makes sense so I can say well implementation of the JSON protocol for lists is this the implementation of the JSON protocol for bit strings is going to be this one and so on and so on and then when Bob he's working on his new data structure and then he needs to teach the JSON library how to encode that they restructure he just implements the protocol for his data structure and that's it it's extensible right I can write a JSON library now that is extensible to any data type and that's something that you know as developers we are familiar from when you're coming from a bunch of different programming languages right one protocol that is very common is a protocol thats related to collections in elixirs the Yerba protocol so for example you can use in the map to traverse lists and News in no map to traverse ranges here's a very interesting use of another protocol so in Erlang if I create a dictionary with key a and value one if you do that in the terminal this is what you get back you get a bunch of gibber's you get the internal representation of the dictionary and most of the times unless you are debugging or fixing a dictionary library you're not interested in that that representation right it's actually really hard for you to find what are the keys and the values but in annex C what we do is that well I'm going to ask the data structure what is the best way to represent itself to a developer so the same thing in that experie is going to return your DS and say well the kids a and the value is 1 and sure if I write in the library an you want to the bug you can disable it but by default that's what I'm going to show you only the the details that you care about so that is extensibility and the final one is productivity and productivity is kind of hard right how can we say that one programming language is going to be more productive than the others we have studies that show that in some cases we actually show that but generally speaking it's kind of hard to assert so what we did for Alex theory is that we're going to guarantee that developers they are going to be productive with the tooling so I'd like to say for example first-class documentation documentation Alex theory should be easy to write should be easy to read very good tooling so it calls the test framework that we saw about interactive Alex here it comes with a tool called mix that gives you a mechanism for compiling your code testing your code and everything so from getting if you're installing today you're excited about the stock and you want to play with it it takes you literally to commands right to get to a working project you create a new project and then can go into it and you can run tests you can compile everything is ready ok so here's an example of the documentation as I said should be easy to write should be easy to read so if we write if you document your ap is right you can access it from the browser you can access it from the terminal you can access it from your editors it doesn't matter it's going to be accessible ok we have a package manager if someone has solved a problem you do not need to solve it again and hex is really interesting because it started as a package manager for Alex here and it became the package manager for the whole airline ecosystem so that's really nice of nice example of the communities interacting together and then having a bunch of available resource around so again if you're excited about Alex here you want to try it out you can just go to the website you can go to the getting started that's going to Kathleen started with the language if you are more interested in books podcasts screencast pick yours you can go to the learning section and we have a bunch of different resources available ok so those are the three goals that we have for the language and I think that's where we are it sets a lips apart from the other languages in the ecosystem right so it is focus on compatibility this focus on extensibility and this focus on the tooling on the documentation that is going to make you more productive at the end of the day right so I want to thank everyone for listening to the presentation I also want to thank my company platform attack we are a consultancy in Brazil we have been working with Alex here and the echo system for almost 6 years and we are really proud from where we are right now and that's how all I have to share [Applause] so for questions there is a microphone here I believe so if you want to ask a question you can go to the microphone I'll stay around also the whole day so if you want to come around and ask yeah we'd love to have a conversation so I have a question yeah I was wondering so you say that compatibility is one of the goals how easy it is to have projects that have arts written in alexia parts written in in Erlang or basically calling from Erlang into elixir and from elixir into Erlang yep so that's a very question so one of the things that it doesn't have happen so let's rewrite a little bit to the talk and those idioms everything that I was saying about it's shared by those languages which means that datatypes processes supervisors really the semantics they are all the same so it's very common for example that when you start with Alex here you don't know anything about air link but you're doing Alex here for six months and then you go read the air link Docs and you can understand everything that is there because it's the same terminology so I think interoperability is actually because of the compatibility layer doesn't get really messy because the concepts the semantics they're really the same and then once you get past the syntax differences you it's very easy for you to mentally map from one or the other and even to the point that we like to say in Alex here we don't like to wrap airline so if I have a library and all that's doing is wrapping airline calls they say no there's no reason to do that right it's going to be fine to interface and all this interpreter ability so yeah so that means that these protocols they they are removed by the compiler they're not entities in the so the product that's yeah very good point so the protocols after they are compiled they are what we call being modules they are the modules for the VM and all the information need to do for the dispatch it's daring the modules so if you want to just move that to Alex here oh sorry - air link and use it from there it will be fine great thanks you're welcome so if there are no other question let's

Channel: Curry On!

Views: 7,638

Rating: 4.9503107 out of 5

Keywords: curry on, elixr, erlang, programming, programming langauges, functional programming, fault-tolerance, distributed programming

Id: MMfYXEH9KsY

Length: 44min 14sec (2654 seconds)

Published: Thu Jun 22 2017