Keynote: Q&A with Chris McCord - José Valim, Chris McCord | ElixirConf EU 2021

[Applause] [Music] [Applause] [Music] all right so if anyone wants to come up for free or send through the app and we're going to get it in i'll be the first one and chris why don't you answer my messages which messages pretty sure i answered your message last night at midnight yeah yeah we actually talk every day so yeah so i'll start with the one from the app which is i think this is a cool one to get started where i did the name i heard this story but i barely remember it so where did the name phoenix come from that's a great question so i'm going to turn my volume down so i'll have to use jose's body language if he needs to come in um all right so the the the name came from well one the name had to be awesome so i was trying to figure out before really i started phoenix what the name would be and i had a i need to find like the evernote back when evernote was a thing of all the names but i was trying to find something that fit within the elixir ecosystem um i look into a bunch of like greek mythology names but they all were either taken or not great like hydra or there's a there's a bunch of names that like i didn't love but i found but they were already an open source project and then settled on phoenix which is kind of like a perfect fit for like the metaphor of the beam you've got this like bird that dies and is respond to real life again so it kind of played into process supervision and resilient systems so it was kind of a perfect name for the metaphor of kind of what the platform provides and it wasn't taken well i'm sorry it wasn't taken from anything irrelevant i think microsoft had some kind of phoenix compiler project and then firefox was also like there there were a couple things from like a couple decades prior that people on hacker news complained about but in general phoenix was an available name wasn't it also like jacqueline's idea jacqueline is his wife or she was she involved in the list yeah so she she helped me come up with names so i'd have to find her after we asked her if that was like her original idea or she definitely came up with names with me so no takers here yet so we'll continue online okay so let's go to for a tough one what was the most regrettable decision you made in phoenix or live view oh my goodness regrettable um that's a i don't know that's a good one so i think there's probably a number of small things i i think uh the whole i the whole thing around phoenix context was not regrettable i still think it was the correct decision but it was a long time a lot of work for i think to we've had some frustration from newcomers when they're suddenly forced with kind of new ideas and then so sometimes i feel like it please no one like experts are like why is phoenix prescribing the way i write this code and we're like the context generators are for beginners they're not for you and they're like yes but why are you prescribing the way to write my code and meanwhile some beginners are like why are you making this harder so i think that's not regrettable so i think it was the right call but i still think that's one of the more uh thankless didn't plays anyone um things that we've done outside of that i've been pretty happy with where we landed on on most things um i didn't quite think live view would be such a javascript intensive uh workflow for what i spent my time doing but that's kind of a necessary evil i think that that probably covers it cool so there is another one which is where i'll take this one quiz i believe where did the elixir name come from and somebody did a throw emoji so i don't have a very good answer for that the name was simply there and the fun thing like yeah it was like oh i'm going to call it oh elixir that was there i took a very pragmatic approach like oh it's relatively short uh it's the letter in the alphabet so if people are somebody's listing languages alphabetically it's going to come like relatively up close to our length as well same initial letter six letters so that was my so i was like let's go with this and the funny thing is that it understandably it led a lot of projects in the ecosystem to to take this like more as chris was saying like you know this more like mythological vibe like uh phoenix hydra and so on and and for a really long time i actually didn't see that so and so for example the build 2 is called mix which for me was always like about mixing like the code and compiling the code right but there is like a whole different understanding that people to say like oh it's related with mixology or something like that that i never saw from where it came from and then there is hex which i was like cool like it's a hexagon like hexadecimal right that's cool and it's like no hex is like cursing somebody like you can throw a hex and then i was like really so and then there is ecto as well which for me is it comes from the latin like the outer part like the ecto like ectoderm right so i was like oh this is cool right because um because acto is a layer around the database right so it makes total sense and then somebody's like nope it was named after the ghost from ghostbusters i'm like damn it so yeah um okay i'm going i'm jumping in and out here so chris what is missing in live view in order to release the 1.0 version probably a lot of stuff um so i'm trying to think of my like unloading my head a bunch of stuff we've recently talked about uh one so the programming model i feel like is very baked and in place for a long time now but i still think we have a lot to prove out so i we don't want to rush to a 100 and then be constantly breaking expectations of people so i think it's in a stable state and like how you would write a live view application but there's a couple big things one marliss's recent uh contributions have been huge um and that's kind of like just a starting point of we've got a html aware template engine but then going forward to like really take it to where our vision is of being able to have like off-the-shelf reusable components we definitely need some something along lines of slots to be able to have someone release a library and say like here's your tailwind table and then you can just say here's what i want to roll row to look like uh so slots is a big feature i think marloes has done a lot of interesting work around compile time checks that it wouldn't be required for 100 but that's currently kind of on our mind just as a developer ux experience um but outside of that there's a couple outstanding things that we kind of have to experience um in the wild like what it looks like to build a big live view application so i think one of the big missing things is a component live view messaging abstraction so if you've got this tree of components you can do a send update and you can send to a live view process but there's no shared abstraction for messaging sending things up and down uh component tree to live views themselves so i think that that would be kind of a requirement for me to figure out what that looks like and i think a lot of that will come from what people are actually building in the wild so that's definitely on our mind on the road map but i think before we land um on a 1-0 we'd have to have that kind of solved yeah sorry for the delay because i have to unmute in the bottom corner um okay so um i'm seeing what is next [Music] okay so this is a good question uh to both of us you go first chris uh how do you prioritize work open source and private life priorities help when you're getting paid to do open source so i'll say that the answer before like before i was being employed and able to balance my life out by working on phoenix during company time um it was much harder to prioritize things it was kind of helped by the fact that my wife was in residency so i had a lot of time uh without having to like sacrifice family time but it definitely uh is like a situation for burnout if you're just trying to like pull yourself into big open source projects um completely on your free time so i think how i'm able to balance is having companies like dockyard or now uh fly io actually pay me to mostly work on open source so it's a privileged position to be in but that definitely helps and how i actually prioritize features it's kind of it's pretty haphazard kind of depends on what either someone using phoenix and the wild needs or kind of our long-term road maps that we have i mean like phoenix presence or phoenix live view kind of just came out of us being like hey how would we solve this kind of thing or hey wouldn't it be crazy if we did this and then that turns into you know a couple years of work so i think that there's priorities that jose have in our shared collective brains or random notes um that exists they're roadmaps on the issues tracker but i think day to day it kind of depends on you know if someone opens a bug obviously that's higher priority or if i have time just to go heads down it's usually around some kind of live view feature these days but yeah the life stuff is probably the most important because if you burn out then you're not serving yourself or anyone in the community so i think it's important to definitely prioritize family and everything else above trying to code yeah i think there is one thing that chris and i have in common and uh we are really thankful for the companies we we work at and the companies work on is that for us like work and open source is pretty much the same thing so i think that's one of the things to keep in mind like when you see us being very productive you have to like doing a lot of public work remember that a lot of that's part of our work we of course have work things to do which is actually a good fallback like when i'm tired from open source i can just go and do the small part of my work that is actually the responsibility that i actually have to do and i can forget about the the rest eighty percent open source and i can still feel happy about it um but yeah that's that's a big advantage and um it's something that sometimes you know when if anybody here is maintaining your own projects is something to keep in mind and uh and there's a lot of discussions nowadays in the community not only the elixir community but in open source in general how to make it more sustainable and so on right so for us it's a big boost and and originally i struggled a lot with balancing um like private life and work uh but uh personally when i had kids it's kind of like you know it's kind of decided for you um so i got much better at that after i had kids uh i also joke like you know um as a brazilian live in poland where we have like very cold winters i was like well it's it's winter i'm going to go outside no i'm going to stay home and i'm going to work uh so like elixir was actually you know the both both the initial prototype and the version that became elixir earlier today they were both done during the winter so you get you get an idea about that yeah so okay chris do you talk to creators of other web frameworks who you drew inspiration from like rails or other web frameworks in general how does that go uh not like web server uh frameworks i'm trying to think if i've talked with with anyone directly um but i am in contact with open source um folks like um most recently uh caleb uh pariso the the um alpine js author and i uh have chatted several times about how he's solving um he creates creator of live wire it's like a live view like solution for a php uh laravel's spring framework uh so inaudible i'm trying to think if i've had significant conversations with uh server folks um not not directly i think um i've got an email from uh dhh um turning down my application in 2013 to apply uh 37 signals but that's the closest i've i've gotten to talk to another boyfriend rick author all right so sometimes i want to ask feedback uh on the questions but i don't think i can do that so somebody said can you tell us about the new graph shared on twitter did you share anything increase or is that for me that's gotta be for you i'm assuming the explorer so so a couple two days ago or three days ago i uh or maybe last week uh i shared the a so we recently started this effort for elixir for machine learning and i was trying to find like in none of the projects i had i had worked on or started i never had a mascot and and sometimes you get you know you get like envy right because some projects they have like very nice cute mascots like something i can bring for the kids at home so i was so when we were starting this like um the numerical elixir project i was trying to find a a mascot and then uh i literally went to i knew it was numerical elixir so i literally went to wikipedia uh animals starting with the letter n and uh i found this animal called numbat which you probably saw the log it's a very it's it's it's very specific to australia unfortunately it's uh threatened with with extinction they they think there's probably like about a thousand of them and i was like this is perfect right because it's like numb like numeric right no bad it's perfect so the next thing i did was to see if it's not an animal that's trying to kill people right especially being based in australia but he's actually very cute he's only eat termites so it became the logo and i have been teasing this thing for a while so all the logos they are built on top of the numbat and um yeah so all the projects that we do there is usually a logo related with it so it came with an x which is something like for working with matrices like multi-dimensional matrices called tensors and so on and then there was a live book project we had some presentations on so if you saw the live book logo it's a mixture of like this number thing i wish i could show but um hey chris do you do you have the nombat swag around you the actual uh stuffed animal the push toy hold on oh it was actually on my desk i think okay my wife will be working wow yeah so then we have the live book and the latest one the actual plush toy right the closest i have is that's the number yeah yeah uh it's i mean it's not an actual number it's a postcard of the number but yeah so the latest one was um it was so there was there's this new project that has already been announced it's on github um it started by chris granger and not sure he pronounced his last name correctly not chris mccord so it increases he's in australia and he started a project called explorer which is about so whoever's whoever has some familiarity with the python python ecosystem there is the pandas library right which is for data frames and what data frames are is basically imagine you want to work with like tabular data and make it very easy to rearrange the data select filter right that's kind of what it does so explore is the same idea brought to elixir and uh and they were like okay let's make it uh crazy is doing a great work and they're like okay let's bring this into into an x so we need a logo right and the name the name explorer is great because a lot of things that you do with data frame is actually because of tabular data is that you're exploring the data right so like okay let's think of the logo then my first idea because of explorer was to to give the uh the number like an indiana jones look like kind of giving a small hat and a whip but but the designer who works works on those things uh with us his javier he's actually if you've ever been to elixir conference in the united states he actually does all of the art for galaxy conference united states that's how i met him uh he's very wise because he never listens to my ideas uh when it comes to design and and then he said you know you're talking about exploration so what if we put the numbat in space so that was what the most recent tease was about so the explorer project um yeah and about data exploration and is the number that became a astronaut so it's pretty cool yeah all right let's go back to questions after start time [Music] okay let's go with a specific one chris um have you have you this may the answer to this one may be a no but have you seen what rails will do with uh um es6 http 2 import maps any plans to adopt the same approach or es build will stay for a while that's a good question so first of all i'm kind of jealous of the explorer logo because i'm a huge space nerd and before i named going back to the phoenix name for a second before i chose the phoenix name i tried to force a space name onto the framework because i loved space so much but like all the names were either already taken or like just kind of like too nerdy like i'm a big nerd but like pulsar like they were just like like too much um i couldn't find a good name so that's so now that like because i wanted like an awesome space logo so now a number in space is uh i'm jealous i need to put the phoenix in space some now um anyway that's an aside so uh yeah that's a good question so my first my first hot take of let's not require node at all um was actually to do http 2 import maps uh just script tags on the page uh we explored that initially and i think that's a i mean that's awesome because like it's back to the like early days of the web but it's not terrible because you're not doing like a ton of uh http requests um and blocking the page uh but what we ultimately landed on is you still it still doesn't take you very far because even if you're using http 2 you still have dozens of requests going to the server to fetch individual assets uh you don't get minification uh which is also a big change so i think that it's it's a great option for folks if they literally want no build step but i think es build being a portable go binary that should work five years from now is uh the next best thing so i think it's it's neat that rails also explored um really the same paths that we did um i think we just didn't think that the import maps would be a good default for folks that would actually grow with them like it's it works out of the box really well if all you're doing is serving like app css and app.js but the moment you add in a charting library add in you know all these other utilities you suddenly have a ton of javascript files being fetched so that's kind of the longer answer to that but i think it's a reasonable approach for for stuff with a very constrained um javascript and an asset story um and maybe this may be misremembering but isn't import maps still like fighting its way to have like proper browser part across everything does anybody know like you know it could be i mean i think ultimately even if it was well supported it wouldn't change our answer but if it's still not completely supported that's definitely a consideration too for folks but i think es build as far as it's staying power um the nice thing about it like i said is the fact that it's a portable go binary so like if it works for you today to bundle your css js it will work five years from now if you deploy an app today so i i think it's less about like you know webpack three when we first shipped webpack it worked you know we could say oh webpack three works today but then we couldn't say five years when you revisit your code base that that's gonna work at all um and actually it won't that's what we've seen so i think that the es build story is like even if we were to say like you just built as abandoned five years from now there's something better uh literally like a pre-compiled go binary is just gonna spin up do the thing that it did years prior so i think there's a much better long-term story there even if es build were to fall out of favor like our whole goal is like long-term maintainability for applications that you start and continue in the future yeah and i don't know has anybody tried already the new phoenix stuff with yes build please raise your hands um about a dozen hands up maybe a bit more so the cool thing about yes build for those who tried is that like if you don't have yes build from your machine it just goes and download it and put it under the underscore build directory and you don't have to do anything else right which is just for the getting started experience regardless if you're new to phoenix or an existing project it's just so refreshing right because they're not telling like hey you should go there figure out how to install node in your system figure out how to install npm and then do the npm install right it's just like no the version was declared somewhere we're just going to go and fetch it as if it was like kind of an elixir package and i think this is a um a really big deal and ties in really nicely like what chris is saying right should still work in five years right and yeah in five years uh we will most likely still have internet we can just go and grab that thing and put it in the proper place okay right so now i'll go with a question that um that left me very disappointed i'm kidding uh but it is what thing in elixir or phoenix frustrates you but isn't top priority so you decide to leave it be it's like come on man we're working hard uh chris you go first oh man so frustrates me but not top priority oh there's a lot of i'm trying to think like there's actually not that many but i'm sure there are like i'm sure we've had a bunch of conversations um like jose's number one like he has a lot of good sayings but one of his great sayings is like the ship has sailed on that so there's a lot of things that we're like oh we should do this or we should have done this and he's like nope ship is sales 1.0 um so i'm trying to think if there's like any big things we would have changed i mean i think one thing that we've done a better job on and by we it's really jose pushing pushing this side but i think one thing we did a poor job of was compile time um dependencies initially with like route helpers and importing things into um the user's module space by default with the new project where in retrospect that introduced a bunch of like compiler overhead so i think jose and the core team have done a lot of work recently about how to optimize compile times and do checks for people's applications to make sure they're not introducing a bunch of compiler dependencies um and i think it's been several years now that we've added a route alias instead of importing the helper so i think over the years we've gotten better in that regard but i think going back that's one of the things that we could have avoided very easily just on the way that we generated the project code i'm trying to think of like apis that that we have like slated for phoenix 20 which isn't there's no road map for um but i can't i can't think at the moment um jose maybe you can jog my memory anything that annoys us i think most frustrations we do solve them as they come and uh and and i think there are two things that is worth talking about i think like a lot of the things they may be frustrating and there are alternatives but it's not clear if the alternative is any better right so it's a balancing of trade-offs so if you have something that is done the way it is today and there is an alternative but you can't really say that that alternative is really going to be better then there is the question of like you know if it was an early language you could say like you know let's try but now you have to balance like hey is it worth putting all of our users through the the hoop of like trying those different things even if it's not better and there is actually a good example for this which is related to application configuration so um you know you configure your phoenix and elixir applications with the config files and there was a period we tried to and we learned a lot of lessons with this process and there was a period where we actually tried to take most of the configuration from the config files and put inside correlated collocated with like so if you wanted to configure the phoenix endpoint you would put all the configuration in the phoenix endpoint or if you wanted to config the repo you would put that configuration with the repo so we wanted to make the config files leaner right so we thought like hey this is the way to go and then when we try the new approach then people are like this is not good because i want to configure my app and and i don't know what i can configure because the configuration is now is scattered about on like 10 or 12 different files and this is very hard to follow so um sometimes i think it's just an example like you know if something is a clear winner i think like we'll just like let's go and do it so but a lot of the times it's really unclear if it's if it's the winner and there are other times where there are things restraining so chris is bringing up like uh compilation times which is something that people have say hey you know it's not the compilation time that is bad it's actually that when you do a change uh a lot ends up being recompiling right and there was a lot of progress in the recent elixir releases and the next elixir release is going to be even better so when you change a file like uh fewer things are recompiled but the things like if it's it like i couldn't do the improvements that i we are done for alex 0.13 a like three years ago and the reason why we couldn't do it is just because um it's just it's mostly because it was for saying but we just didn't know exactly how to fix that problem and sometimes you fix another problem and then you realize that oh that thing that we added there can now help us solve this other thing so there's a lot of development that is like kind of cross-related so you know but i think my joke i said like you know this is a about the question exactly that you know like if there is something that we think it's restraining i think um we we we just go and try to if we can address it we will definitely try to address if there's a clear way forward then i think that's that's good and we jump on it i think the other thing i'll add there is the phoenix presence the it's frustrating for us but not i mean most all users it isn't a problem for but the fact that we implemented uh an or swat crdt uh for that which has like a pretty expensive operation when you merge data from different replicas like the fact like it wasn't until we had built the whole thing that we realized that we could have um cut out an expensive part of the operation we didn't need to implement like the full part of the crdt uh just because there was a like like once you solve the complete problem you actually realize is like what the complete problem is so i think the i initially made the error of not understanding that like the replicas own all their data so there's a lot there's a conflict resolution step that doesn't need to happen when we merge presence data that would probably drastically speed up uh phoenix presence so it's frustrating to me that it's not something that like that we can prioritize like immediately right now and it's also good enough for most folks like people are running a hundred thousand concurrent um users through presence um today so like it still scales super well but it is frustrating that like uh if these companies that are using it at really really high scale running into slow downs it's something that that we would like to revisit so it's frustrating in that respect but it's also you know hard to prioritize because it works super well already so i think stay tuned on that but that's something else that comes to mind cool cool so um there was a question here so chris how do you feel about dsl's design for test purposes i'd have to see the specific example uh i think dsl is like it's coming from me this is probably this is actually yeah so coming coming from a former creator it's easy for me to say all right i can be like most dsls are not are not worth it but that's coming from someone who gets to write dsls so i i would need to see a specific example i think dsls can be powerful and it depends why by what folks mean by dsl like is the phoenix contest or live you tested dsl where you can just say like get this url or assert uh something was broadcasted i wouldn't consider that necessarily dsl but if you go fully the other direction where it's like all all you do is use macros to have a declarative test for everything you're not actually writing elixir that's more using test utilities i think that is is usually more restrictive than necessary but i can only speak in the abstract so i would need to see like an actual example but i think dsls in general are very powerful but you got to be careful because the moment you want to do something um more broad usually it's it's doesn't well serve you yeah what does the audience think about uh test-based dsls it's definitely a polemic topic like when i want to try a show of hands like who is in favor thinks it can really be a boost for productivity is there anybody okay very few hence a couple and who is like nope i'm not touching it no way very extreme the other side okay so and who is like sure if it's well designed why not okay so yeah um yeah i think one of the i'm going to say one thing about dsls uh it is a funny question to ask like somebody one day was asking me um what do i think about not invented the hair syndrome and i was like yeah don't ask me that um you created a programming language like it's you know it's and then you're talking like hey you know like you create a web framework what do you think about the sales it's going to be a bit biased um but i think that the main thing about the sls that i learned throughout the years is um is that the dsl should always be a layer on top of a declarative on top of a proper functional usable api like the huge majority of the times like there are some cases there where it's just five for it to not be but in a lot of the cases that's what you should you should aim for like the building blocks for the dsl should always be exposed that is going to help your dsl to be cleaner and it's going to be easier to test it's going to be easier to extend only good things are going to to come out of it and a very curious uh tidbit actually my first talk in english ever was at aruco that was happening in krakow and the title of the talk was dsl or no dsl so that's uh uh you know and exploring different approaches we had in the ruby community at the time and some that was very dsl-based some that were not a lot dsl base and the pros and cons and i remember being very glad because matt said he liked my talk so that was cool uh i'll add to that real quick jose the your comment about uh the dsl also having a functional api is actually um i think extremely important and plug is a great example of that in um just like one thing from two days ago so fly fios playing with elixir um they're really excited about it obviously because they they they hired me but one of the fun things is like i get to live vicariously through uh them discovering elixir and things they can do with phoenix and live view but this plug example is perfect because uh they wanted like they're playing with licks and they're like oh my gosh we let's deploy something and get this serving our users and one example was they brought the there's a reverse proxy plug that exists on hex that can take uh requests and then do a reverse proxy so they wanted to say like what if we could just carve out this part of our stack and serve it with um with phoenix and the reverse epoxy plug did like 95 of what they needed but they they were like uh we needed to say like uh for this special circumstance we needed to um behave differently and i think in most other platforms they were like well this isn't gonna work and i gave them like a six line of code snippet which was just their own plug that just did the check and then called you know reverse proxy plug that call and pass the the connection in with their options so i think that was just one example recently where the dsl abstraction had like a very obvious answer that like in retrospect like it blew people's minds like oh i could just call the code but i think most uh other ecosystems yeah it would just be a dsl that would kind of be untouchable as far as user land is concerned yeah i think i think in our conversation something that comes up a lot related to to dsls or because you know phoenix is actually the phoenix core let's say it's a bunch of packages like phoenix you know phoenix html phoenix live view and one of the things that we talk a lot is also like no cheating and what we mean by that is like phoenix live view even for it's like this is the same people are working on phoenix live view are using phoenix we are not allowed to use any private apis or any specific dsls or things like so everything that we need uh we'll go and we'll make it public and figure out the proper way of doing it in phoenix exactly i think the no cheating is good for many reasons i think it can be a good sign of a healthy ecosystem because if somebody wants to like hey i actually have a similar idea to live view and i want to try a different approach like all the abstractions are going to be there right they're not going to they're not going to rely on the hacks if we have done gone that route and also again in terms of the api being clear and uh and being being readable yeah um i'm going to read the next question um [Music] there was one i'm not find it i'm going to paraphrase it which is oh what the community can do better to improve the growth of elixir and phoenix help watch dogs blog posts contributions on github chris yeah i mean this is a great question i think that like we have conversations around this the community as in we have conversations you know every year like how how can we do better how can we grow uh i think you know if evangelizing continues to be a good thing so i think depending on like whether you want to do open source contributions or you don't have time to you know ship a bunch of code but you can evangelize in your company train people um i think those like there's a book that jose co-authored adopting elixir uh if you're interested on how to actually get elixir into a company uh so i think that there's that side of things um and then on the actual open source side of things i think what people don't realize about open source is like they're shockingly small there's a shockingly small amount of contributors building the tools that you use every day whether it's the language the web framework or whatever library your little utility library you're using and um my personal experience is a lot of people want to get involved with docs or code but don't even though they're like just like they tell me like tell me how i can get involved and then i tell them like get involved find us on slack uh follow the issue tracker so i think in general people feel like they need to have permission to get involved and even when they're given permission i still feel like they don't feel like they're like worthy of of contributing but uh i will say that like yeah shockingly few people are actually become contributors and i'd love to see that change i don't know what the right answer is other than to tell people that like even small contributions um that's usually the best way to get started but make a big difference um for projects so i think like if you want to get involved this is something that you're passionate about like find the maintainers on slack and and literally just jump in uh is the best way to do it so i think that i would love to see the community um getting more involved on you know pull requests and documentation i think we do a good job but in general i think there's still small amount of contributors to where to what i hear from people telling me like oh i'd love to help out i always like to say uh go with your pains right like so if you are feeling any pain at your work like in the sense of like oh this there's something that is not clear or we are missing this thing to make our life easier because in my previous ecosystem we had a two that could do that and now this two is not available here and maybe we could have it too i like to say like always go over pains or if you solved a challenge or solve a problem that was not clear to you uh you can go and write a blog post about it how you did that and how you attacked that and how you tackled it and i like to say there is like no like there is no small contributions i talk to a lot of people where they're like oh we did this and then i'm like oh you should write a blog post about it and then like no i think that's like too small or easy or like obvious you know like oh after we talk a lot about this like after i found out the solutions was really easy right and i was like yes the hard part is finding out the solution right so you know all those things they definitely help right like just writing writing about we are doing uh contributions small things in the docs and then to the other areas that chris was talking about uh the code level and so on so uh going with you know going back to the frustrations questions right going with what is restraining you can be a good way to go about it how much time do we have is it it goes into when okay so we have like 13 minutes about okay so there is a question i wanted to leave at the end but i'm not sure if i'm going to time it correctly so i'll just go ahead and ask it now uh what is on there there were three or four questions about elixir and phoenix roadmap so i'm going to try to consolidate all on this one so chris what is the long term for uh for phoenix long term is one year plus one year plus uh so i mean it's probably not a surprise to folks that live view remains at least my immediate focus uh i think you know phoenix if you're building um json apis or graphical apis like there's the answer there that that's baked um that's not going to change um so i think as far as my focus live view and how to build um distributed applications around live view will be my immediate media focus so i think that that's not a surprise to folks we talked about kind of what we want to see in live view before 1-0 so i think that's kind of been well trotted out but i think the me joining fly i o one thing that i want to start really focusing on is what does it look like to run a distributed elixir application with live view running you know geographically by users so there's a lot of interesting problems there around uh if you've got data across the ocean you you know how do you fetch that efficiently and what kind of patterns exist to build an app that way um and i think one of the really interesting things that sounds crazy is like you could even do kind of like server optimistic ui on the server uh with this kind of setup so there's a lot of really neat ideas that i think will sound um really uh really like bad ideas to people just like when they first saw live view they're like this can't be good uh so i think there are some cool things that i'm interested to try kind of in the near term that i think will actually prove out to be pretty interesting solutions yeah so for elixir um some i don't know when it was in election conference united states the last one we had before the covet break my my talk was about how elixir we have a empty backlog it doesn't mean it doesn't mean that we're no longer working on it and you can see right like there's still that was when one line come out and we are heading towards 1.13 but what an empty backlog means is that you know it's like now we're there are no big features planned we'll just continue evolving the language based on feedback based on frustrations for example that we hear people and that's how elixir has been has been going for i would say since then in terms of release right we are doing improvements we are improving compilation times right which are pains that you know you only hear from people that are you know after they're working on a project for a while and they're like hey you know we are running to this case and um we wish it could be faster so that has been our focus uh so no there is no nothing really flashy to talk about uh elixir 1.3 on 1.13 in particular is going to have two main things that uh i think affect developers all indirectly so one is improvement to the compilation times we talked a couple a little bit about and the other one is we are starting to add some functions to understand a fragment of code right and the reason why this is important is because if like if you're working if everybody here is using an editor or or at least an editor and some are using an id with advanced features like auto completion suggestions kind of things and the tricky thing about those tools is that they often look at they are they often need to work with incomplete elixir code or elixir code that is wrong like imagine that you are typing some code and then you type one plus that one plus until you write what is after the plus that is incomplete code right like that does not compile elixir but the editor needs to be smart enough to say hey this is an incomplete elixir code but the user wants a suggestion anyway so there has been a great fort from like people working on on edit or tooling the elixir language server protocol elixir sense and now with live book having you know having its editor and giving suggestions to user about auto completion and so on we are focusing focusing on bringing this uh this functionality to the language so the ecosystem can build on top right so you get a feeling of where we are going with elixir it's really no we're just like it's polishing right we are polishing everything that is in there and continue improving um which aligns well with the language goals right because the language goal is to be extensible like everybody should be able to get the language and build a web framework uh build a uh something like nerves and more recently something for machine learning without really changing the language so not really a lot uh changing on elixir and then there is a question uh still related to roadmap i'll go first chris and then you you tied up which is like uh if there is anything that we want to remove for 2.0 so um for elixir i can say that we will have a 2.0 at some point but it's i it's not coming anytime soon so with time you probably saw deprecations in your elixir code and in the past were as the language was evolving we were much more aggressive about the pertaining apis but now things have stabilized considerably so my plan for elixir 2.0 is that if you run like so imagine that we are going to release elixir 2.0 when elixir is like 1.40 or something like that right like in 10 years from now or something like that my idea is that if you can run 1.40 without uh warnings uh elixir 2 is going to work just work you don't have to do anything right so the idea is that everything that we want to remove is going to be deprecated so uh alexir2.oh is just like we are tired of carrying those deprecations and uh we will say like okay let's let's flip right and i have some ideas about making this release move even now like we could have like some kind of future flag that you pass to elixir and then it it it kind of disables the deprecated functionality so you get actual crashes and things like that so we can all be super prepared and the transition is as smooth as it can be uh as never seen before let's say and yeah and chris um anything you you think any plans virtuo anything that you you think like should wait virtuo or something like that not in the immediate future like i'm just looking through what we have tagged in the phoenix codebase for v2 um and it's like nothing feature-wise like just really small things like uh people remember when uh poison was kind of the default jason uh decoder like there's a bunch of little things like historically where you know j the jason package came around and we replaced poison with jason for new projects um but the phoenix we didn't want to break other people using poison so that there's a call out that like eventually will remove this default poison um jason decoder in phoenix even though most people today aren't using poison um a little bunch of small things like that we also supported like the system tuple before runtime config was solved uh you could do like i want to fetch this system uh port uh export uh environment variable so like those kind of like little things we want to remove uh now that we have like you know we experienced the issue uh we came up with a solution uh in phoenix uh or elixir and now like those are kind of just crushed but they're like really small things um one of the bigger ones um that we have called out i just uh now that i thought like i just pretty sure everything real quick is like we want to remove a bunch of we uh the code injection that we do so it turns out like when you're injecting code and it looks like you know you learn lessons over time and one of the things that we do like if you want to use phoenix controller is we import the plug.con api so there's a lot of things that in retrospect we shouldn't have automatically imported things into user code because to understand what's being like when you say use phoenix controller you have to actually go look at the source to find out what code is being brought in so when b2 comes around i think uh we would remove that import by default and um you know we could even add it into like your web ex file to like you so you see what's what's being brought in uh at least so i think even the upgrade pack there lucky out of the box technically everyone's controllers would break but it would probably be a one-line change to say like oh i'm i imported in my user land code not phoenix doing it so i think that's one of the bigger things but really it's a very small change so i don't think any apis at the moment are subject to like big changes yeah because um because we say like hey you want to know everything that is in your controller you can look at the wii u x file but yeah then the use phoenix controller is actually importing a couple of things so there are some things behind the scenes but i'm thinking we could already start importing plug con today and nothing would break do we already do that i don't think so so that actually would be a great idea maybe 160 goes final you'll be future proof as far as that yeah so if somebody wants to send up a request you can make it so we change the new app generator to import plug home in the dev controller for web ex and that's going to prepare everybody for phoenix 20 coming 15 years from now cool do you have time for my questions do i get it okay um all right chris what is in your opinion the top three anti-patterns that we developers apply when we use phoenix and we should stop top three this is tough uh one i think so that can work together all these answers for me we can work together i'll i'll start with one so one that we see developers doing uh from time to time not necessarily specific for phoenix but it happens in phoenix applications is is starting processes when they should not like using processes as a mechanism for design like oh you know i need to i'm going to create this process here decision server to to model my interactions with the users like no like you know the process they're not a design tool they're not a code organization tool and i think i think it's natural to be clear like you are learning a new language a new paradigm and then like hey how things fit together and um and i one important thing is that processes they are not for code organization process they exist to model runtime properties of our system bitcoin currency estate resilience to failures but is not for call organization so that's one can you think of oh yeah so the the big one for me this is gonna sound really rich coming from me uh but overuse of macros so someone wrote a book that told people to use a bunch of macros which i still stand by that if you're learning macros absolutely go uh go all out but i think that people tend to um like working at a consultancy inheriting code that people i think they really want to use macros because they find them interesting they're like oh i can solve this um but the vast vast majority of the time on inherited code that i've encountered like it could have just been a function call so i think that macros in general are like i think you should start with this is an anti-pattern if you're if your answer is oh i need to write a macro for this uh start with the assumption that you're wrong uh and then prove to yourself that you actually need it so i think that's that's an obvious one along the process um point that jose mentioned using processes for code organization is poor design also using umbrella applications for code organization is usually an anti-pattern i like to say that like umbrella applications should be um like you should have a separate application along the order of um how you want to actually um deploy an application um it could all be deployed in the same vm but like if you want to say like i have this application that might be doing heavy cpu intensive work so when i you know i do it as a mono repo but when i deploy it i put it on a node over here and it runs on its own that way it can do cpu intensive work and not you know slow down web requests so i think what we see folks doing instead a lot of the time is making a separate umbrella app when really they just wanted like a lib separate lib directory for just code organization purposes that's a big one that comes to mind yeah and the cool thing is that i think all those things that we talked about they are in the docs uh so the docs i mean i don't i don't i don't want to feel like oh you should have read the docs that's not what i mean it's just that um um because there are a lot of dogs um so you know but if you get to stomach them it's like it's advice that we do give like hey don't use this for that so there is a there is a a page in the lecture documentation called library guidelines if you haven't checked that out you can google it elixir library guidelines it's in our docs that have a bunch of like like hey don't do this don't do this don't do this a bunch of small ones one of the one of these small ones that i see people committing from time to time and it's very easy to remember is this is very small compared to the other things we're talking about but is if we use task sync you must await okay that's something you have to keep in mind because it is designed for somebody eventually receiving a response of that thing and then if you just want to uh start a fire and forget task then you can look for the module and the other apis in that module but if you do a task i think uh you must wait um now that we saw those things has anybody going back home thinking i have homework to do no good very good i have one i have one more okay uh this one ask three and five try to collect okay yeah i try to collect like i don't know the right way to phrase it but i think along the process idea i think people coming from other platforms this whole idea of preemptive scheduler um with green threads is very new for a lot of people at least it was for me so what we see people do is they come from a language that either has no real concurrency primitives or very poor threading or just threading and they think that they need to like slice up the work granularly themselves uh which leads to a poor scaling solution so like one example is a doctor we inherited an application that did a bunch of external api calls and then based on results inserted into a database and we had a indexing task that took six days when we got the app and we just refactored the code to run in six hours same postgres database uh just using proper process primitives so i think people come from a language where they just throw things into like a sidekick or redis job queue and then uh they're used to thinking like well i can't block the the quote-unquote app because i'm either blocking the web request thread or i throw it into a worker but then i only have let's say 16 threads running workers at one time so i can't just allow that thread worker to block let's say for 30 seconds to do a big job i need to time slice that myself too so they come to elixir and they think like oh i get cheap concurrency so i'm going to start a process to make this one http request i'm going to start a process and then when that's done i'm going to start another process to go do something else and they're they're doing going too granularly if that makes sense it's hard to explain but what we did when we refactored the code base is like no we just start a process to do a unit of a work um and then you can make concurrent http requests within that process but instead of thinking about this idea of like every async operation has got to be like some quote-unquote job and then you have to kind of coordinate um i think i see folks breaking things down too much in the job queue idea versus start a process to do a unit of work that should potentially do other things starting the process that linked to them if that makes any sense so using processes as a job queue is an anti-pattern that i see quite often cool and i'll do the last one chris what are the biggest improvements you'd personally like to see in the elixir ecosystem i think we do a fantastic job i'm trying to think of like so like jose said everything a lot of things are typically frustration based so there's nothing that really bothers me day to day that i wish uh would change because if that happens like i mean like i said all my answer is like i have a very privileged position like if something frustrates me i either can improve it in phoenix because i control that or i bug jose because he and i collaborate so most things that i personally want to see happen to happen um so i'm trying to think if there's there's anything large i mean i think one thing if people that know me uh like backyard folks i i very much complain about uh dialyzer quite a bit um i think that it's powerful but i would i would love to see um less pain in kind of the um static analysis side of things for folks that want that um because personally for me anytime dialyzer if i'm forced to use it i will use it but any time it's pushed on me it's more pain then it adds more pain and value to me so that's probably my biggest frustration um on projects i'm just being forced to live through that pain where i see the value in an idealized world but i don't get the value in reality so i think that could be improved who here wishes elixir was a little okay who here issue wishes that elixir was a lot more statically typed please raise your hands okay a little bit more and who thinks like no types please stop okay cool so uh at least half would be on a little bit more and i think like a little bit more side what i didn't want to i would say a little bit more would would be good yeah i didn't want to go down the static type uh wormhole there but yeah i mean i think i'm a big dynamic type fan but if the computer can tell me i'm wrong i just realized run time then yeah great i just realized the order as the questions can also be totally biased right so i'll do it again i'll reverse the order and see if anything change okay so who is like no types please raise your hands it's three options okay who'd like a little bit more but like don't go for crazy on it okay and who's like yes turn it all in okay you're raising true it doesn't count man cool cool yeah so um for me when it comes to what i would like to see in the ecosystem my answer if anybody's has asked me this question you you know what my answer is going to be and it's like uh my opinion is i think my opinion is not very relevant in the sense that it should like what the community wants next or the ecosystem thinks what needs to be next like it's up for the ecosystem to decide and the reason why i say this is because uh if it depends on me we would not have a lot of the great things that uh we have in the ecosystem today so for example even phoenix so who is started um we started uh in elixir very early on did anybody who started elixir before 1.0 came out okay very few hands uh right so before in the very early days when phoenix was coming out like there were a lot of web frameworks trying to be a web framework and bringing ideas from rails and other places but for me like the the thing that i really liked about phoenix and the craze and what craze did it was exactly because i was like hey you know it's not it's not thinking about like hey can we be like jungle on elixir or can we be rails and leaks it's like no like it's real time right it's like it's you know it's saying look we have this platform platform that is fantastic for this and it's really thinking it's like it's flipping the problem in its head right it's not like hey how can we bring the other things that's not the question we should ask the question is how can we use the platform to build other things right so i think that's what i found fantastic and it's an idea that i would uh never have had even coming from this web development background and similarly with things like nerves right if somebody say like hey what would be great for elixir i would never answer um nerves something for building embedded software right and and then we have a bunch of other examples like membrane and so on so um yeah i think i think um like the the next big ideas um they are not coming from us they are coming from you so you know um go for it cool i think this is it so what do i do now [Applause] [Music] [Applause] you

Channel: Code Sync

Views: 1,906

Rating: 5 out of 5

Keywords:

Id: _Bnhwv9JLzs

Length: 65min 27sec (3927 seconds)

Published: Fri Sep 17 2021