Gradually gradually typing Elixir

Welcome to changelog and friends, a weekly talk show about the knife and the cheese. Today we're joined by elixir creator Jose Valin. Thanks to our partners at fly .io. Launch your app near your users. Learn more at fly .io. Okay, let's talk. Ooh, you've been on six of our episodes. Six. This is gonna be episode seven. We should do a most frequent guest thing. When did you start? Like the show? The changelog started in 2009. Oh, officially. Okay. But it had some fits and starts. I started in 2013. And I think you've been on since then. Yeah, it was not before then. It wasn't before then. Your first appearance was 2016 and was about elixir most likely elixir and the future of Phoenix. I think we actually had. Well, it was just you. Oh, what's that? So now we're just doing the show. Welcome. It's changelog and friends. So our story with elixir started with Chris McCord, not with you. Did you know that? How unacceptable. All right. So you call Chris and he comes on the show. Yeah, that's pretty much what happened. So Phoenix dropped and I'm a web developer. So I'm interested. And I was a long time Ruby on rails. I knew who you were and I use device and stuff. And so it wasn't like I was unaware of yourself. We just hadn't met. And when Phoenix made a splash, I was like, we should do a show on Phoenix. And Adam said yes. And so we invited Chris McCord on and we did a show about Phoenix and elixir from his perspective. And I was sold enough to give it a try because he was very convincing. And I ended up liking it quite a bit. Did a quick, not a demo app, but like a very small, like single endpoint. I think like a Slack inviter kind of thing where do the whole Slack invite thing for us. When somebody joined a channel, I can't remember what it was, but it's like a really quick one file Phoenix app that I could deploy and it worked. And I was like, this is cool. So that got us going on Phoenix. And then we invited you on for the deep dive on elixir. And that was in February of 2016. And then a few months later we had you and Chris on together. That's probably the one you're thinking about. Oh yeah. That's the first one I remember. Yeah. Ecto two and Phoenix presence. That was in June of 2016. So it was literally four months after the first one. So we just, we're kind of hooked there. And now this is your seventh time on the show. What's interesting though about his very first appearance with us, the elixir and the future of Phoenix episode, episode one nine four 70 ,000 listens. And that's what we tracked, which is like not inclusive of Spotify, which I guess since it's that old, maybe it doesn't have a lot in the external ecosystems. We're not pulling into our internal stats. So that's 70 ,000 internal stats listens. That's a pretty big show. You know what, like speaking about numbers, I think the tweet that we are going to talk about today on the show about types, I think it was my most popular tweet ever. It was like, yeah. I mean, I don't keep track of everything, but I can remember. Sure. Last time I checked, it was 160 ,000 views. I don't think I've ever crossed that. Why do you think that happened? I mean, I get, I don't know. Like it's elixir and types, right? So I knew it was, maybe we should talk about what the tweet is. Yes. Fill the tweet or the X or whatever it is. You want to read it? You want to read the tweet? Cause this is something we do now. We have people read their tweets. I only have Twitter on my phone and I keep it locked under trickies or something like that. If you have it, but otherwise I can quote it from memory. Yeah. I don't have it. You please do. You'll do better than me. So it's basically announcing that elixir is now officially a gradually type language. And it had a screenshot from some very small snippet of elixir code where we were finding a type violation because you had a variable that was declared to be an integer in some place and then declared to be a binary or something like that, all inside the same binary pattern. They're like, oh, this thing cannot possibly be an integer and a binary at the same time. And I kind of knew that it was going to like, it was probably going to like a lot of people are going to like it and it was going to go out. Right. So what I did is that I, of course I did the tweet with like the main headline and then I added a bunch, I started a small thread and I added more context. Right. And then later I realized that so, so people were, they were asking me questions. I was like, Hey, that is in the thread. And they're like, oh, it's because I don't have a Twitter account. And now Twitter doesn't show you the whole thread with all the context. Right. And the context is important because if somebody is expecting elixir to be like fully gradually type right now, it's not. It's not. Yeah. We've begun to work and we should probably talk about that, but it's just the beginning. Yeah. You do say officially though. So that may be the misnomer on the assumption because the context in the tweets that they can't read because on Twitter slash X is hidden behind you saying, I'll read it for you. It says tomorrow marks 13 years since the first commit to the elixir repo. And today we celebrate by announcing that elixir is officially a gradually typed language and then the screenshot and that's got 177 ,000 point eight views on it and almost 600 retweets reposts 2 .2 K likes slash hearts and almost 200 bookmarks on that too. So it's a little bit fake newsy, isn't it Jose? No, it is. It is official, right? It's because, so let's go a little bit into it, right? So what does it mean, right? What does it mean that elixir is officially gradually typed, right? So before that, before that tweet, let's say elixir was a dynamically typed language. And one of the ways that you can think of a dynamically typed language is that it's a statically typed language between quotes, right? Where all the functions, all the inputs are dynamic and then it returns dynamic, right? So everything that you receive is dynamic. Everything returns dynamic and dynamic means I don't know what is the type at compile time. I know at runtime. So if I try to do, I try to add the number to a list, which is not possible in most programming languages, right? You are supposed to, in elixir you're going to get an error at runtime, but if you had a static type system, you could potentially catch that error at compilation time, right? So elixir was a dynamically typed language and being a gradually typed language means that you have the dynamic, but at the same time you have the dynamic, you can also have precise type information. So what the tweet was saying is that, well, instead of elixir now seeing all the variables, all of your inputs as dynamic, now we are doing inference on your patterns and guards, which are very common elixir code. So in your pattern, you can say, oh, I'm going to match on the list. You can use a guard to say, oh, this thing is a number or an integer. We are getting that information to say, oh, so now I know that this variable is no longer dynamic and it's actually an integer and it's a list. And now that we are mixing this dynamic world with this little bit of type information, right, now it's officially gradually typed and that's cracked, but it's more like it's officially gradually typed, but we are at 1 % of the journey. That's what the following tweets, they meant to say. So if you think about everything you can do in a pattern and in a guard and elixir, you can check if it's an integer, if it's a function, you can better match on maps, on tuples, on lists. We only understand one construct right now, which is the binary matching and the binary construction. So of all the things in the language, we understand one of them,

but

getting to this one is super, super hard, right? It's like literally two years of research have passed. So getting to this one was like super, super hard. Now getting to the next 10 is not going to be as hard, but yeah, we are officially gradually typed, but it's like we are 1 % gradually typed, if that makes sense. It does. That's why you had to add those additional context thread tweets. That people can't read and the ones who can won't read. Right. Exactly. But that is how you generate more and more buzz as people continue to engage with you on the thread. So that explains some of the excitement. That's the adage too of work in public. That's what this is, right? This is working in public. This is showcasing something that you've been working on for a couple of years, not research wise and saying, hey, officially yes, but 1 % on the journey. Yeah. And it's funny because, so just to put things in perspective, it's 1 % of the first milestones and we have declared, it may change, but we have declared that we are going to have three milestones in this, right? So what are our milestones? Well, actually, so we did a bunch of research already, and then we can go into these. We have published articles. I have given talks. We have done a bunch of research. And by we, I mean Giuseppe Castagna, which is the senior researcher, and Guillaume Dubac, the PhD student who have been working on this. There is a paper with our names and my name is the last one deservedly because I've did the smallest part of the work there, right? So when I say we, I mean, not me, pretty much them. So we did all this research and our idea for the implementation, which is what we have started, is that we're three milestones. And the first milestone is that we are going to look at all your patterns, all the guards, get information about them and use that information inside the function, inside the program to catch obvious typing errors, right? So the idea here is that, so I like to say even before I started thinking about typing that Elixir is an assertive language because you usually, even before we don't have types, we actually kind of know what we are working with. We know if it's a struct, we know it's a list. That information is there in the program. So the idea is, what if we can leverage this information that is there in the program and use that to find bugs? And we are going to do that without changing the language, like the language surface for the developer. And then we can use that to give it a try on the type system, make sure that it's going to be fast, make sure we're going to have good error messages. So our first milestone is meant to be like, you can't disagree with it. It's kind of like, it should be a win -win situation for everybody. If you're worried about type systems or you don't like about type systems, like, hey, we are going to find bugs for free. You don't have to change your code. You don't have to write types. You're just going to find bugs for free. If you like type system, it's one step to what you may perceive as the right direction to go to. So that should be like a win -win situation. It should please everybody. If it does not please everybody, it's probably because we did something wrong and we may be in the wrong direction. So that's the first milestone and we did 1 % of it. And then the second milestone is to actually start changing the language to introduce some idea of types, mainly around like data structure. So when you define a struct in Elixir, you may want to say, oh, I have a user struct where the name is going to be a string, the age is going to be an integer, and you can have more precise information around data. And then the third milestone would be, well, we are now 100 % gradually typed and you can also provide your own type signatures if you want to. So it's like we have been researching for two years. We were able to move out of research and there are still those very large milestones for us to go through. So one of the things I tell people a lot, like I'm not asking anything from anybody except patience. Let's be patient. We are being very careful about these. It's like we are thinking each step after the other. We are not trying to rush it. So we'll see where to go. And the usual disclaimer I give people is that these can still fail. It doesn't mean that Elixir is going to be 100 % gradually typed. It may be, oh, something did not work out. We will give up. Maybe we can only do milestone one and we are not happy with milestone two and three. And then that's what we'll have at the end. What's up, friends? This episode of Teams Talking Friends is brought to you by our friends at Vercel. And I'm here with Lee Robinson, AKA Lee Rob, VP Product over at Vercel. So, Lee, let's talk about Vercel's front end cloud. I know Vercel supports over 35 frameworks, but the question I often hear is, is the happy path on Vercel Next .js? Are you optimizing the best experience, the sugar on top, so to speak, for those using Next .js?

Yeah, it's a great question because, of course, we're biased because we make Next .js that we really like Next .js. But the idea behind the front end cloud and the idea behind a concept we call framework defined infrastructure is that we want to make it as easy as possible for you to write code in the frameworks that you prefer and still get to take advantage of all of the cloud infrastructure primitives and the developer experience platform that Vercel provides in that same model. So, tangibly, this framework defined infrastructure concept means that I write code in my framework native way, and Vercel is going to do the heavy lifting of transforming that into managed infrastructure. So, in Next .js or in Nuxt or in SvelteKit or Remix or all of these frameworks that we support through framework defined infrastructure, I'll write my code in their framework API. So, I want to do server -side rendering. Great. I'll do it through their conventions. When I deploy to Vercel, our platform is going to transform that code to work with our managed infrastructure that's very scalable and also flexible for what developers need.

Okay. So, help me break down what you mean when you say the front end cloud. I get Vercel, front end, front end frameworks, all that good stuff, but break that down for me. What exactly is the front end cloud?

We believe that there should be tools designed and built by and for front end developers. We want to have tools that help enable you not only from the framework and the code that you're writing with React or Vue or Spelt all the way up to the platform that allows you to deploy your code, not only in US East, but around the world as well too. I think historically, a lot of tools for developers have been built back in first, have been built for the back end developer. If you think about AWS, right, it's a great back end cloud. It has a suite of tools that you can pull from and really craft and build anything that you want. But when you're building the front end of your application, there's a lot of things that are undifferentiated. It's like, I don't really want to have to stitch together all of these different pieces and set up my pipelines and set up all of this front end infrastructure. I just want to build a really good product. And really what the front end cloud means to me is focusing more on the product experience and focusing more on the user experience and just letting a platform like Vercel's front end cloud take care of all of that infrastructure and tooling for you.

Very cool. I love it. With Vercel's front end cloud makes it easy for any team to deploy their apps. Today, you can get started with a 14 -day free trial of Vercel Pro or get a customized enterprise demo from their team. Visit Vercel .com slash changelogpod to get started. That's V -E -R -C -E -L dot com slash changelogpod. So can we go back even further and just answer why, why this effort? Why do you think this is a good direction for Elixir? So I think that's a very good question. I gave a whole talk at Elixir Conference Europe, when we went, 2022 perhaps, on this topic. And what I said, and usually when I go give a conference talk, I usually give Elixir updates when I'm at Elixir events. Like, hey, here are the things that we have been working on. Or I usually talk about a project that I'm involved, like a life book or stuff with machine learning. And then I started the talk saying like, oh, these are the things that I'm excited about in the future of Elixir, like machine learning and stuff. But before I talk about those things, I need to address what I call the elephant in the room. Because if you go to an Elixir event, or I think if you do a poll in the forum or something like that, if you ask what is missing in Elixir, most people, they're going to say it's types. Types are the thing that, like a type system is the thing that is missing in Elixir, right? So if a lot of people feel that's the thing that is missing, I have to understand that. I have to understand why they feel it's missing. Why do they think they are going to gain? And one of the things that I say in this talk, I don't remember precisely the arguments I used at the time, so I may butcher my own presentation. But one of the things that I mentioned at the talk is that usually discussion about types, they tend to get so polarized very quickly. And it's very common for you to hear things that I don't believe to be true if you try to look at it. So I remember seeing people saying, well, if I was using a type system in this particular language, it would have caught like 80 % of my bugs. And then I'm like, I don't think that... I feel like what the type system can do for you is in that particular scenario was being overvalued, right? I don't think it's 80 % of the bugs. And then when you go look at it, when there are some studies trying to find a correlation with that, they can't find something that precise or that clear that says, yes, a type system is going to lead to a program with fewer bugs, right? I don't think we have found the universal proof of that. And I even think this discussion as a whole can be harmful, right? Because you probably heard people saying like, hey, well, if you have types, you don't have to write documentation. And I'm like, I don't agree with that. Get the logical or operation. The types in something is going to be Boolean, Boolean to Boolean, right? That doesn't tell me how that thing behaves, right? And then some people say, oh, if you have types, you can write fewer tests. And I also think that's very harmful. I like to say like, well, if you have types, you can write fewer bad tests because I don't think types would replace 99 % of the tasks that I actually write and I find important, right? Like for example, going back to the same logical or, the types are not going to find bugs in the implementation of logical or if you make it always return false, right? So I get this whole presentation, which was kind of like preparing people, like why we may need a type system in Elixir, but the presentation was much like, well, types are not all this thing that you think they are. So a very good salesman here, right? But the thing that I want to try to get to is like to kind of put everybody on the same page, right? Elixir is also a dynamic, it runs on top of the Erlang virtual machine, which is dynamic. So you're not going to necessarily get like large performance improvements out of that as well. So what do we stand to gain from adding types, right? And what I mentioned in the talk, which I'll try to get through audio right now, is that it's all about contracts. It's all about making sure that, well, when I'm calling this function and that function changes over time, what is going to break? So it's defining contracts between different parts of your code base and helping you find bugs violation to those contracts sooner rather than later. And that's kind of like what we are to gain for Elixir in particular from having a type system. It's this guarantee where the different parts of my code, you know, as they evolve, as they change for time, they are still in accordance with each other. And there's something else that people, they mentioned a lot. They think, well, will Elixir help us like improve the developer tooling as well? Like having a type system with improved developer tooling. And usually the example people give about that is about TypeScript, right? And the funny thing is that it will help for sure, but everything that we need, so for example, if you take JavaScript, the issue why you need the type system to have a way better tooling is because JavaScript is completely dynamic and it's also polymorphic. If you have an object, right? Like you don't know what that thing is, right? All the time you're passing around, you have to call something in that object and you don't know what that thing is. So you have no idea what you're going to complete, but Elixir is not like that. We're not calling things on our variables. We are usually calling things in modules that are well -defined. So in theory, we have, we need you to work, we need to improve our developer experience, continue improving it. But in theory, the types like kind of like we have the saying where we have the, in Portuguese, where we have like the knife and the cheese, like we have everything ready to improve the experience. Everything is there. So in theory, we have that for the developer experience and types always help improve. If you can easily see what this thing expects, you get that quick feedback cycle. It definitely improves, but you know, it's not going to be like an essential jump, like you have in TypeScript where the type system is effectively necessary. Can you say the Portuguese version of that for us? In Portuguese? I want to hear the Portuguese version. Yeah. What's the knife and the cheese in Portuguese? Yeah. Was that French? Yeah. It may have come from the French, actually. It may not, you know. Be native Portuguese. Yeah. I love that saying. There's something very cultural about that, right? The knife and the cheese. Is cheese a common, is it part of like most meals in Portugal or, I mean, why is that an idiom there? Yeah. So actually I don't know if that's also another good question. I don't know if they use it in Portugal or if it's just a Brazilian thing. So

people

will... That's the problem with Portuguese. It's spoken in many places, yes. Well, queso is probably pretty stapled, right? Like

cheese alone, in any form, melted or not, is a staple. In almost all cultures. Yeah, I suppose that is true. Well, I mean, who doesn't like cheese? It originated in the Latin cultures, but everybody was like, you know what? That's so good. We got to take that, you know? Right. I'm appropriating that for my, for my likes because queso is required. I want to start using that. We got the knife and the cheese, you know? Yeah. Like, so you have everything ready, everything in hand, kind of. That's what it means. If it's like a Brazilian, it would be, I would think it more like you have the rice and the beans, you know? Cause like that's the base of our meal or something like that. Right. That's probably how I would say it. But yeah, for some reason it's the knife and the cheese. Adam would say we got the barbecue and the... Home lab. Home lab. Yeah, man. All right. That's my staples, it's home lab and barbecue. Yeah. I like that. Okay. We have the mic and the earphone. There you go. That's right. We could just keep doing this. This is the show now. Thank you. The blank and the blank fell in the blank. Okay. So you had the knife and the cheese. You're not going to have as big of wins as you would have in JavaScript because of the, just the nature of the difference of the languages. It's not that we, we won't have such as a bigger wings is that we were already, we, we already have... You're ahead already. Yeah. That would be one way of saying it. Yeah. No, that makes sense to me. Absolutely. And you're starting with the guard clauses and the pattern matching. Is that where you're kind of like staking the claim? Cause, cause there you're already kind of doing, so in Elixir you can define multiple functions or methods and they can have the, depending on the actual parameters coming in, you can have multiple versions of the same function and it's checking all kinds of stuff. So you can say, is it a struct? You can say, does it have these particular fields? You can do crazy amounts of pattern matching there. And then it will call the appropriate function that matches the pattern. So you're kind of doing, you know, type analysis there in a sense. Then you can have the, the actual guard clauses, which you guys provide a bunch like is underscore map or something like that is list. And you can write your own as well. Can't you, to a certain extent. You can as a composition of existing ones. Okay. But you can't write arbitrary code there. Trust me, I've tried. Yeah. And I would like a feature like that. Cause you know me, Mr. Dynamic, I would just like to be able to write my own guard clauses right there in line. Has anybody requested that feature Jose? I don't think it will ever be approved because like we can kind of see the reasons why, because like, for example, if that was possible, then the work that we are doing right now of doing like type inference patterns and guards, we would not be able to do it. And also Erlang wants to studies that to get information. So we're talking about like the guards and stuff, but Erlang already use that information as well to do optimization. So for example, instead of like boxing integers, if it knows like it can keep them unboxed because the type was already check or to avoid some type checks, it already does that. So, and it may, Erlang may also rearrange the order of the clauses if it think it's more optimized. And at the moment you allow people to just write whatever they want, then you throw all that out. Like people are going to write code that does an HTTP request. They are guard. They are guard. Yes, I am. So

yeah,

it makes sense. It's a trade off and I understand why it will never be the case, but I will say that oftentimes I wish it were the case because I'm like, this would be much simpler if I could just do that. But I understand that that's a bridge too far. You can do your own, like you said, but you're composing existing available guards that Elixir and Erlang already know about, right? Yeah. That's 80 % solution. Yeah, so we are, so as I just said, and we started with the patterns and guards because we want to be able to start using the type system without changing the language. And that was very important for us. We want to be able to evaluate everything and give things a try without imposing any changes on users. Some of the stuff's going to roll out in 1 .17, the upcoming release, right? Yeah. So the 1 % work that I've done, that we've done, sorry, it's already in main. So it's merged. You can give it a try. And there is one other thing that I want to get for 1 .17, which is if a pattern match on a struct, and then you try to... So if a pattern match on the struct and inside the struct declaration, you pattern match on the field that does not exist, that raises a compilation error. But I want to do it so that if a pattern match on a struct and then somewhere else you do like struct .field and that field does not exist, I want that to emit a warning. Previous Elixir versions already did it, but it was a hacked thing that we've built. And this would be done properly backed by a type system. So that's the only other thing I want to have for 1 .17. So maybe by 1 .17, which will be May, we'll have like 2 % or 3 % of everything. But I think we'll be able to go quite further. I wouldn't be surprised if we get close to doing at least all the patterns and all the guards, because here's the thing. So just so we have an idea how much work we have ahead of us, because... So for every construct in the language, I don't mean like every function call. A function call is one construct, but for every construct in the language, a case, a code, receiving messages, everything like accessing a map field, for all those constructs that we have in the language, we need to go and implement the typing rules for them. And we need to do that for all the patterns, all the guards, right? And then what also we need to do is that for each data type in the language, we need to devise the proper data representation from the point of view of the type system. So like atoms for the type systems, they are represented in one way, integers in some other way, lists in some other way, and each of those have their own internal representation as well. So one of the things that the tweet did not go... Actually, I believe I went in the thread, I talked about this, is that today we have no granularity over the type. So in the current implementation is that we have atoms and in the current implementation, the atom OK, we cannot make a distinction between the atom OK and the atom error. Those are all atoms. We don't make a distinction between them. We don't make a distinction between a tuple of two elements and a tuple with three elements. Those are all tuples. So you also have to work on that as well, right? And sometimes when... And this is really hard work. So we stayed two years doing research because, for example, we would look at some data structures in Elixir, like maps, and we're like, wait, we don't have the proper theory to properly type Elixir maps. So Beppe and Guillaume, they actually had to go and develop new theory, like improve mathematically that the theory is correct, just so we can type check Elixir maps, right? So that's the work that we have ahead of us. We have to implement that now. And yeah, and that's all part of that initial milestone. Yeah. So in May, when we inevitably upgrade our Phoenix app to 1 .17 without any sort of changes at all to accommodate this, what would happen to us? Nothing? Would we get some better... Or our compiler would just be smarter, basically? Yeah. So the hope is that we are going to be able to find more bugs in more occasions. So if you have like very obvious mistakes, so those are mistakes that I'm thinking like you would be able to find in a code review, for example, very easily. Like you're reading somebody... Imagine somebody committed some code and they did not run the test or anything. They just changed some code to be able to say, oh, I don't think it's going to work because you said that this thing is a list and you're trying to add that to an integer, right? So like very obvious ones. But then even within asking user to write the types, we'll be able to ramp that up considerably and start finding bugs between a guard that you defined in this other module, right? And then you change that module and this module change. So that thing that I talked about contracts and we want to observe and find out when contracts change, we will be able to do that even if you don't write any type signature at all. And I think this is going to be really valuable. And if we can do it really fast, then I think it's going to be fantastic. I know you have like a Phoenix app, right? Do you use Dialyzer in the Phoenix app or no? No. Okay. If I do, I don't know that I'm doing it. Would that be set up by Phoenix for me? No. What's Dialyzer? So Dialyzer is... Love the smile he gave you. No. Yeah. So Dialyzer is a discrepancy analyzer. So Elixir has like type signatures. You can add type signatures to things.

And

then Dialyzer is going to look at those type signatures and it's going to also find like obvious bugs in your program. Kostas who implemented Dialyzer, he said Dialyzer is never wrong because Dialyzer is only meant to be able to find bugs that it can prove with 100 % certainty that that is going to be a bug, right? Because the other thing about type system is that not a lot of people realize is that type systems, they restrict the kind of code that you can write. Like in many programming languages, you can write a code and you're like, this makes total sense to me. But the language is like, well, the type system cannot understand it, or you cannot prove that code to the type system. So nope, you can't compile it. And if you build a language, statically type since the beginning, you make the language design, the syntax, the semantic, mirror the type system, right? You build everything together side by side. So those like sharp edges, they do not look sharp. Everything makes sense. But if you have an existing language like Elixir or Erlang, adding a type system is much harder. The approach Dialyzer chose probably two decades ago at this point was like, well, it's very similar to what I was saying about Elixir. We want to look at the code, we want to understand the code. And if we find a bug, we are going to let you know. But they don't call themselves a type system, right? And what is new in our research is that we are kind of implementing something like Dialyzer, something that is going to tell you, hey, I for sure have a bug in here. But that's within a type system, right? So it's not a separate thing, which means that if we get the foundation that we're working on and we continue evolving it, we are going to have a type system, like a type system that people can use. So I don't even remember what was the question anymore. But you were asking me a question. Oh, you were asking me a question. Yeah. You asked the question. I turned it around. Well, I didn't know what Dialyzer was. Yes, yes. You were telling me about it. Yeah. So a lot of what I'm saying, so yeah, I went for circle. So a lot of us say if you use Dialyzer before, a lot of the things that I have been saying, they feel similar to Dialyzer. But Dialyzer, like the error messages in Dialyzer, they're not good. They're very confusing. I think Dave Thomas, he gave the best quote about Dialyzer. He said that using Dialyzer is like talking to a monk. You know the monk is correct, but you can't understand what it means. So that's like, so

it's like, Hey, this code cannot fail. They're not like, Oh, sorry. This code cannot work. And then you look at it, this code cannot work. And then you spend like two hours figuring out, right? So we have Dialyzer, it can do some of this work. But the error messages, they are not clear. It also runs separately, right? So it's like, it's a separate workflow. So I was just just saying like, if we had a Dialyzer that ran all the time, right, as you compiled, it was fast and it had good error messages. It would already be like a huge, a huge boom, like to the user experience. And we're starting there, you know, that's what we are trying. In a way, I think it would be like, because I'm saying like, Oh, we can have a Titus in the future. But I wonder, could we just do like the first milestone that I'm saying, like, we try to guess everything and then people are so happy that we don't have to go the whole way. They're like, stop, right? Like, don't change it. Like, I don't know. But we'll see what happens. Yeah.

Well,

yeah, I think that would be a big boon. I mean, especially with things like Dialyzer, where if you're a casual user of Elixir, like myself over the course of six or seven years, I didn't even know. It rang a bell, but I didn't know what that bell meant. So like having it built in first class citizen of Elixir and just there doing its thing and with good error messages and all that stuff, I'm sure we will be very helpful. And you asked like, is that something that Phoenix generates by default? Dialyzer has been part of Erlang way before I started programming Erlang. And the reason why we didn't add it is because we don't think the trade -offs are worth it there. Like it's really a power user too. And if you want to opt into that, like do your research, right? Like search your inner piece so you can talk to the monk, you know? And yeah. Well, I've used Credo. So there's an Analyzer tool, which I think is mostly a linter and a thing that's not the Elixir way kind of thing. And that was fine. But also, I guess, got annoying for me as a solo dev because I guess for me, the reason why I've always been dynamic language is first and foremost is I just like my freedom, you know? And if the tool doesn't provide major value, but it just annoys, like I'm sure Dialyzer, I would turn it off probably very quickly because it's telling me something's wrong, but it's not helping me know why it's wrong and everything looks right to me, I don't want it. I don't want a tool that just gets in my way and tells me that my stuff sucks, but not why. And so I've traditionally ignored a lot of that kind of stuff because I just want the freedom to write the code that I need to write to get the job done. But if the tool can provide value and help and not be just a hindrance, you know, just something I'm fighting against, then I'm here for it. So hopefully you guys strike that balance, especially with the 3 % solution. If you're listening, you may remember the early days of the internet where open networks like HTTP and SMTP led to an explosion of websites and online communities. Building a fan site and connecting over shared passions led so many of us to careers in software. Back then, it seemed like anything was possible because the internet of the 90s was built to democratize information, not consolidate it with a handful of big tech companies. Read Write Own Building the Next Era of the Internet is a new book from startup investor Chris Dixon that explores how network architecture plays out in our online lives and the decisions that took us from open networks governed by communities of developers to massive social networks run by internet giants. Read Write Own is a playbook for reclaiming control and for reimagining applications so users can own, co -create, and even profit from the platforms they use every day. From AI that compensates creators to protocols that reward open source contributions, this is our chance to build the internet we want, not the one we inherited. Order your copy of Read Write Own today or go to readwriteown .com to learn more. How all this started. There is also the thing like similar to the machine learning work, the machine learning effort. It's like, you know, I haven't like, it has been a while since I have been hearing about types, right. Or, you know, that I've been like, familiar with machine learning for quite some time. But like, the reason why we started was because like certain events happen with machine learning was me meeting Sean and Jacko and we're able to, to form a and I actually tried to implement a type system in 2017, 2018 and failed, like failed really quickly. And then Eric from the Elixir team, he also started implementing one. And that's like, so Elixir sometimes can find like type violations because we have like a very simple type system, but we very quickly, we ran into roadblocks like, Oh, how are we to solve this problem? Because like, we don't have the proper background. Like we're reading papers and I think both of us, like we have a master, we have not gone further than a master and I don't even have a master in computer science. So we were trying to figure out this and we were basically stuck. And then somebody sent me a paper they wrote. It was their master thesis, or they wrote for their master thesis in Uruguay about implementing a gradual type system for Elixir. And so they sent me an email like, Hey, we wrote this paper. You may enjoy it, right? I was like, Oh, this is very exciting. Like, would you be interested in working on this? And they're like, Nope, we are out of the university, probably never to be back.

And

I was like, Oh, okay. That's a shame. But I went like to the citations in the paper, in the article. And then there was a lot of citations from Giuseppe Castagna, which is a researcher very known, like has a lot of publications in the world of type systems. So he had a bunch of papers and I started reading those papers. And one of the papers that I found was exactly about the problem that Eric and I were trying to solve. And the paper was that, Oh, when you're implementing a type system, some languages have to solve this problem. And then I started reading the paper, like section two, the introduction. I was like, Oh my God, this is exactly what I need. This is the answer. I'm going to solve my problems. And then like section three, well, we can express this problem as the following like mathematical understanding of this and this and that. And then it's like, but the mathematical understanding and then section four, now we are going to prove that our mathematical understanding of the problem is correct. And there's like a bunch of proofs, like three or four pages of proofs. And then it never comes back. It never comes back to tell me like, here's how you would actually implement this. Right. It's like, Oh, and then I sent an email to Giuseppe saying, Hey, Giuseppe, like I read this paper, I work on Elixir, but I have, like, I don't have the proper background. Right. And I basically told him this story, like that his paper is basically, I cannot understand it. And then I said, Oh, I actually wrote like this larger paper for implementers, for people who want to implement a type system. And then he shared that with me. And then we started talking if there was a way we could like collaborate and work together. And that eventually led to, we like we're partnering with some companies. So a lot of companies have sponsored the type system work as it happened. Fresha, Superbase, Remote, Dashbit, Starfish. So many companies have been sponsoring and then we were able to make it happen. Right. And the thing is that it's also about like, you have a lot of programming language, so the story is over. But the other thing related to this is that there are a lot of programming languages, but we don't tend to think about this, but there are also a lot of type systems, like those types type systems, they are effectively different in how like they are implemented in their mathematical foundation behind them. So how do you find, right? Like, you know, if you have a bunch of languages, how are you going to find what is the proper type system for our programming language? Right. And the thing is that the approaches that we were trying before, they were like ultimately incompatible. And if the type system is incompatible, it means that it won't be able to type certain features of Elixir. So you either have to say, hey, if you're using a type system, you cannot write the Elixir that you write every day, right? Or you do not have a type system. And I wanted to avoid that, right? If we go into this place where there is like, maybe it's like an uncanny valley of like of gradual typing, which is one of the reasons why I say the project can fail. So what we did, like one of the other reasons we had like those three years of research is to going through a bunch of Elixir constructs and saying, hey, does this map well to this type system? And this type system is called a stat theoretic type system, and it looks fancy. But basically what it means is that everything is implemented in terms of sets, in terms of unions, intersections, like things that you learn like early when you are studying, right? So that's also something that makes me excited because if the type system is implemented in terms of unions and intersections, there is also a hope that it's going to be more accessible, right? And it's funny, like all this started because, you know, two master's students in Uruguay decided like to write the thesis, but not only that, they decided to send me an email, right? If they didn't send me any mail, maybe I would never have heard about it. So Giuseppe ended up helping you implement or how did the thing move forward from, you know, you were stuck, you mailed him back and said, hey, this doesn't give me what I need. He had a bigger paper. Did he continue to work on it with you or was it kind of a handoff of that larger paper in it at all? So we got a PhD student. So he is like a, he's the poor soul with two bosses. So Guillaume, so, you know, he's doing, he did a prototype. He's the one who is like effectively doing the work, I believe, of like, oh, I get this Elixir construct. It maps to this, maps to this. And then if he has a question, he brings to Beppin, Beppin is going to be like, oh, maybe you can use this theory or I just want to be clear. I am kind of assuming that's how they work. But and then Beppin was like, oh, actually, this is a problem that we have not solved yet. We have to work hard or maybe we have to write new papers. And what I really like about working with them is that, so there's potentially, it's like, I like to ask a lot of questions because the way I learn things is about like, kind of like trying to find the boundaries. That's like how I learn things. Like I try to find like to as much as possible what I can do with that particular abstraction, what I cannot do so I can try to situate where and how I'm going to use it. And what I like about working with them is because this process of asking questions when work with them is a collaborative process where it's not like, no, you can do it. No, you cannot do it. But they were like, huh, maybe we can do that in a different way that has not been tried before. You know, and that's very interesting because it's like it's a learning experience for everybody. I definitely learn a lot, but the process of asking question helps us like approach problems in different ways. And one of the things that probably doesn't make sense, we can have a link to enter to talk about in the show, but we wrote an article for the Elixir website called Strong Arrows, a New Approach to Gradual Typing. And usually, gradually typed programming languages, they have to deal with some trade -offs in their implementation, which is like, or you can do like TypeScript. So TypeScript, for example, sometimes the type system is going to say, hey, this thing is an integer or a number. But at runtime, the thing comes out at a boolean, which should not be possible, right? So or you make the type system behave like that, or you make the type system work a lot with dynamic, which is not very useful because one of the reasons you want to work with the type system is to not work with dynamic types all the time, or you have to introduce like runtime costs. So this was one of the cases where we are not happy with any of the solutions out there, and we're able to develop a new approach to how gradually typed languages can be implemented that as far as I know, nobody has tried that before. And that's the exciting thing. And also the scary thing in that we are trying something that I think like nobody has tried. And it's like, maybe it means that we are going to find something really good that really suits the language. But it may also mean that we're just going to make a bunch of mistakes because it's kind of like maybe somebody actually tried that, but they didn't write about it because it ultimately failed. And you don't often hear about things that fail. So you're 13 years in to this Elixir project of yours. You've had some diversions, maybe they're not diversions, but you've had time working on NX, you have Livebook. If it does some other stuff that hasn't been like right on Elixir proper, but now you're back on like the Elixir programming language work, you seem as excited as ever. I mean, you seem very enthusiastic. But I wonder, like, do you ever see an end to this road with you and Elixir? Do you think, like, do you ever feel like I should do something else with my life or is this your life project now? What's your take on it? Yeah. So do you remember which year COVID started? Was it 2020? Yeah, 2020. So I've always kind of tried to see myself or position myself as replaceable. That's my ultimate goal. One of the reasons is because, yes, I'm not going to be here forever, obviously. But also, I think, in this sense, it's kind of like a sense of like, you know, kind of like it's fewer responsibilities. And that's a very comfortable place to be at, right? It's like, well, if I'm replaceable, it means like fewer people depend on me. And that's very comfortable because I don't like people depending on me. So I think, so a lot of that has happened in Elixir design as a language. So Elixir doesn't change a lot, right? Like as a programming language, it changes. It has been quite stable. I have been, I've said at this point probably five years ago that Elixir is kind of done and the type system, it's potentially the only thing that is going to change that. And I think it's going to be, it's going to have repos, right? It's not like, oh, we have a type system, right? I'm sure if we go all the way in, it's going to change some idioms that we have in the language. We may say, oh, that's actually, you know, maybe because we can type it or also because after we start typing it, we figure out that that's a bad idea. I like to draw like comparisons with the code formatter. When we added the code formatter to Elixir, sometimes people would come with code and say, look, the code formatter makes this piece of code ugly, right? And then when you went to look at the code, it was because it had like a function call inside another function call inside another function call with something happening inside that function call. So like highly nested code. And then I'm like, look, that code, I'm sorry to inform you, that code was ugly, right? It's just that you try to squeeze everything together and maybe try to fit one line. And the formatter is just telling you, it's like, yo, like this is not going to fly, right? Like you have to change. That should be an official response from that, from the formatter. Like, yo, this is not going to fly. That would make programming more fun, right? With love, Jose. Yeah, with love, for sure. Yeah. So, and I think like the type system is definitely going to have some of that. We are going to learn things similar to the formatter. It's not that formatter is perfect. The formatter has limitations and you're going to have to. And you readjust it as a community to that. And the type system is going to be more because it's not only about opinion and style. It's going to be about actual software correctness. So, yeah. So there is like this whole journey happening right now, which is going to take quite a while, right? And we started the whole machine learning stuff, but the machine learning stuff, like my idea for things is like, well, I'm involved in machine learning, but I hope eventually I'm going to find a way to hand it off and have that whole thing continue without my input. It's just like, you know, it's like, I mean, my kids, they are five and nine, but, you know, like I'm eventually hoping that all my projects go to university, if you know what I mean. So that's how I see myself. And the funny story, the reason I ask for the year is that the year before COVID, or maybe even the year that we had COVID, is that I was really at a place where I was like, am I done? Am I close to done? Am I close to like, to really making these like 20 % of my time? Am I close to making these like 50 % of my time? And I was really considering that, right? And then when that happened, when I was thinking about that, it was when I got the email from the university in Uruguay that led me to types, right? And it was when I met Sean and we started the machine learning work. So it was really funny that when I was thinking like, Hey, am I close to done? Lifecom was like, no, just slap a chair on my back. It was like, you have more, 10 years of work ahead of you. Good timing. Good timing indeed. So how you've been working on the type system, you know, with the team for a couple of years now, how far do you think you are from it being like, we can just call it, we have a another year, another five years, like just roughly, what are you thinking? It's more like five because we don't want to, we are being very intentional. That's the word I want to use it early. Intentionally, we're being very intentional. We are being slow on purpose. I wanted our paper to be called a gradual, gradual type system, but it was rejected. Because we are like gradually introducing everything, the gradual type system and so on. And because of that, I think it's going to take some time until we do everything. I also like to say that it's kind of like, I use this analogy a lot, a lot of like the, the boiling frog. I don't know if this is true, but you know, in theory, like if you put the frog in the pan and then if it's hot, it jumps out. But if you start like warming the temperature, and I think that's kind of how we need to approach this. If we just like add the type system all at once, it's going to be a big shock to the community. But if we can do that in steps, we'll all be happy like a boiling frogs. So I think it's more like five years. Not that, oh, we are right. It's like not that we're going to have it in five years, but like the whole process being delicate as we are being is going to take about that time. And I talk about research, for example, and we had to research a couple of things. There were some things that we've identified that we can improve over the status quo. So there is one thing that we did not do, for example, that for us is like out of the scope of the type system, which is so in Elixir, we have like processes and you can send messages between those processes. I said since the beginning, I am not interested in that because very few people, they are sending messages directly. Everybody's using existing abstraction, like John Server or Tasks. So I said, I'm not honestly very interested on that part. So there are things that we didn't do. And maybe in 10 years, maybe somebody will have like cracked that problem in a very interesting way. But also there are things like we have behaviors today, like a John Server, and we can kind of add types to that thing, but it's loosely defined. So we are studying bringing a post -doctorate to think about the problem of how to type behaviors. And this is going to be like somebody, a post -doctorate researching the theory on that for maybe a year and then figuring out a proper implementation. So by the time in five years is where we are like, oh, Elixir is in a good place type system now, somebody say, hey, I have like this brand new theory that is going to make behaviors in Elixir much better than they are right now and then need to consider introducing it. So I was just to say very naively some time ago that maybe I would retire when I'm 40. And I don't mean like retire, like I won't, I will stop coding, but it's like coding does not need to be like the main driving factor of my life. Like I won't be like waking up for coding anymore. Let's say professionally, I could try to find something else to do, but yeah, I don't think I don't think it's not going to happen. I feel like I should probably revisit that to 50, you know, like, but I'm also like, man, like 50, 12, 13 years ahead and like maybe 45 is going to cut, but I think like 45 is not going to cut. So somewhere there. Speaking of decades and how you think about things, we had a great conversation about a hundred year programming language called HAIR. You may have heard of it. And you mentioned maybe in a decade, this researcher, this post -doctorate can research this and in five years, or you just sort of laid out as if, you know, knowing or thinking that Elixir will be here in a decade and be relevant in a decade, how do you, how do you, or how does a community that helps you support this language and those folks who are sort of thinking, okay, let's get a post -doctor to do research, et cetera. How do you all think about the length of time that Elixir will be relevant and useful? How do you think about that? Oh, I think it's a, yeah. I'm going to say something that I think it's not, I think the answer to that question is not technologically related at all, actually. Okay. I think unless we have a big shift in technology where it's like quantum computers are viable and then everything that we use is kind of gone and we are starting fresh. So unless like, assuming that there is no, well, maybe AI is a big change that changes everything. And then the good programming languages are going to be the ones that are good for AI. Like maybe somehow that happens, but assuming that there are like no major changes to the industry, or if there's a major change, we can survive to them. I think like the relevance of a programming language is mostly building a community, work with the community and marketing more than technology. The technology it's like, it's, so we use the technology, the early virtual machine being great as like the motivation, the things that attracts and excites people. But after I think you do that initial jump, it's all about the community being self -sustained, continue being excited about what they do, what they build, how they interact with each other, then any technological aspect, if that makes sense. Yeah. There could be some truth to what you said with perhaps languages, quote unquote, winning if they are better suited for code generation. In fact, I think Natalie Pistonovich on Go Time has a talk about that where she thinks that Go will eventually eclipse Python and usage because it's so well suited for code generation. Just the aspects of Go make it very good for AI generated code. That's not bad code. And so, I don't know, that's obviously just an idea. That makes me think about tooling right now as an elixir -ist, I feel like the state of the art GPTs are not very good at elixir. I find them better at JavaScript. Those are the two languages that I write the most. And I'm curious if you have used them, if you agree with that, if you wonder, cause it's obviously a very successful language, like 99 % more successful than, or more successful than like 99 % of languages ever invented, but it's still a niche language in the scope of the industry today. And so much so that when I tell people I write elixir, some people have to ask me what that is and I'm happy to answer it, but it's, you know, it's somewhat obscure. And I feel like the amount of blog posts and stack overflow answers and all the stuff that the GPTs slurp up must be less than JavaScript and TypeScript because it's not very good at elixir yet, in my experience. Yeah, that's the thing. But so I think we are at the, we are very early on the AI side of things to be able to see what is a good language for AI. Because I think like right now, a lot of the things are dictated by like the corpus size, but it's not yet clear if, you know, when we are coding in the future, if elixir has not passed the threshold of our good corpus size, it may just have been diluted. We don't know that. And I want to go on another tangent that I come back to it later. So I think it's still unclear that's the case. So for example, I've heard last week somebody telling me that although GPT -4 is good for JavaScript, they were having a really bad time using that for things like React and Next because things have evolved through time. And for complex problems, it would frequently give mixed usage, like, oh, like a pattern that it was using this React version, but not on this one. So it's like, you know, like maybe if we had things that were like fine tuned per React version or for elixir, we could have like a different experience. But I also think that I feel like everybody kind of like, I heard people say like functional programming languages, they are going to be really good for AI because there is less state, there is less assumption being passed around, which makes sense. But I think ultimately we really don't know. It may mean that other people say like typing is also good because then you can go into this loop with the AI where it generates the program and they're like, yo, this doesn't type check. So if you can do more static analysis, right? But maybe there is a chance, like, you know, maybe the best AI language is not necessarily textual, right? It's less based on the textual mode, just that the textual mode and the LLMs is what is the hot thing right now. So I think it is still a very open problem and I wouldn't try, like, yeah, I wouldn't try to guess. We're pretty early on in that. Yeah, and I think like maybe other people, they can have a pretty good idea, but I'm also new in the machine learning space to understand what is like, how things are volatile because now we are all riding on this architecture, right? On the transformers architecture that everything's like building on top. But what if there is a new architecture, right? So we are talking about, oh, there are changes in computing, right? But it can also have like a major change inside AI. So if there is a new architecture that changes everything, like then maybe this conversation goes like in a completely different way. Well, I agree with that. I think probably it's too early to tell. And obviously people will try to decide what makes a good programming language for, like you said, for transformers. And it may not be true for the next particular platform shift if there is one. With the state of the art right now as like Elixir community, have you considered from like a marketing or like a community perspective, like having a fine tuned or I don't know, ragged, like Elixir, all knowing Elixir chat bot that would be like awesome Elixir because we made sure that it is by doing certain things that we can do. Yeah, that's a great question. And I have thought about it. I have built some prototypes about the best way to go about that. And there's another funny story here, which is that I took some holidays early December. And then before the holidays, there was like the OpenAI, they had an event where they announced like the GPTs kind of things. And I've been also thinking about AI in the context of Livebook. And then before I went to holidays, I told people like, hey, I've been thinking about this. I've been thinking about what OpenAI announced. And I probably think like the new APIs they provided for completions, we should build something on top of that. Because even if in the future, OpenAI is not the winner or people don't want to use a closed source model, you have like a hundred different solutions, which adds OpenAI APIs to other models. So it's like their API, whatever we think about it, their API is kind of going to be the winner, you know? So it makes sense to build against them. So I was like, let's build something against OpenAI. And then I go on holidays and I come back from holidays and apparently the CEO was fired and then they come back. And then there was like, like in the two weeks I was on holidays, I know they came back. It's like, what happened? And then I was like, so I was ready. I was ready to go. Right. And then it put me back like, okay, take a deep breath. Right. It's like, maybe not quite, but it's something like, so something that I want to do, I don't remember who did it. I think it was Co. Plus one of the companies that started with Co. What they did is that they generated embeddings for all of Wikipedia. So if you want to do something, you can just get the embedding and search the embedding. It's something that I have been thinking a lot about. What if we could generate embeddings for all the documentation that we have in Hexdocs? So people can very easily start building their own indexes, their own regs and this kind of stuff. Right. So we started exploring these. We already did some groundwork. We had some students at the University of Krakow studying different embedding models so we could that work. So it's something that we have been thinking a lot about, like maybe having an official Elixir GPT, but it's still not sure if it's going to be something useful. We need to find the line between useful and gimmicky. And I think that is still very hard for a lot of the AI stuff. But maybe gimmick is fine. That's how people get excited, but we need to be aware of where we will be investing our time. And maybe this year we are going to have something going in this direction. We also have Robert from... We have a machine learning channel

in

the Early Ecosystem Foundation. I know he fine -tuned some code completion models for Elixir, and we plan to evaluate those and give those a try as well. So I think we can do exciting things. But yeah, I feel it's still very hard to draw the line between what is going to be useful and what is going to be gimmicky. And that makes me a little bit uncertain of how I'm going to prioritize because there are a bunch of projects we can work on and improve the ecosystem. So is that the best use of our time? And this brings me back to the thing that I said I want to talk about, about the corpus size, which is that I feel that starting a new programming language is actually becoming harder because... So there are a lot of things that got easier. Like, for example, everybody who started a new programming language, they are going to use LLVM, right? So a huge part of our compiler stack that got easier, for sure. But the requirements for you to have a programming language that people are going to consider useful, they have like just over the last decade, potentially a bit more, it feels like it has kind of like wrapped up, right? So for example, before we were like, oh, you want to have a new programming language, you write a new programming language, you would share it on the main list, you would put on GitHub, people would give it a try. And I think, for example, one of the things that go was very influential was like making tooling first class. So today is like tooling has to be first class. There is no discussion about that. And I think, despite of everything that happened around that led to Go adoption, I think having a good tooling since the beginning definitely played a factor, right? So yeah, you have to create a language now and the tooling, and most likely you need a package manager, right? And I like to use, again, Go as an example, because Go thought they could not have a package manager, right? And if there is a language that could potentially not have one, is one that is backed by a big corporation, they're like, well, it does happen that we need a package manager, right? So you also need a package manager, right? But the other thing that I like to say is that with the language server protocol, you would think that that would help programming languages, and that does help programming languages, but it kind of make editor integration table stakes. So now everybody needs to have editor integration. If you don't have a good editor integration, because it made it more accessible, now everybody has to use it. Before, when I started with Elixir, nobody really cared much about editor integration or about the language supporting it, because a lot of programming languages, you had a bunch of editors, and all those editors, they had kind of spotty integration with the language, So it was not like, people were not like, you need to have a very good one, right? Now you need to have a very good one. You need to have people and time invested on having a very good language server integration and IDE and this kind of stuff, right? And now with AI, if it really becomes like a playing factor, a big play factor, you need to have a big corporate size to train the AI, but how you're going to do that if you're just starting out, right? So it's kind of like, it has become harder, but at that point you could through work at it. But if AI becomes such a big player on developer tooling, how can a new programming language go cross that chasm, that cost, that gap, right? And I don't have an answer for that. I think you said, Elixir is still kind of niche, but I think we're lucky because we have enough, right? So you have a corporate size that is at least there, right? And that's one of the things that worries me about, well, if AI is not going to be decentralized, then it means that me 10 years ago, right? If AI is not decentralized myself 10 years ago, maybe I wouldn't be able to restart a new programming language nowadays, right? Because I can't customize the AI. So I think it's very important for us to have open source AI tools because it means that if AI becomes a big factor and you are a small programming language, there is at least an option for you to make a dent, for you to participate compared to everything being closed and hidden somewhere. And I agree that if we rely on them more and more, that assumes that all programming languages have been, all problems have been solved in current LLMs and that status quo is long -term status quo. And I think that's just not going to be true. I think that developers will eventually have problems with whatever can be done with what is status quo and what is supported by AI. That if we as developers stop solving problems, then new programming language cannot come around because hair, for example, is not, you know, it's a hundred year programming language. We talked about that, you know, a little bit earlier and we talked about on this podcast before, but that is a, that's an example of where someone in particular sees a different problem and does not rely fully on artificial intelligence to generate their code, right? So if developers at large, and I mean like 99 % or more rely on artificial intelligence to do all their work, then that would be a problem. But they're still at 1 % and that 1 % can still be influential. And there is still a path forward into the future LLMs and the training and the embeddings, as you mentioned. I think if for some reason the artificial intelligence locks us out, maybe then we have nothing new. We only have what's existing. Yeah, I think that's a very good take. And I wonder if we get there, like what are the dynamics, right? Does the 1 % need to be like, whatever we continue evolving, does it need to be really good for people to justify, oh, I am dropping my AI tools to learn that 1 % because it's such a big boom that is worth like dropping some of the conveniences, right? So I think that's kind of like the, one of the main points, which kind of like, it's not really AI specific in the sense that it has always been the trade -off and adopting new technology. And I think that's kind of why I talked about the editor tooling, right? The fact that now everybody should have editor tooling, that's no longer a differentiating factor between programming languages, right? Because it's kind of table stakes. So yeah, I think that that's a very good point. Like if we continue being able to innovate and continue like finding things that are worth moving through and exploring, then yeah, it's just like, does it need to be a much bigger gap right now? And if it is, what is this type of investment and time you need to put into that? Well, this is how disruption happens though, is not something comes by which is marginally better at one thing and also satisfies all the table stakes. What happens is something new comes out that is radically different than everything else has come before it. And it's 10x or 100x better at one particular thing that everybody cares about. So for instance, it's a hundred times faster than every other programming language, but it has zero AI and tooling integration. And people are like, I don't care because I want the 100x improvement. Or it's 20 times more productive. You can write three lines of code and end up with facebook .com or whatever. Yeah, you're always a default to facebook .com. Well, it's a huge application, right? I understand why. It has so many features

and

everybody knows about it. But I was going to use Twitter, then I was like, no, it's just been losing features all year. You know, it's like way more productive in the way that it works. And so therefore all the other things don't matter. And I'll put up with not having any of them because I want this one thing. And then slowly over time and everybody laughs at it. Oh, you don't even have VS code integration. No one's ever going to use that, right? And this is how it always happens. We just don't know what that thing is or what it will look like. And maybe it won't, you know, maybe it'll just be incremental improvements. And those are going to be harder to stake a claim because there's so much surface area you have to cover like you explained, Jose. I also agree that what you said before about Elixir with community, you know, that it won't be a technological thing that keeps Elixir being relevant for years. It's community, it's, you know, non -change, non -major paradigm changes in the tech stack and a couple other things. And I think that's true too. This is why I think essentially what we're saying is that tool makers need to remain tool makers, not just AI implementers. That whatever the thing gives us, we must just assume and take and use that we must always keep thinking for ourselves. Is there a better way? Ken, I think the future will be, I think, largely human made and maybe augmented by AI at some point, maybe fully augmented if we ever get there. I'm sure we will because that's how progress happens. But, you know, for the foreseeable future, at least in my lifetime, I think humans will have a vested interest in innovation and assisted by some other thing like an AI. And I think if we have tiny communities or indie conferences that people can still get to or slacks to be a part of or just groups to be a part of where human to human interaction and agreeance on challenges and solutions and research and all the things is still a thing, I think we'll continue to have innovation that really maps to where we need to go and what we need to do. And it won't be stopped or encumbered by, does AI support this or does AI not support this? I think we'll force whatever is necessary to have human advancement. Yeah, I like that idea a lot. And I think it kind of, so Jared was saying, well, you know, you need like 10X improvement to an X improvement, but a lot of people end up migrating to Elixir. And I don't think Elixir is a 10X improvement over anything, right? Like maybe within our choices of programming languages, there is nothing really that is 10X, right? So maybe for some reason I am overvaluing the tooling, you know, the tooling that is there only to support this, but not do all the work. You see what I mean? It's like, yeah, it's on the margins. I mean, obviously I say 10X or 100X

doesn't

necessarily have to be those factors. But if we took something like Rust, for instance, like if you're a C programmer and you've been writing C programs and here comes Rust and it's offering security guarantees that you'll never have with C. Rust now is established and has all the tooling and stuff, but imagine didn't, but it's still offered that. You might say, yeah, I'm going to do Rust because it's so much better at this thing that matters that the small stuff doesn't matter quite as much. That's just one, for instance. And which you can't really quantify properly, right? So the 100X doesn't even matter at this point because you really can't quantify it. It's just, and in Rust case, I mean, there are other trade -offs there, but for the bugs, like going back to type systems, right? It's like, it is provable that it is avoiding those kinds of bugs, right? So, yeah. And the reason why I say 10X is because when we do talk about the innovator's dilemma and disruption theory, it's usually

is

10 or more, but what it is is it's 10X less expensive. Like usually there's one thing that makes it so much cheaper. And with programming languages, we don't talk about that because everything's free and labor and your investment time matters. But most disruption comes because something is radically different and it's worse than the incumbent, but it's 10 or more times less expensive. And so you'll put up with worse because you're paying so much less. And that's just, I'm just taking that whole dichotomy and applying it to programming languages, which doesn't exactly fit either. Just food for thought. But I don't know, why did I switch to Elixir? I think I was a Rubyist and I appreciate the freedom and dynamism of Ruby. And I saw that in Elixir and I liked the speed of Elixir compared to Ruby. Maybe it was 10X faster. I can't recall, but it certainly had, especially in web server performance, very impressive numbers with very similar looking code. You know, if we take it at face value, once you get into it, you realize it's not all that similar at all, but has some shared pedigree with a language that I love, but was going to be a lot faster for me in production. And so that was why I switched plus Chris McCord convinced me. Yeah, I guess I'm contradicting myself over this episode because yes, there was about comparisons to Ruby. There are several cases about people migrating and usually it's usually a 10X on machine capacity, right? Like some people are like, oh, we went from... Cores. Wasn't it cores? It's all about cores. It was usually machines. It's like, oh, we were deploying like 80 machines and now it's four. And by the way, it's four because we are over provisioning because we are worried that we went too low. That's usually how the story goes. No, you're actually right. There were in particular to Ruby, there are 10X. The other thing that I'm thinking right now, so I'm enjoying a lot of this conversation. The thing that I'm thinking right now is because I was asking why I'm so worried about tooling, right? Because I was thinking like, oh, now the tooling is so hard. It's hard for our programming language to restart. And maybe it's not that it's hard for the programming language restart, but maybe it's for the programming language to cross a certain step throughout its evolution. You see what I mean? Like maybe Elixir, the reason why I think so much about tooling is because of course I hear people talking about tooling and maybe it's at a point in its adoption that in order for that to make the next leap, tooling plays a crucial role. And that's why I am indirectly putting so much attention on tooling and thinking about AI and thinking about the Elixir protocol and thinking about types, because that may be part of the journey there. I don't know. It's definitely food for thought. I thought I had this figured out, but I clearly don't. Well, sorry about that. Well, I mean, you could draw lines to civilizations as well at different stages of civilization where you have the things that we care about and are concerned about. For instance, the United States right now is not basic sanitation, right? We're at the tooling phase of country, right? Like where you are, obviously in some cases now we're regressing, we do have sanitation problems, but we've gotten there. When Elixir first started coming out, you were probably worried about like, do I have the data structures right? And like, hey, why can't I enumerate over this list the way I want to? Those are core features of a language and you're established and you're there. And now you're worried about things that are higher up the stack, like tooling. You know, playing that game is how you make it better now. And so at different phases, different things matter. And that's probably why you're so concerned with tooling because that's where Elixir is. I mean, it's a great language. It's stable. It's fast. It's productive. I mean, it's all the things that you set out to build in my opinion. And so, you know, congratulations on the success, not just yourself, but the whole community. And now it's like, okay, how do we take it better from here? Well, apparently we gradually, gradually add types to it. And that's what, that's where you're at. I actually did some math. I couldn't help it because I was thinking like, you know, when you think about directors or particular actors, you think about like Tom Cruise, for example, I think Top Gun was like his all time, Mavericks, of course, the latest one, was his top grossing movie of all time for himself. Right. It trumped every other, and sorry Jared, I use that word trump. It has exceeded all past records for Tom Cruise as an actor in a movie. And so I was like, well, what has Jose done in terms of listenership on the Change Law podcast network? Because you've been on Practically Eye talking about different things. You've been on this show, you've been on Now Friends, you know, you've had Chris along with you to sort of like talk through some things. So collectively, you're responsible for at least 210 ,000 listens on our podcast. Yeah, Across Shore, one, two, three, four, five, six shows. Now, the seventh one that you're on right now may take you into the 250. This could be your Top Gun Maverick right here. This could be your Maverick right here. Well, yeah, just, you know, the title Elixir is officially typed is officially language. That's right. Officially in quotes. We're going to get that virality going. I do have one more and maybe you answer this, but I like a more direct answer if you haven't. I think you alluded to some things or the challenges at least. So to Jared's point earlier, AI as it's known today, GPT, chat GPT and others are not that good with assisting with Elixir programming. And so I guess the question is, what does it take to make it good? You mentioned embeddings earlier. You mentioned documentation being more readily available. What does it take from a, I guess, a leader in the Elixir world to enable LLMs to be better? What role do you play in that journey for them to better consume the documentation and better know how to programming in Elixir to help folks like Jared and myself or our team or others to really become better and more proficient in Elixir versus just like anytime Jared asks chat GPT for assistance, it's just like, no, it's not good. So just quit. So I think if I got the question right, I think we did our work correctly in the sense that at least from the language point of view, in the sense that documentation was always first -class. So documentation is very easy to access. So if what you want to do is to configure an LLM, it's actually very easy to access that programmatically, send that, extract information. And we talked about one of the things that you also have to do is try to get understanding from the source code so you can find, oh, this code is using those modules, is importing those things. And those are things that you can do relatively easily in Elixir. We can most likely improve that. So I feel like we have the knife and the cheese. It's just a matter of somebody going and cutting the cheese. It's, yeah, I feel like the foundation is there in terms of like having this information is structured, but somebody needs to feed it somewhere. But again, we can go back, like maybe it's a corpus size, like maybe

chat

GPT like indexed hex PM already. Not sure, right? Maybe it has done that. I don't know. I don't know if I can send a letter to somebody, hey, please index my website, or maybe it's a matter of... So one of the things is that Redmalk, they release twice a year, like kind of a graph plotting GitHub against Stack Overflow. And I think they are having like the most popular languages according to GitHub and Stack Overflow. And then there's like a linear thing in the middle. And it's very funny because Elixir is high on the GitHub side, but quite low on the Stack Overflow side. And one of the reasons for that is because we have always had the Elixir forum. So that may be one of the things - Where's the knowledge? Where's the back and forth from the community? Yeah, the knowledge is in the forum. Is that thing being dexed? Because we know Stack Overflow is, right? Yeah. And ironically, that's one of the reasons I think I may be misquoting that Redmalk, they are considering removing Stack Overflow from their plots because it's prone... I think it has been losing relevance in the last years, right? But maybe in the effort of trying to have a closer community where everybody can engage with each other, wherein I'm active in the forum and I'll probably not have the patience if I was dealing with Stack Overflow, right? We created our community a special place, but it's not known. So yeah, so I think it's still too many unknowns, but I think at the core, we unwillingly did a good job because we were worried about documentation being accessible, documentation being first class. So we did that and that can be... And we promote people to write documentation, lots of documentation, right? So there is a lot there. And yeah, and maybe the rag is going to be the thing that is going to be enough. That's one of the hopes, right? Going back to, oh, we want everybody to be able to use this. If rag is good enough, then a lot of people would be able to augment their ecosystems without depending on open AR or whatever. But we are still evaluating. When we talked about sort of the long -term future of Elixir, artificial intelligence, and that sort of larger topic of how long will be relevant and can AI generate it well, that whole conversation. This makes me think of this necessity to not have a black box that is whatever AI is. Because just like you said, who do I send a letter to to index my stuff so that my very relevant language today remains relevant tomorrow because tomorrow says AI will continue to be more and more relevant to developers in their journey to develop, right? So who do we send the letter to? How do we know? Well, currently the status quo of AI is for the most part a black box. Obviously, open source LLMs and indexes have become more and more pushed because of this challenge. But I think this illustrates and highlights really the long -term challenge because even you can't say for sure why what wasn't indexed was indexed for the Elixir corpus, whether that's the forums, whether that's the documentation, through hex documentation or whatever, it's unclear to someone like you how to enable chatgpt or the likes to better support Elixir assistance for developers using those things to use this tooling. And that's just not cool because long term we need to have inroads into those places so that we can be part of the future if AI is predicting how we'll get to the future. Yeah, and I think, yeah, this is too early. I think we're going to improve a lot. I was listening to a podcast today where Sam Altman, who was saying like the improved chatgpt -3, about 40 in the orders of magnitude in terms of size, performance, and things like that since they started, I think 10 times for chatgpt, three and a half. And I think open source is going to catch up, I think, and I think that's the hope. But yeah, it's also like we go back to this when we are thinking about Livebook because what I want is for open source tooling. But when I'm building a feature for Livebook, I need to build the best feature for the users. And when I can use chatgpt -4 and I can immediately see the results and they're really, really good, I can use other tools off the shelf. They are not as good. So we are a small company. We are doing open source. So my options, if I have to choose for my users is going to be chatgpt -4 because it gives me the best result for the least amount of effort. It's there. And this is like, so we were back in like about my indecision about investing this stuff. Is that because I want open source, right? I want things to be open source, but right now the quickest return of investment is GPT. And then I am in this contradiction space, right? But yeah, and it's just, I think it's just patience. We have to be patient. And, you know, I think probably in one year and the whole thing is like, it's crazy to think about is that this thing has been happening for a year only, right? It appears that this thing has been out for so long, but it's a year. And I think like, if I'm back on the show in a year, we may potentially be having a very different conversation. So yeah, we'll see. Do you have any fear about this? Like even when, as you respond to that, you sort of had some, I wouldn't say like trepidation. But you sort of had some uncertainty. Do you have any like fear and uncertainty and doubt, the flood that people sort of pass around? Do you have any fear about this? No, not really. In the sense that I consider myself like very lucky, very fortunate or whatever, or blessed, whatever you want to say it. I think maybe it's a, I'm not being overconfident here, but more like thankful that I think whatever happens to me, it's going to be fine. I truly believe that what's going to make Elixir survive is the community more than whatever technological changes, unless there's something very drastic. I talked to my father about this, about investments, right? So like when Bitcoin was in the crazy, right? And then my father is like, oh, have you heard like about this thing that if you put your money there, like people got this huge return. And then I always told him, father, if we got to know about it, it's because it's too late, you know? It's like, or if something happens, right? It's like, oh, father, like if something happens, it's because like if something goes this bad, it's because it's going to be bad for everybody. So like, don't try to fight it, right? So again, like, unless there's a very major change, I think I will be fine, right? So I'm not worried about me in the sense, I always think more about, it's more about ideals, you know? Again, like I like to say, well, me 10 years ago, that's where my trepidation is if things go like closed source, you know? And those things, they happen by, we don't see the results. Like I think another polemic topic about this, it's like, hey, I use Chrome. As soon as Chrome came out, today I don't use Chrome anymore, but as soon as Chrome came out, I immediately swapped to Chrome, right? And if I had known that this would lead to a point where, you know, Google is in this position where it has a lot of control over the browser, over the web, right? And over how we use the internet, like 10 years ago, I would probably not have used Chrome. If I could have seen it, right? Or so I think that's where my trepidation comes from of like things being closed source, like the developer experience. So today, another example today, Elixir was the first programming language that GitHub had the new navigation, code navigation things that were provided by the community, right? So there were some programming languages, and there still are, where they have very good navigation and exploration on GitHub UI. And the path for that, to get that feature, to get that behavior was, and I'm very thankful that the GitHub team, they discuss with us and allow us to do that, but that's closed source, right? And GitHub plays a major role over, you know, how developers use, right? So it all comes back to this idea of like, if you want to provide a good experience for your users, how much of that is behind something closed source that you have no control, and you are depending on somebody, you know, paying attention to you, like, or you having a contact or, you know, me having a name because I was very active in the Rails community that GitHub uses like 10 years ago, right? Those are the things that, but I, like, I feel lucky, you know, but it worries me, right? Like how much is being closed, right? How much is going to be out of our control? And then the trepidation, I guess, is like, what does that matter for the small Jose out there, right? Like what's the start building his thing today and they won't be able to. Well, you killed the vibe there, Jose. Oh, thank you. That's me at parties, you know? Not invited. Just kidding. Oh, funny. All right. Well, let's, uh, should we try to close on an up note on a high note on a, on an upper? What's that?

I had no

idea. I think we should end it right there, Adam. Don't you think we ended on a high note? She's a knife tactic there. I love it was higher. I don't think it would be good for the listeners. I think that was plenty high enough for me. Adam, were you satisfied with that? That was a high note, literally. Yes. And, um, I dig it. Yeah. Yeah. Like trying to go put our back ourselves back into high note. Right. We were going back to the discussion, right? Like it's all about open source. Right. And I think if we can, if we can continue investing, if we can continue patting on open source and open source models, right. As Adam said, I think you had a very optimistic perspective there about, you know, while we are still investing in tooling, right. We may still be ahead. I have, this may be a horrible idea. Okay. This may be a horrible idea, but I started, because my arms, they are, they are hurt. I started, uh, I went back. I go back to reading more and I started, uh, reading doom, the book. Right. And at the very beginning, it has a, it has a quote, which may make the mood even worse. Okay. But, uh, let me give it a try. Let's try it. So I've marked it because it was, uh, so it says once men turned their thinking over to machines in the hope that these woods set them free, but that only permitted other men with machines to enslave them. And how old is doing? It's probably like 70 years old or something like that. Right. And I think, you know, maybe it's some nice food for thought. Maybe it's some horrible food for thought. But, um, when I read that, I was like, huh, that made me think, right. You know, especially with everything that is happening with AI right now. Yeah. It's on point. I liked it. I think maybe we should just end it right there. Just let that be the final word. Yeah. You know, I dig it. I dig it. No need for further doom and gloom. We've already got it. Jose. It's always fun on your high notes and your quotes. I'm looking forward to may for elixir one dot 17 for your one to 3 % solution, uh, deployed out there into my code. I'm, I'm, I'm looking to make my code a little bit better. So, uh, thanks for all the hard work you've been doing on the language and all the things, man. Thank you. I am a very big proponent of under promise over the lever. So I'm hoping it will be way past 3%, but that's what I'm going to promise. Uh, the 3 % and yeah, I hope people will. We'll try it out. And yeah, as Adam said, we'll continue improving our tooling and that's what we, we can do for sure. Very cool. All right. It's been awesome. Bye friends. All right. All right. That is our show. Thanks for hanging with us. Next week on the change log news on Monday, best selling author and recovering data scientist, Joe Reese on Wednesday and on Friday. I'm not sure, but Adam and I will be at that conference in Austin, Texas, the first part of the week. So I'm positive we'll have some fun stuff to share with you by the time we get back. If you're headed to that conference to connect with us in the hallway track on the main stage at 4 PM on Monday and at game night later that evening. Seriously,

do it. Once again, to our partners at fly .io, the home of changelog .com to the beat freaking residents, break master cylinder, and to everyone of you who helped make change logs community, the absolute best the internet has to offer. That is all for now, but let's talk again next week.