ElixirConf 2018 - Opening Keynote - The Next Five Years - Jose Valim

[Music] good morning everybody how's it going that's great it has been almost a full year since we last met who was here last year that's beautiful all right so I'm really glad to be back here and today talk is the next five years and why the next five years right so a very quick timeline of how things allegedly happened so in 2011 elixir started at this point it was we really had a name it was elixir but it was very different from the Alex Erie that we all know today so a bunch of prototype experiments and then throughout this period at some point there was a vision of what elixir is a programming language could be that's when I went to perform attack the company I worked for one of the co-founders and I said hey you know I have this idea of this programming language that can solve some particular problems in a very interesting way and I asked them let's do this and they said yes let's do this so that was the very beginning of 2012 and then trees and a half later we release Alex here well not for Oh 2014 2014 release alak 0.0 the first stable release and last year when we were here right Alex 0.5 was just out and at that moment it was five years since we like I started working on Alex her full time so the keynote last year was pretty much looking back and kind of looking at what happened and you know revising our goals and where we want to go so my father would be really nice for this year to kind of now so if then the last year were looking to the five years before us so what if we look to the five years ahead of us right so so now we are here 2018 and XT 1.7 was just out so we are going to talk about the lecture 1.7 and then look at the five years ahead so what is the agenda for today so as usual I always give a very quick update and what happened the latest selective release then you're going to talk about ongoing afford so if have been following what is happening the community in the community especially what the LXE require team has been working on over the last year we have started a bunch of different efforts I'm going to give an update on all of those and share some new things as well and and then we're going to talk about next five years so electrical not seven electronic seven was just out and it was a minor release and it was a minor release into a so it was a minor version bumped from 1.6 to 1.7 but also because it was really a minor release there was not there was no new flashy features right it was continuous improvement iteration of everything we have so and that's what we should expect we're going to talk about this a lot in this talk which is but that's what we should expect from the future releases as well right we you're not going to have a lot a lot of new things modifications of how I write and cleave software we're just going to continue improving what is in call right now and so it came out in July 2018 and we are getting close to 800 contributors the whole beam community right we've we've passed we are past 7,000 packaging X p.m. we are getting close to 300 million downloads that's a lot of zeros right so we are growing right we continue growing in all the sensitives well we when we look at the code right the contributors are growing when I look at the packages when we look at the doom it ups and it has been a really health growth so far it has showed some pains I'm going to talk about this as well throughout the talk right but those are very good signs right and when we come to Alex 1.7 the major feature so there are a bunch of smaller features like improvement to logging improvement to the test framework but the major feature that was Alex 1.7 was actually that we adopted EP 48 EPS tends to early enhancement proposal so when Alex 0.5 was out a year ago one of the big features five us that we actually standardized how all being languages is tor AST or your code information in the beam chunks so that has been standardized so it's easier to write tools that work across all beam languages and the idea of EVP 48 is do the same thing but for documentation so this was a proposal written by myself Eric and Radek and the goal is literally to standardized how beam languages they're going through store and format documentation so we can have tools that work across the whole ecosystem as well so what does it mean for example today if you are using the interactive Alex Rochelle you can say H and type the name of an electric module and it brings the documentation but if you do H and type the name of Vernell of an Erlang module that doesn't work now that we are standardizing how-to documentation stored in from red this is going to work in the future that's the plan so we did this proposal of the format and then we implemented for elixir itself and so it's a long term afford right so Alex we implemented it and we are waiting for the other languages to implement it as well but in the future we hope they're going to have this interoperability working and but we don't need to wait for the future to reap the benefits of this change so one of the things that this change made possible it's actually the addition of documentation metadata so so for example we use attributes like at dock to document a function but now you can also pass metadata like what are the authors of this function when was this function added so you can add any kind of metadata to the documentation and we are already starting to use this document these metadata in some places so for example now in galaxy documentation if there's deprecated functionality before we had to write it in the tasks in the text of the documentation satellite is deprecated but now with the metadata you use the metadata to say what is happening and now the exedoc - to generate Doc's get that metadata and put there in the docs right to make it easier to browse if we have the metadata you can navigate now everything that is duplicated there a lot of interesting things we can do the other thing is that I don't know if you can see it I'm I apologize if the example is a small but also now on all of the functions that we have in our documentation if you look at the top right corner there is a sings saying which version that thing was added so people who like right elixir libraries sometimes we're in a scenario wrote a piece of code and then CI fails because the piece of code you're using was using like recent elixir features they're like okay so which version will actually support now before you had to go I I did this many many times I had to go through each version of Daleks or documentation say hey does this thing actually exist in documentation but now it's just there I can see when it was added and they are a bunch of other X doc improvements that are on the pipeline alright so you know as I said was the really minor release a bunch of small improvements not nothing really big and because you know the what we should expect that to work on elixir is starting to not a lot of things are happening there but actually the things are going to be happening on the community on the hueco system right so I want to talk about a couple of things exciting that happened so for example meanwhile in the community and I cannot possibly cover cover everything okay that happen in the community so just some general highlights like we got new podcasts more people talking about elixir and discussing and discussing Alex here we were talking about documentation we got new X doc versions we as a community we are proud to say documentation in Alex series first class right and those improvements continue to show that it's first class it has always been first class we are continuing to improve it to improve it right they are not satisfied something that also happened is the release of Erlang OTP 21 so and there are a lot of nice things in this release blurring the nice things is that the wrong time in some benchmarks got from 5 to 10% faster and that actually revealed too so as a result of these compiling elixir code in some cases got from 15 to 20% faster as well right so this is really great because I tend Tory in the litter team we tend to worry a lot about completion times and it's not that completion times it's a problem to the majority of any three projects right but if we can make it faster right why not like if I can make everybody in this room like at the end of the day wait one minute last right it's one minute that we all get productive and then if we multiply but everybody in this room can say yes it pays off so it was really nice that Ellen go TP resulted in faster compilation times a new version the next elected version well that age should improve things about 5% as well I know that the Phoenix team has is working on changes for the next Phoenix version to improve this as well so it's really great that again it's not a major concern but we are continuing to improvement on a try the game are not satisfied and if there are improvements they are change we can do we'll take them so in the community also what happened is that over the last year right we got nerves or not oh I believe that right now they are on 1.3 or something like that we got new Phoenix versions they're probably going to have new Phoenix versions out soon and a lot of other things right and there are two things in particular that would like to share review that I am personally like very very happy and I'm going to tell why so the first one is the Alex Erie mini documentary by honeypot so we have a lot of ways that you can learn a lick there and you can understand what it is or you can refer to somebody to explain what elixir is about but we never we never have a visual way like a video where somebody could sit and listen and the honeypot team they did a fantastic job on this so we know if we want to get somebody for somebody asked what elixir is about and you want them to understand what actually is about what if the communities about what is happening the community this is a very great mini document very very great video so I'm really happy with how everything came to be and with the end result and the other thing that I'm really happy about is about the announcement of the membrane framework so now if you ask me what it is I have no idea okay and that's actually why I'm very happy about this because when when I started to do a lecture like one of the goals was that we want a lecture to be an extensible language right so it is supposed to have this is more core and everybody is going to build around it and I knew that I would like to get a lecture and extended to at least one domain which was a domain that have a lot of expertise on which is the web domain right so or maybe two domains if you consider like talking to the database sequel as a domain itself so I knew I wanted to expand I knew I wanted to get allocate and extend to those areas and that's why for example when you look at acto it's one of the oldest projects in director community because we used acto to validate the language itself so you know and it worked and they were like hey this works right but you know there could always be a bias because well it works for active because I'm kind of knew in my mind that that's a domain I wanted to work on anyway so yeah it works and then Chris came with Phoenix and he did a web but he added the whole idea of Realty and I was like hey this is very interesting and then it came nerves that I also have no idea about that I find fascinating right that he's getting a lexer and extended to the domain of embedded software and I was like so you know it's a validation of the goals of the language that were able to achieve it and now the membrane framework is canning elixir and extend it to the domain of reliable scalable multimedia streaming and it's like this is fantastic right because it's showing that again they're getting this a small core and they are extending it to different areas and throughout the conference their way to see other examples like Boyd is going to talk about the why framework cynic so all these like I find it very fascinating and very exciting all right so those are some improvements that are happening in the community we also saw some improvements on the website and this is an interesting story so over the last year so everything I'm saying happened over the last year so we started to hear something so one of those things is it's harder to contribute to a lecture and then we talk to people like try to understand you know where the sensations coming from like why is happening and then we got some feedback and then we realized that you know this is actually true it is harder to contribute to elixir especially if you came before Alex 0.0 where the language and here by Alex are I mean the Alex's language the language itself this is more core right so and I said it makes sense right because if you came before 1.0 the language the score was two being shaped so there was a very high chance that it could come and cause an impact and and shape the how this is more core is going to be but after 1.0 right this thing what we all expect is that this core is going to change less and less because we want now for the whole community for the ecosystem to start building around it right so we said you know what it actually makes a lot of sense especially with elixir in that so I I said it like two ways you can consider a 1.0 release so one way is to say hey we are releasing the 1.0 version of this software and this is kind of the starting point and continue building building building on this and the other way say hey it is like the 1.0 release of the software and this is pretty much close to the to the real deal right like this is the package sure that will continue improving coaching iterating and we have done this throughout the years right but that's the core and elixir was always the second one okay so it does make sense it's harder to build two elixir and not only that the community grew right and then there are less things to do so the laws of offer and demand they're not very kind here right it's actually great as the maintaining of the project sometimes we open up in issues with things of like to having a language and then it's tackled within a 24 hours there's a ProQuest we just need to review it test it and merge it so it's really exciting so we agree it's it is harder to contribute elixir but the last one here is exactly that we should all you know build around the score that's where the focus should be right the focus is in the community is in the ecosystem the other thing we heard is I'm glad the core team is more transparent now so this was really curious because for better or worse the amount of transparency in the electric core team didn't change like constant all the time so we started again talking to people and try to understand why there is this impression and when we're talking them we said but you know like if you want if you want to know what is going to be in the next lecture version all the major features we actually discuss them in the main list before and it gets your forum everything that we plan to have the next Aleksey release it's actually an issue tracker and then we would tell these and people say oh so there is a process so it became clear that at the beginning the community was small like people probably came to use elixir and learned elixir through like just a few ways and they could eventually reach through the ripple story and from observation kind of understand that there is a process of how things happen but it was never documented this process so it was clear to us that so this fluctuation like in this transparency is because they were the process was not written down so you know it's unclear what to expect from the team so based on this feedback we've added a new page the website so if you go to website if the menu at the top there's a development page and there we outline all of those things where Alex you existed how it started you know it tells about the goals of the language that we want exactly to be an accessible language and the focus should be in the ecosystem and in the community and everything around it right we talked about the process if you want to change the language will submit something this is where we go this were you do security reports everything's there right and it's a small change right but I think is more change in terms of a fort but I think it really brings a lot of visibility to the whole process whereas sometimes it was not clear to a large part of the community of how those things work all right and I will also there were also improvements at platform attack that would like to to share review so for those are not familiar para form attack is a software consultancy based in Brazil I am co-founder and director of research and development at platform attack and as I said elixir started as a research and development project inside part of our attack in 2012 and in 2016 it was when we started to have our first electric projects with clients and we got a lot of feedback in this process we talked about these last year as well so we would have experience with those projects and we would get feedback sometimes this feedback would lead to language improvements sometimes it would lead to getting started improvements and so on and some of the feedback that we got as well was feedback from our own services for us as a company and a very common feedback that we got is that companies they would like a way where they could rely on the team the engineering team in the expertise that plataforma tech team has on elixir constantly over long periods of time and it's exactly based on the feedback that we at the beginning of this year we started a new service called elixir development subscription and that's exactly the idea to have a direct communication channel between your engineer team and our engineer team so you can build up your applications with speed and confidence right because when we are learning a new technology and any new technology it's common to have questions but it is about the best way to implement something what is the best way to integrated technology of your existing systems and then if you have a team that can provide you support good reviews and systems take part in technical meetings it helps to speed up this process and give confidence a lot so I don't want to go a lot into this if you want to talk more I'll be around the event there's also Google we put the putter from taxi sure we have a desk right but wonder if I'm excited is that since the the service is started and we are working already with more than 10 companies throughout their elixir adoption lifecycle and delegate Devon subscription it also led directly it was one of the things that led directly to the next thing I want to talk about which is that Wojtek ma he's joining the platform attack team right so the reason why this matters and I'm actually very excited about this right is because when perform attack started to invest in Alex in 2012 I was the only person working on it full-time ok so it was me for those last six years and sure there was a lot of developers at the company that contribute Alex here directly and indirectly but full time it was only me and now if Wojtek joined the company we're actually doubling this research and development team right so it's really exciting for me and and it may be a lot excited maybe exciting for him as well because I was used to do this joke that I was responsible for a huge department of one engineer and now I can make the joke anymore and I know a lot of people appreciate not having to hear this joke again so yeah so I'm really excited to have my tech MA because they have a lot of ideas and things that we want to explore as well in the community in the echo system and having somebody else join the team means that those ideas right it's going to come on to appear and they're going to become concrete sooner right so yeah we'll see what's going to come in the next year's all right so that's it so that's kind of like a very long update on everything that has happened throughout the last year and now I can talk about the ongoing affords right so as I said the Elector team we're kind of like working on different things that we were studying to be part of the language or not be part of the language so you've probably heard about those things already so the code formatter properly based testing X HTTP and releases those were the four main fronts and and it would be good before I start talking about those things right to think like well if we're talking about feature is that we eventually want to make part of elixir right what is the criteria for adding features to elixir and luckily now we have a page that outlines those criteria precisely and this page says that the criteria for near-future is is that who add new features to elixir if they are necessary for developing the language itself okay so if we need that feature as part of the language then we need it as part of the language there's not much we can do so the whole reason like the e^x templating engine it's part of elixir it's because we need it in other parts of elixir although as it could just be a separate package okay and and or the feature and/or the feature bring important concepts features to the community in a way it's the fact can only be maximized or leveraged by make it part of the language itself right so for example Jason who here needs to decoder and coach a ISM right like almost everybody in this room needs to do that so but why is it not part of the language because there's if we add JSON to the language there will be no difference in the user experience compared to a package right you just add one line to your mix access file and done that's it right there is not a very big difference so doesn't make a lot of sense to make it part of the language because again we want to have this more core right we want to have this more core and build around it extend it so that's the reason and there are two guidelines that the dielectric car team follows so the first one is extensibility so again the focus for us is to enable rather than provide we want to make sure that things are possible right and then you can get it and twist it and shape it in any way we want right so we want to enable rather than necessarily provide that feature we are also conservative right I always say adding is easy right it's very easy to add called removing code from elixir it's very very hard because if we just remove code we will break the language right to backwards incompatible we can't do that so if you are not sure we just postpone it right because you can always add later but removing is really really hard all right so let's talk about those I'm going for it so the code formatter and I promise this is the last time I talk about the code formatter not going to hear me talking about the code formatter and any other event anymore okay so what is the code formatter it was released in Alex 31.6 and it formats your code use the echo system style and it helps you focus on what matters right so you know sometimes I send app requests and there are a lot of comments about the the format of that code how to style it and you should rather be spending that time so somebody needs to write that comments and other person need to read and act on them and when you run them for matter a lot of those issues are solved and you can focus on the design decisions and the business logic and so on and it also works as a guide for new comers right because if you're learning a new programming language one of the things one of the many things that you are worried about like hey am I like this this cold style-wise look like code that the community would write and now if the formatter like immediate feedback so that's how their formatter words and what is the motivation for having the formatter in a liquor itself right so does it fit the criteria that we were talking about so the first one is that we needed formatter to format elixir itself as the liquid core team grew it was very apparent to them that I follow no consistent style whatsoever so we started to have a lot of discussions right about the form and it would ask why you wrote the code like this and I'm like I have no idea like it I guess it looked at prettier at the time and so you know we would have those discussions and on how to improve formatting in general and the other things that it would also it also made it a little bit tricky to accept contributions right because one of the things that I never wanted to have any mixer is to have a style guide because I don't think it's a welcoming experience if you have to ask somebody hey you need to read this long document boring about styles before you can make a contribution for this project so people they would often write for quests and then we would merge those per quests as is with a style that we don't agree with and then we would then add readapt the code to the format that we thought would be the lecture code based Foreman so there was a lot of time spent on this as well and we thought well if we have different matter now we can just start everybody to just run the formatter if you send a pull request and did not run it for matter then CI is going to fail all right and then it's going to be easier for everybody to to contribute and it's going to be the first to accept those contributions - alright so that was all the reasons and the second one is that one of the goals of the format is to defy the code written by the community and it's easier if we do that if it comes from the language itself okay however I think it's exactly this second goal that lead to a little bit of friction because we talked about this in documentation is that you can't use the formatter blindly so since this last talk last time I'm going to talk about the formatter I'm going to use this opportunity to talk about this thing very quickly and then we can move on eternally so so this is a true story okay so it is a true story it actually happens somebody came I don't remember it was on IRC or in the Alexa forum and they said hey I run the formatter and in my code and my code now looks ugly right and they're like yeah let's take a look at this right let's see how we can improve and this is the code okay so they're really nice after all these we asked if we could use this example the documentation so it is in the documentation as well so here's the code I know you can see it right that's kind of the point because why it's happening here it's a very long code okay so it's a very long complex expression that is kind of written into into lines and the developer when they wrote this code they were probably relying on a very long line length or they were relying on the fact that their editor could wrap lines to have this very complex expression in a single place so when you run these through the formatter this is what you got the formatter would not accept that right so it's going to break into a bunch of lines and so now that code would pick oh it was so concisely in two lines right now it's like taking six or eight lines and then this is ugly right while I personally prefer this code right that's not the point and you may prefer the other one that's totally fine right the point is there is no formatting that it could possibly apply to this code that is going to make this code actually readable okay but it's true right there is and again like I am guilty of this you can ask there are members of the car team here and you can ask them a bunch of those cases so for example we had functions in the electrical base that would take 8 arguments who who think having a function that receives 8 arguments a good idea apparently me right so so but that happens like on every day like oh you started with function for arguments nothing starts with 8 arguments right that would be really bad but so it start with 4 and then you add to it anyway - you have 8 and then before we vote the FIR matter we were just adding something like oh I'm going over the line length it's fine right it's not a problem just cheating here and then when you're under for matter because go over the line length it would put each argument on its own separate line and I'm like hey this looks horrible right so laundry's like the formatter that it actually helps me keep honest so when we look at those cases we said well actually just running the formatter here it's not good enough we actually have to refactor the code so the format is actually helping point flaws in the code by having this strict guideline and that's what we did right so for this code we were working with this developer and then we said hey what if we get so I don't know if you can still see it because it's - a lot of code but basically it is one expression and another very complex expression so what if this we get this end here the second argument to the end and move to a separate function so we did that and when we moved to a separate function we actually understood what that code was doing and we could optimize it to something that actually is faster so to me the code became better former that it's better to read and performs better - right I'm not saying that the formatter is never wrong right like there are cases so first before queefed Abelar data like I'm sorry is just going to record type or data right so but you know that's the the lesson here is that you don't run the formatter blindly right it's a to the documentation go over different cases where you can give hints the formatter and the that will lead to a better end result right it's over the formatter is fastest right so it sparkling which will continue to be part of the language right but I wanted to share because you know the formatter has been also a very big learning exercise and experience for me because the first time I use her format as well and I'm always like surprise when I'm learning those lessons and I would like to share I wanted to share it with you all right so the second thing that we are talking we're talking a lot about adding to elixir is property based testing so I'm not going to go into a lot of details about what is property based testing so but the basic idea is that the examples that we write today when you're writing tests they are example based tests right you want to test a function you have to come up with a bunch of these examples in your head and then you're going to call this function with those different arguments you are certain the output and that's it we've probably based testing you don't come up with examples you actually write properties things that should always be true so for example imagine that you want to check to test string contains that checks if the string given as first argument contains this training given the second argument so a property that would write is exactly this one so I would say well imagine that I have a string as left argument and I have a string as right argument if I concatenate them this concatenated concatenated string should contain the left side and the right side right so this is a property it should always be true okay so we don't have to come up with examples anymore we define the property and now when you run this property it's going to generate a bunch of examples randomly and on the fly and it's going to test our function under different scenarios possibly helping you spot bugs so property based testing sometimes known as generative testing Genet generally you got the narrative testing it's useful to describe the invariants of the system right things that should always be true and the reason why we're very excited about property based testing that it actually helped us spot bugs in the existent library so we're thinking hey if this is helping us be better developers and we have included a lot of the property based testing vocabulary in the issue tracker discussion in discussions with the core team so if this is helping us be better developer there's probably going to help the whole community to be better developer - and that was the main motivation for having property based testing part of a lecture itself so in a way it's needed for designing elixir and the second one is again to promote best best practices in the community but as we talked and we invest gaining more and more we actually started to evaluate those points so the first one is it really needed like is it really required for design elixir for example sometimes they're going to plan some feature in elixir and we have to a simple made this feature and what we do is that one of the ways we can do that we see which one performs better so we need to do benchmarking so we're bringing an external package like Ben Chi to do those benchmarks we compare those results and then we say hey here is the conclusion that we got from those benchmarks okay so are we discussing to have been Chi as part of the language it's a great library but you know it's fine as a package we're not discussing it to be part of the language because when we need it we can bring it right the fact that we know that it is a - that exists and we can use it's the most important part here so you know before that you know the same thing applies to property based testing we're not going to use properly based testing on everything for elixir it's a very useful design tool and a very useful testing tool but we can bring when it's necessary when you're designing new api's we can talk about properties and so on so after we for about is I thought well it is a great and excellent tool to have and a great technique to learn and have in your and have your mind but it can be it can be brought in when necessary it doesn't have to be part of the language right in the second one is that if requests promote promote best person in the community which library is the best practice because we have more than one property based asset library in a language so which one are we actually going to pick and to promote right because they do different trade-offs and those are trade-offs one it's not necessarily better than the other and the other thing is that awareness grew a lot in last year so for example at ellicsr call this year we're going to have three talks on the subject of testing two of them are about property based testing and one is about software verification and testing in general right so recommend watching the talks and learn more about property based testing as a whole right and we also there is this book released by fred hobart and he's the author of learn new summer laying of Erlangen anger and it's a really excellent book about property based testing with proper Erlang and elixir right for those reasons we have decided that we are not going to include property based testing as part of the lecture itself okay so a string data so the update here is that the stream data which is the elixir implementation of property based testing is going to remain the library outside dellux learning organization so andreia is the one andrea he's there he's the one leading this report and who continued to lead this a far they're still a bunch of interesting ideas to explore and you can still go contribute make her attend in the package and help design and guide the package and will continue to work on this but not as part of the elixir laying team of work okay so i just want to say this right i still think that the idea behind the stream data it's very interesting because so because the other libraries they are properly based testing libraries their focus our own the property based testing parts but with the stream data we kind of like flip these things around like what if we put the data first and then we can derive interesting properties out of it right so one of the things if you put the data first and with their I have interesting properties out of it one of the things that we get is properly based testing but we can get other things so I still think there is very worth exploring this view of property based testing of data generation in elixir and you we can continue to do that as a community with the package alright the other part is X HTTP so what is X HTTP is a native P client that does not prescribe prescribe a processor architecture what does it mean every time you use most of the 83 clients packages that we have in the community if not all they all come with a process architecture so when you do a request we're actually send a request to another process or to a pool that is going to coordinate with something else and then another request and so on the issue is that for example if you want to imagine I want to use you want to consume data from Twitter firehose or in or any HTTP client or any - HTTP API right so for the prefer using gen stage which is one of the abstractions we have the electrical system you would have something like this would have the the Twitter API for example and then you would have the HTTP client as a separate process and then they have the gen stage process so we have this process in the middle that is not adding anything right it just overhead it's just interaction just more places for things to go wrong so the thing is what if we could merge this gen stage for example digitally client and have this to be one thing and the ways we figure out we could do this like well what if we have an HTTP client that does not prescribe a process architecture it's like a very thin wrapper around the socket okay the TCP socket so that's what we're exploring of this library and we're also exploring ways to define the mechanism to interact with HTTP one and HTTP 2 so we are considering having this library as part of a liquor right it's it's not meant to be a full-featured HTTP client right it's the building block ok and what is the motivation fire for having HTTP client in elixir itself so it's needed in elixir right there are a bunch of tests that we do like archive install script install local hacks that is going to install hacks for you and local rebar that is toss robot for you that they needed to be client to get those things right and the OTP team and why we don't need HTTP why we don't need this library today why we don't have it today because we use an HTTP client that ships as part of their lingo to pee it happens for that airline go TP team they have been talking for a couple years and this and the latest release was last time this actually became true that they'll be talking a couple years about breaking our lingo TP apart into a bunch of separate packages and the these are laying OTP 21 it happened for the first time they took a bunch of the korba it stuff out don't ask and and they move it to a separate package right so we thought well there is a chance that they may remove it the HTTP client and we need to be ready for this later we end up talking to them and they said like it's unlikely they will actually move be client even if they remove the one they have today they'll have a very free lightweight one so it actually turned out that we don't need to worry about this scenario so we have enough sex HTTP but throughout the last year again we discovered that well it may not necessarily become part of elixirs so their Forks they're going to continue outside of the elixir language and Eric and Eric is around here and he's the one leading this effort Andre is helping as well so if this is an area that you are interested on and you're really you want to contribute get started with the project again I really think the idea it's very interesting it has a lot of potential right so if you have something small that everybody can build on top right there's a lot of potential in that so I definitely recommend of exploring it and the last ongoing important that I want to talk about they are releases so releases they are the best and the safest mechanism deployed systems in elixir still and it will eventually become part of a liquor right because it's part of our lingo TP so we just need to put the elixir makeup on it and and have this fully integrated okay we have so it was always in the plan to do this and we have made good progress and by we I mean the community as we're going to see over the last year so one of the things that we did is that we had a huge discussion the elected forum about integration how are people using configuration how should we change configuration what is the difference between compile-time configuration and runtime configuration and as Brian said just before the talk so Paul and Dockyard they recently announced distillery 2.0 right which is a major improvement to how the release process is happening the community and exploring those ideas of how the configuration should work so there's a lot of exploration on feedback happening here and you should try it out and give it back to Paul and continuing prove it is right so really nice a fantastic work coming from Paul Dockyard here and the goal is to eventually write to have leaks releases or as part of Alex or core so regarding release we had a lot of progress in the configuration front right now we are doing experiments we furling go TP to simplify things so couple things are going to be simpler and more efficient if we change our lingo to pee so we are playing with those ideas maybe to become a pro request we can get it merged Lucy ought to happen and overall what we want is that the releasing core don't have a smaller put in distillery right again the goal is to enable rather than provide so it may not come with all the bells and whistles that distillery has but the core will be there right but for now it's still ongoing work Paul is the one that is working on this so and for now the best way to go is still is still distillery right so continues in the surgery and we'll keep you updated in the progress right so if we look at the ongoing efforts it's actually a little bit for looking for flashy new features more worn at the beginning to talk but we got a code formatter we decided that property based tests and access to P is going to be built as part of the community and release this isn't going however there's one last ongoing part that has happened over the last year that it's actually not on the list and we haven't talked about it in the past that I would like to share with you so what is this so there are two things I would like to share with you right the first one is that we started work on a type system wait the second one is that we stopped working on a type system the last one is always wait for all the bullets to come out before before clapping alright so yeah so type system this is a very long topic there is no way I can do justice to this topic in ten minutes that I'll try to talk about this but I thought this important for us to talk about it I know there are people that are exploring those ideas and since we explored a little bit ourselves I think it's fair from us to share what we have learned with the community and hopefully somebody else is going to pick up those learnings and is going to try something different and so on and so on so over very broadly speaking right right is why have static types like static static type checking in in elixir so when we ask people why they want that the biggest thing they want is detecting errors by a type checking right they want to detect errors early on and and usually here I do the disclaimer right because you can detect errors early on but there is no type system in the road that is going to protect you from all errors right so you also need the safety mechanisms that when especially if we're talking about distributed systems or things that run over the network right suddenly the database disappears but for five seconds it's a mystery right but it disappeared and we need to be able to cope with that so having the failsafe mechanism fault tolerance mechanism we have a value today it's strongly necessary right and a static type system does not erase that it would actually complement that it would help symbols not come into production but they are still going to happen that's life right and we need those mechanisms in place but if we can detect the errors earlier why not right depends on the cost of having this but if we can have it and assuming it's fast it's productive it's good for you for our experience as user delaying why not so that's the major thing everybody talked about the second one is documentation in tooling and we already got improvements where the get improvements related to the commutation told him because we have tax packs in a language and there are people like Luke with IntelliJ and Jake Becker with Visual Studio code is doing great improvement great progress in those fronts about improvement documentation and tooling in regards to types and everything else to the type specs and everything else but we can still improve right and possibly a complete type system would allow us to improve even more so it's also something I would get and the third thing is efficiency and performance but this is not going to make a huge impact indexer sure we can improve a couple of things but generally speaking it's not going to be life changing in any way right because they're still running the Erlang VM that is that is work with the dynamic types in a way so we don't have a lot of leverage from this particular error but those are kind of like the features that we expect from us from having a static type system and in the order that the community finds it more important so what is our attempt okay so our attempt was to accept as much Alex your code as possible so if you want to have a type system the language in an existing language or any things I'm going to do is to have to change this language as little as possible okay so that's one of the things that we had like this is what we want right and for these we're going to perform local type inference so what it means that you would write a function and even if you don't put any type for this function we would figure out the types for you so you know so when you look at this it's like it's the no absolutely no compromise approach right like we want to type all of the electrical we have right now and you don't even have to add the types right this will be magic so and we want in a way that type of code can only interact with piped code so it would be closed after you go to type it code you need to leave type it code okay so what is an example how this would work okay so imagine we have this code and this code is totally no sense it doesn't make you know but it's enough to show to show a point here so imagine we have this module called converter and we have two functions written today so it the first one is into a string that converts an integer to a string and the other one is a string to Adam that converts straining treto and then imagine that instead of using that module we would now use something called def typed okay and when used F type we know that that's a type add module and then if you don't define any type specifically we are going to infer the types for you okay so the first function we are going to say that that's a function we can infer that that's a function that receives an integer and it returns a binary which is how strings nullity are implemented the other one is a another completely separate function that receives a binary and returns an atom okay so we would do this would get inference it works right the problem is that in Aleks C we can write code like this imagine that we get those two functions and merge into one with just one single function okay so one single function with different clauses so we have this function now called notice that when it receives an integer it's going to return in a string and when it receives a string we need to return an atom now to type this we need to use something there are different ways implement is the way we choose is to use something that is called in literature as an intersection type right so I would say like well the type of this function here is now that we're merging those clauses is the intersection of the first Clause with the second one okay so we started exploring this thing called intersection types and we figure out that intersection types they're very expensive in terms of inference to the point of being practical right and I'm going to show exactly why it's just it's very funny because we worked on these read a lot of papers all intersexual types they got a prototype working and then we started to notice that everything was getting super slow to the type inference and then we went to talk to some professors and then would say hey we'll use type inference and it's very very slow and then they would be like immediately oh they are known to be slow for inference right and all of the papers talk about it though the papers that we read right so it's very interesting because that's not sir at this point with intersectional types I think it's two exploring if the things are decidable how inference works that performs is not a concern to having that moment but apparently it's a known thing right but we figure out the long way that that's the case and the reason why is this so let's take this example here in a lecture we have the end operator right launched coin operator so a and B if you're going to type this in elixir would have a type like this it would be very close to the implementation right so how does it work if the first argument is new this thing returns new if the second argument is false this thing returns false if this and then if the first argument is everything else this thing is going to return whatever the second argument is okay and the same for or right so when the first argument of or is new will return the second argument when the first argument for ORS false return the second argument and then for anything everything else we return the first argument right now if we have to write this code and/or that receives able C and computes a and B or C measure the write this code and we want to figure out the types for this we need to consider 27 different combinations right because we have three arguments and each of the operators they have three clauses so it becomes 27 cases and you can see that in a large software this is going to become really bad really really fast so that's what we learned and and then we said okay so if doing inference is expensive what if we just require all the inputs to be specific type so we don't do interests anymore we can do inference for the output / all the inputs need to be explicit type typed we tried considering this and it just didn't feel like elixir anymore right because now you are in this death type of thing that behaves kind of different it requires input and then depending what you are going to do right you have so if you had a problem it would have two different ways where you could tackle this problem one that is typed and the other one that's not typed and we just felt like this whole idea that we have over a small core to the fall apart like because we'd like fork the language and have two ways to do everything so that's why we stopped working on it okay so what are my suggestions and that's actually the main point of this whole thing okay we should consider all the ways we should explore other ways gradual typing there are a lot of people talking about where they'll type lately so if this is an area like would like to explore type systems you know imma show you I just showed you one direction that did not work but there are bunch of other - just explore gradual type seems to make sense in general and there's - a lot of you were out right we need to figure out how we're going to type processes how we're going to do meta programming are going to handle with the intersection type like with the phone case with multiple clauses and there's actually one apart coming from air link which is a project called gradual Iser that is attempting to add gradual types to Erlang and would be able to benefit them from an exterior directly so that's another area could investigate right so when you look at all the ongoing efforts right we add a new one at the end that did not work locally referred intersection type that one did not work it's all going to be part of the language ever but the point here is not that we're saying we're not going to have types we're also not going to we're not saying that we are going to have types right we don't know but the points that we tried something and now it could be your turn to try something maybe we'll try something again in the future when we regain some breadth right so you know it's really up to us generally speaking and not and it can be that you're going to go home and go to explore a new idea you're going to try it out and next year we'll be presenting as electric calls what is tried the lessons learned and then somebody else can get those lessons learned and eventually can converge into something that we can all actually use so this brings me to the last part of the talk ironically is the title of the talk but it's the shortest part so the next five years and one of the things that when we're talking I was talking to people I like hey what do you expect the next five years for elixir one of the things that people talked a lot right when people came to their mirela kind of the first thing is a lecturer 2.0 right but I strongly disagree right because so people would say well we would have X dot 0 that is going to have like new features to the language that for some reason we can't have today right and the reason I disagree is because as we saw a couple times from this talk and lick C was designed to be an extensible language right again this is more core that we can build around it right one of the focus was actually that we want to have the tools that we use to be the two that we used to build the language to be available to the whole community right so if we need a major language version to change the language itself then we feel to be the accessible language right if we need to release elective to not all to get up with new features to make things that are not possible today to make them possible then it means that we failed right the language is not accessible so in my mind right when we talk about alex 3.0 it's not coming anytime soon okay it's if there are changes that need to be done we can get the language you can do change those changes now we can improve the language today okay and actually from 2014 this release 1.0 there is only one breaking change plan of our 2.0 okay and it's ridiculous minor change it's the result of the dark attribute something like that that's very few people rely on and for me this is really good this is a really good track record right if in the last four years that's the only breaking change that we have cumulated that's because alex is extensible right new features and less process they can be implemented today and that's what we do right sometimes we say hey there's a better way to do this and then we have a new feature and eventually we deprecate the old ones the old practices okay I know you know that we do have the vacation warning so an epic reality version usually cut application warnings but the plan is to eventually stop right because again there's no core we are having less and less changes eventually we will settle down so a lecture 2.0 if we ever have this release right the only goal will be to solidify best practices and remove the brocaded ones so ideally I'll accept the handful of breaking changes that we may have right now I just have one right but ideally if you run Alex 0 not 0 in I'm sorry if you want your software your your application in Alex 0 1 dot something the last the last electro a lot something and you don't have the vacation warnings when you're pro great Alex three to that thing is just going to work right that's the ideal right that's what we want so but again we are not in a hurry right does not start coming in time soon so we talk about the next five years the last major planner feature for elixir is releases that's it there is nothing else major planned right that's the last thing it's actually it was actually there since the beginning since well not zero so if you go to a texture called 2014-2015 we talked about releases right and that's the last major report new projects ideas developments they belong to the ecosystem right and they're going to be sparked by the community it is going to be the little core team Phoenix nerves membrane scenic any library that you are working on right it's going to be explored by all of us together and that's what I want to share at the end that the next five years they are in your hands thank you very much [Applause]

Channel: ElixirConf

Views: 13,536

Rating: 4.9574466 out of 5

Keywords:

Id: suOzNeMJXl0

Length: 57min 55sec (3475 seconds)

Published: Thu Sep 06 2018