Amos: Welcome to Elixir Outlaws, the hallway track of the Elixir community. José: I came up with a very bad joke two days ago, but I was very, very proud of it. Amos: This is, this is definitely your forum. José: Which Pokemon gets two of everything? Amos: No idea. José: Pika-Two. Yeah, it was very proud of like, like there are three things that I really proud of life, like, uh, my two kids and all the top, this joke. Amos: Perfect. So should we, we grab, uh, one of the real questions here? Anna: Yeah. Let's do it. José: Shall we get started? Amos: Sure. So they said, uh, I understand that the official in quotes typing has been put into the hands of community. Are there any credible efforts being made in that direction? And are there any plans to integrate better with dialyzer and, or other static analysis tools like making them first-class citizens? José: Yeah, that's a very good question. And so there is a project, for example, coming from Erlang called, uh, Gradwell Lizer. We even had a talk at Code Beam Stockholm that may be worth investigating. So, yeah, so there's work happening from different places and I imagine it to continue to happen, but I think those things take a little bit, and I think it would take a while for something to come up as be solid, the support for the dialyzer. We will continue doing it for the community because I am personally not a big fan of dialyzer. And, um, and not necessarily because of that dialyzer, but because of things like the degration, it will be really complicated. I would love if we ran those things as a compiler code and not in a separate paths, but it would be really hard to do or require a lot of work. Um, the, something would have to improve on dialyzer side is to improve the error messages, for example. So, you know, uh, we had some ideas, some discussions on how we can do that, then, um, improve the Erlang side of things, but all those things that would take some time for me to do it reliably. So, yeah. So I think we'll continue improving in baby steps, let's say, but there's a lot of work that needs to be done at the foundation, which is why it doesn't happen as immediately. Right. It's not like, Hey, we're going to have these ready for 1.8. No, it's going to take awhile. Generally speaking. Chris: It feels like so much of that problem is just finding the right type algebra that actually makes sense for the language and allows you to interplay with Erlang. I mean, cause that was like the fundamental problem with doing, um, like Henley Milner, like type algebras. Right. Is that like you've had - it forced everybody to rewrite their code in like this way that no one actually did it originally. Um, so it never got picked up because of that, because it was sort of like you had to tell everybody to rewrite this code that they knew was working already in production. And they're like, no, I don't want to do that for to just make your type algebra happy or whatever. José: Yeah. And with Henley Milner, the issue is also inference. So, uh, we can't, we just can't do inference. There are a bunch of videos that we use today that they're not going to work without a bunch of extensions. So that would require people to type a prompt. And then that, that already starts being a no go. But I think people in Elixir community, at least they are willing to - cause that, like I said, like we are going to accept all code as valid. Right. And that's it. I think people in the Elixir community. They're willing to say, it's fine if some of my code, I mean, if I opt-in, right, it's fine. If some of my code did not compile anymore when I add types, but then we need to figure out which way to do that clearly, because we can just not release an Elixir version, say, Hey, now 30% of the Elixir community is Apple Pie. Right. Then that would be a nightmare. So we need to find a way to do this. And that's when I started looking at wall type things, which do feel like it's going to be a really good option, but it's a very long and extensive research project, especially, uh, starting from scratch. But I think, I think we can afford, I can, but that's the thing I think we can afford to start from scratch. We don't have to, um, stay with the decisions of the past and say, Oh, all the code that was written is going to work. Like, no, if you opt into this, some of this is not going to work. And that's fine. Amos: So is the intention is - as that develops along to, to use the same, um, syntax that's currently in place that dialyzer uses or, or would it be something new? José: I think we should explore both ways, but I think we did some stakes. Like we need Alex, her team did some mistakes when we brought the dialyzer, uh, type specs, uh, into Elixir because of how we handle variables and this kind of stuff. If I could do it today, it's one of the things that I would do it differently. I'm not sure quite how different it would be, but, uh, I think we did some mistakes in this area and, uh, we would have to, to amend them and maybe we can even amend now and support both ways in Elixir for awhile, but at the moment. Yeah. Um, I would, I would explore both because, because I, I mean, I would explore using the types of facts or maybe something in line or something like that because, uh, I think we should explore. Right. And try different things. Amos: You said something about making, making mistakes. It kind of leads to a different question is in developing a language is that is used by lots of people. How do you handle whenever you have those mistakes in now, people are semi depending on them being there, like, like, what is your approach? José: Right. Yeah. Just, ah, that's, that's so tough because you just kinda like, it's a thing that you have to learn how to handle it because you can't. So I have an engineering background. Right. And why did you teach at engineering school is like, well, you do have some parameters and then you have the specification and try to do something that conforms with those parameters. So like, my brain has been wired to do that for years. And then, but you don't have, you don't have the same for programming languages. Right. We do have our performance, which is great. That's why I work. I like to work so much on performance because I can do some stuff in like, Hey, things are twice faster now. It's exactly what they were expected. Perfect, beautiful. Right. But like, well, you know, garden's using the language and the features in the language. Why do you add whatever you remove? Yeah. There there's like no metrics in there. So sometimes people do ask and I've learned to let go a lot of this. So at the very beginning, you know, after one that zero per mile, people would ask, why did you do this? And that would be, would send me like very long, like rabbit holes where I would try to go back and think about the disease. Like, Oh, we decided these, but what if I did differently? And, and then I would like, Oh, but then it would affect that. And we'll do the fact that, and then that's why they would say, Oh, I guess what we did. Uh, it's what really makes sense. But it would go into this ver long trips. And, and now I'm just like, you know, it is like a lot of the things, um, it is what it is. Right. So, uh, and then sure that we continue improving things and things that, so on the things that we talked, uh, I talked at the Elixir Conf keynote was exactly about the Elixir tool. And one of the nice things about Elixir is that because the language was made to be extensible, uh, some of the things that we did wrong, we can actually just fix them now and deprecate it. Right. Deprecate the old ways introduce a new way. So we are kind of like, there are things that were wrong and we are improving and making them better along the way. Right. But, uh, things in the very core then, yeah, we wouldn't be able to change them. And I've kind of like, I've made my peace with it, but that's kind of what I would say. And for everything that we can tackle that we just stuck with it. Amos: So if there was one decision with, with elixir that you've made that there would be no consequences, if you could just do it differently, is there anything else - José: You're not sending me there. You're not sending me to the rabbit hole. No, no, no, no. Amos: Go ahead. If, if, if at any point we don't have a question or you guys want me to, I have a whole list of them now. Anna: Well, is there anything that you're haven't or maybe you can't talk about? I don't know if you could talk about it, stuff that you haven't announced yet, but there are, there is there that you are, um, excited about improving now that you all are talking about what things can be improved. José: Right. So I can tell a little bit what I'm working on, if that uh it's it's interesting. So, um, so as actually like at the keynote, and then they're coming back and I said like, uh, the last big theme, I think we have to tackle in elixir itself is deployment. After that, I think we are pretty much like over, let's say we're going to do obviously improving things, but in terms of big features, that's supposed to be, and sure, maybe you're willing to research like systems and you're going to spend like two or three years researching something that may be part of the lesion up, but that's like, really long-term right. Are you saying like, you know, off practical things that we should expect in the short term deployment is the last one. So, um, and to me, this goes a little bit back, like when the first milestone we had for Elixir here, the first big milestone was sort of Elixir zero. And that happened in like 2014 and after release Elixir zero, uh, like my next milestone was to help like the infrastructure and the community right throughout the community grow. That's why I started working on and contributing to purchase like plug Acto, Phoenix, and so on. And especially because, uh, and there are a bunch of projects related to the web because that's the area that, um, my company bought a farm attack works at. So we wanted to have a good for my company as well. And I, at the beginning, I was very naive. I was like, you know what, I'm going to, I think we are going to do this work on the infrastructure for like two years. And then we, we can move to the new areas, like to green pastures, but now you're like three years maximum. Right. But now we are 2018. It's four years later and we are not done quite yet, but I think, I think we are, we are really close because so, uh, I think the, one of the main complaints that we have about Elixir is deployment. And the other one looking at multi infrastructure in general is it's about instrumentation and gathering metrics and showing that in a nice place. So, uh, coincidentally, those are the two things I'm working right now. So deployment, uh, Paul from dockyard, uh, he worked on the stereotype, uh, zero, and he did some improvements and tried some ideas there that eventually are going to be part of Elixir they'll know exactly who is going to this work, uh, what exactly is going to be Elixir, but some of it's going to be there. He is. Uh, he has currently sent a request to our Erlang OTP, to try some new ideas out. So there are still some error to be explored there. So that's really nice. And I'm working with, uh, Erlang solutions on a project called telemetry, which is about, uh, instrumentation. So it wasn't a nice darling solutions folks. Uh, they saw Chris' keynote where we S where he said he wants bad instrumentation. And we're like, Hey, we'd love to do this work. So we have been work, uh, we've archived dish. Um, here actually, he leaves here in Cracko he's from the office of human Preco and he's doing a fantastic job. So released a very tiny library called telemetry, which is by design meant to be very tiny because it's to be, it it's meant to be a core that everybody's going to depend on. And with that, you can dispatch events. That's all it does. That's why it's so tiny. I always say like, Hey, I'm the batching light I'm dispatching. For example, like there was a request in Phoenix. So Phoenix would say, here, here's a request. This is how long these requests took. And here's some metadata about this request, by the way. It's like how, uh, like the, uh, which controller, which action and this kind of stuff. And that's all there is to it. There's nothing more. And so that was the first step. And then he worked on something called a telemetry puller. So this is the second library. And the puller is because there are some metrics that they are not events per se, like how much memory is my VM using, right? You don't have a metrics. You don't want to have to admit an event every time you change the memory. Every time you're looking at something. So what you're doing is that your, like every one, one second, you, you get them that measurement and publish it. So that's the other project. And now he's working on something called telemetry metrics, which is just a collection of metrics that tell us exactly how those events they should be ever gated. So our idea is that we'll ship like with those three libraries, and now the ecosystem is going to provide things like telemetry stats, the telemetry prom, a fuse that gets those events, gets how those events are being are meant to be collected and send them in whatever way you want and whatever way you prefer. So we have be very careful to not prescribe any architecture because each metric too like that we use, like sets the probably fields. They have very different extras of how the data is consumed or publish. So we make a scene that's very loosely coupled. And, uh, and yeah, so right now those three libraries. They're almost frailty in the sense that, you know, the base is there for people to try out and we are working on implementing like a first reporter or something like that. And what people should expect is that so actual trees already, uh, using telemetry to publish the events, what people should expect is that I hoping Phoenix walnuts five, we will be able to we'll have a we'll ship a really small module, hopefully like 20 lines of code that stays all of the metrics I did once back in the machine. And then by default, everyone say, Oh, wait, wait to push, these two to code, because that is going to have a page that shows these as keys on beta or as a dashboard or something like that. But if I want to say actually what the push, this is, that's the, it should be like a one line of code change. That's like the ideal goal we are going for right now. And then I hope that with their work in the climate and the work in instrumentation, I think like in 2018, when the year is over for those things to be like water under the bridge, right. It should be solved, should not be a problem anymore. And yeah, so that's kind of what I'm working on right now. I'm also working with, uh, Michał. I'm actually more as a mentor. And, uh, Phoenix got a grant from the Mozilla there's that Mozilla open fund or open source based grant, where they sponsor a bunch of different projects. And Phoenix is being used inside the mixed reality, uh, team at Mozilla. And, um, and we got a grant to work on Fire Nest, which is so Phoenix. It has like all these, uh, abstractions for like doing distributed pubsub for tracking, uh, state across nodes with presence. So, you know exactly who is connected in which node, but those are very high level abstractions. We want to break those down into smaller abstractions and Michał was working on the, on the finance project. He gave a very good talk at Code Beam Light. It's a very good talker and recommend people to watch it. That explains the goal of the project and where we want to go into it. Um, but yeah, but this is more of a, like, you know, improving the state of art that we have right now, rather than, um, something that is really fundamental to the infrastructure, but it's also nice. It's, it's nice work. Chris: We're, we're, uh, we're really excited about all the telemetry stuff. Um, we've already started using that in a couple of things, uh, internally, um, cause it just makes our yeah, because it makes our lives so much easier trying to get metrics out of some of these, um, some of the libraries and stuff like that in a unified way. Um, so yeah, that's, that's been, we've been following that and using that we were using a lot of that for the OpenTracing stuff that we've been working on as well in order to like get traces out of this, out of different parts of the system. Um, so that's been really cool. And I've been sort of following Fire Nest from a very far distance. It sounds really interesting. José: No, I would just say, like I said, I start to have data about it and issues in production. We'll love to hear it. And we did a bunch of profiling, which marketing and our initial implementation, but nothing beats real load. Right. So Chris: It'd be cool if people pick it up and start using it internally and their different libraries and stuff. Um, just because it, I mean, being able to like, it's, it's definitely one of the things that I feel a lot of pain, um, in, from sort of, um, the libraries that maybe get like less usage, like obviously like plug and Phoenix and ecto, like get a ton of usage. And so those like have a lot of attention, some libraries that are like less, maybe like less common to everyone stack often don't like publish hooks and stuff like that, to be able to get into instrumentation details out of it. Um, and so I'm hoping that more of the community starts, you know, relying on tools like telemetry, that kind of stuff to get, to have like a unified way to get those metrics, um, from lots of different places. José: Yeah. That it's a bit too soon, I think. But I think like when were these one, five and Phoenix will start officially using it? I think we'll be good. So for example, right now we are discussing moving that telemetry core to Erlang and actually implemented in their link because then the Erlang libraries will be able to use as well. So, uh, and, and th and this is great, right? Because otherwise we have this Elixir thing and then you can only get data coming from that Elixir libraries. So if you can actually get everybody using it and then, you know, and then, um, and the other, other library start to using it as well, that will be able to consume the data coming from everywhere. So I think it's, it's a good move. And, uh, but yeah, after, you know, yeah. Uh, after this is over, I hope, uh, Denmark people can stack, depending on it does something like that. Chris: That feels like a really interesting, um, project, not telemetry itself, but there's something else you kind of alluded to, which is like writing it in Erlang so that people in Erlang can just take advantage of it with, without, without any like issues. And that I know that there's been discussion of this in the past, but that feels like a really, um, worthwhile project for somebody, uh, to, to spend some time on, which is like, thinking about how, and I know people have thought about this, but like really, really focusing on how do we get a tool chain. So that it's real, it's the interrupt between Erling people wanting to take advantage of elixir libraries is, is really, really low. Um, like the difficulty level is really low. So because right now we get to take advantage of all the Erlang stuff, like really easily, but it's a lot harder for them to go the other way and use like all the Alexa tools. Um, and like I said, I know that there's been a bunch of discussion about that. Um, but it'd be interesting to see, like what would come out of a pro uh, out of like some efforts there, because I think that could be super useful. José: Yeah. I know, I know Eric has been working on some of those things with the rebar team. So at least like the compilation of all the Elixir stuff, it's straightforward. Um, but in this case we thought like, even if we compiled, even if we can compile Elixir, if this thing that's supposed to be a very lightweight dependency, if it, uh, if all their link projects in order to bring it, they need to bring all of Elixir that it's not lightweight dependency for dealing with developers. That's why I decided to go. But people, they complain a lot about things like, um, that Coleen Elixir modules, the syntax is, will be Erlang in their link. Um, that's one of the complaints, but then there are things that they're not going to work, but they can't work. I think, I mean, in my mind they can't work like a macros, right? Like macros, you know, it's an Elixir thing and you can't, there is no way it could work otherwise. Chris: Yeah. And the calling syntax is like, it's fine. I don't know. Uh, it's, it's, it's not as nice as just calling like an Erlang module, but it's not like it's not that bad. José: Yeah, that's my opinion because I defined early macros. So I do like define a macro in Erlang. And so, for example, Callie Curnow in - so if you go to the Elixir series called Base Elixir to the compiler. And every time we call Curnow, it's like a question mark and Curnow, all lower equate case and that's it. Uh, so to me, it's not a big deal, but, uh, some people, they still don't like it. Amos: Maybe some more documentation around that way might help. José: Yeah, that's a good point. Chris: But I, I take your point about telemetry, maybe not being a great, uh, a great exemplar of a library where that makes sense, but I do, I do think having the ability to interrupt would be really interesting, like to make that really clean, um, from at least from the perspective of like, needing to compile the like Elixir dependencies and having that be pretty straight ahead. José: I think a good example could be for example, Gen stage, which is a very small library, but it can be very useful because an obstruction that as far as I know, we don't have in Erlang, so people they can make really use it. And it's not supposed to be that far from how an Erlang thing would work. Just the module name, everything else they're just callbacks. So that could be a potentially good candidate for like, having really good integration. I know there are other libraries, I think. Um, what is the name of the, the, the benchmark library that, uh, from Pragtob and the name's escaping me? So I think they did so being Erlang degration, but I think the defining module that proxies to relics or module or something like that, I don't recall, but they have explored this area if I remember correctly. Chris: I remember some people talking about, um, wanting to use uh James's, um, connection library in Earline and that being a thing that they wanted, which is another use case for... Anna: James Fish, fish cakes? José: Yeah. Yeah. But, uh, the connection library it's, uh, it's supposed to be, it's supposed to be that it's no longer meant to be necessary now that they added the, the state machine Erlang and, uh, and we've got the, the continue, uh, callback and they'll continue in, in indigent server. So a lot of the bookkeeping that the connection library was doing around that today can be solved easily with those two or that's. I don't, I mean, I don't know, per se, I'm telling what James told me. Uh, but that's what he said. Chris: James's definition of things that should be easy to implement also I've, I've found aren't necessarily always a, you know, universally easy. José: Yes. You, you, you agree like, uh, so a lot of the work on that little tree, so I had to do a lot of work on the big connection, which I wanted to do anyway, because we had like a, uh, bus number of, one thing that, the project, so it was James. So I did the bunch of the words of grade. And then, and then he would be like, Oh, that's easy. And then I'm like, no, I, I'm not sure. I agree. And then everything, I would think that it's easy, I would say, no, I think that, then he's like, no, I don't think that's easy. And I was wrong. Every, I already said it's easy because he was able to see like, uh, like 10 problems I had over. I was so, so, so yeah, I, uh, James is, uh, is definitely really smart. And if you say, if it's easy, then I totally agree with you. Amos: So I, I had, uh, another question from the group they were, um, there there've been a lot of changes recently in the, uh, makeup of the Ecto team. What would you like to see, uh, in Ecto from the community itself? José: Well, at this point, um, okay. Uh, I, I would say nothing, but that's not a nice sensor, so let me, expand on this a little bit. It's nothing, but it's not nothing in an. It's so we've Ecto three. We announced Ecto to be stable API, which is a way, you know, there are many reasons we can talk about this reasons, but it is a way of, uh, saying that, you know, uh, it's, it's a stable way - it's a stable API what is here? It is one disease. And, uh, we want to give a lot of people opportunity to try things out, explore other stuff, right. And everybody who is using Ecto today, you should expect that what is there is what is there? And we're not going to have major changes from now. One, we are still going to continue to maintain it. If we have performance improvements that we need to do, we are going to do all those things. Right. But when it calls to like two new features and a drastic improvement, uh, people should not expect those. Right. So if you feel like, Oh, actually Ecto API, it's messy. There's a better way to design all days that like, it's great for the project. Try our new one, but it is what it is there. Um, we know we, like, we did our part. Uh, we did a really great job of also bringing up all the infrastructure and we're still working in Elixir. I work on the, my, uh, ex quell, uh, drivers. So white deck, Hazel bottle from a deck is working on it. So the foundation would be really solid. So if people want to try new ideas, they can leverage the drivers. They can leverage the big connection. They can leverage everything that's there. And, um, yeah. So that's the, that's the long version of nothing. So I think there's a bunch of things to do, but not enact per se. Anna: Where you like to see input from the community or participation from the community? Is there an area where you're like, Oh, okay. José: So no, because not really, because I, to me, like my opinion, when it comes to things that the community is tackling and what the community needs to do, it doesn't matter. Right? Like, so I like to give them nerves and example, right. If somebody had asked me is, sorry, imagine the Frank, if he, he asked me Frank, and just like, Hey, should we create nerves? I would be like, uh, I have no idea what were talking about. Maybe it's not a good fit. Right. It would be, I wouldn't be like, it could like discourage and motivate them, uh, because I don't actually understand the domain. Right. So, you know, work on whatever you want to work. Like, whatever makes you happy, whatever you want to explore, new ideas, just, uh, try it out. The thing for lixir per se, uh, it will be like the deployment. That's the theme that we would need help, but everything else it's really up to you, like explore or whatever people want to explore and play with and imagine. Amos: I can dig through here, there, there are, everybody's talking to each other and answering each other's questions now. So it's getting harder to read them. Are there any other language constructs that you've been mulling over lately? José: No, I I'm. I'm looking. So, uh, after the, uh, after the keynote at Elixir Conf, uh, Jean Freeze, he came to me and he said, he will say, you are a genius. You just told everybody that you're not going to do anything for five years and everybody clapped. Yeah. Uh, I, I'm looking, I'm looking for, for holidays. Uh, but, but that's really, there are some things that, uh, so I said, like the things that I'm working on right now, they are some, uh, some projects that, uh, I'm hoping we are going to announce, um, the first, um, quarter of next year. So it's actually very interesting because we have been, so we wrote like gen stage and flow and we analysis do back in 2016. So we set out gen stages, how it can process data concurrently and with back pressure. And it's a very low level obstruction, but it works. It's there. And a lot of people are using it. And then we announced flow, which is idea where you express, like how you want to work with the data. And then we would, uh, you know, would create all the stage, all the whole pipeline for you. And these would go for the pipeline. And when we were being able to flow, we were thinking a lot about things like a spark and flow right now runs concurrently. And then we thought, well, eventually we can make these run in a distributed fashion. Okay. So, uh, that was our, um, that was our thought at the time. It's just that making it run in distributed fashion is a lot, a lot of work. So, uh, we never got to do that part. And then what happened is that, um, so, uh, this year about, uh, May or June, we launched the new service, a platform with that called Elixir development subscription, which is where companies, they have a open communication channel with the engineering team at the Platform Attack. And, um, and then we started to, to work with a bunch of different companies and, and this is something that was already in our mind. And, uh, it became really concrete as we start to work with all these different companies that a lot of people they are working with just moving data around, right. He's also sort of like mathematical processor of data processing and the level of spark where you may want to do things like or things kind of stuff. No, it was just like, Hey, I have a bunch of data in Kafka or with mEq and SQS. And I have to process it and putting the database, sending the Mayo, but in another queue, all this kind of stuff. So we noticed that people, they were, uh, to meeting like this pipeline to process this kind of stuff all over again, sometimes like making the same mistakes over again. So we realized that, um, there actually a common architecture and a common way we can solve this and we are working on, we have prototypes working already, but we're working on abstracting, all of these. So something today that takes like 300, 400 lines of code because you have to assemble the whole gen stage pipeline. So we can do like batching rate, limiting, uh, confirm, because when you're working with us gas, for example, you don't want to take like things from the Q1 by one that's expensive and expensive, like in all kinds of ways, it's going to classroom where money is going to be as lower. Right. So you'd let everything in batches. So we have to have this idea of batching partitioning. So we have been working on these and we hope to reduce this problem. So I it's like eight, 20 lines of code problem. Um, yeah. So that's one of the things that we are working right now, just something that, uh, we are excited about, but other, yeah. But other than that, like when it comes to the things that have been involved, right. It's like I, through his deployment, I went real consider fixing bugs. I'm actually heavy. I don't know if you saw it. I started live streaming. Amos: I missed the live stream by about 10 minutes. José: Oh yeah. So, um, yeah, so the timing is not good. I'm still working on the time because I do like early morning for me and not mine. So today was a bit late. It was one afternoon for me, but I know a lot of people in the United States there'll be either waking up or completely asleep. So you feel like if I were in San Francisco, so, uh, it would be really hard. And allies are really motivated at waking up like 5:00 AM to watch me speak, which I don't expect anybody to do honestly. So, um, but yeah, I'd be, I'd be live streaming, like fixing some of the Elixir bugs and that has been like, uh, really, uh, really exciting. Um, but yeah, you know, part of this project is I really want to put them like on the maintenance shift, uh, more than, than everything else. And, uh, let everybody, including myself just work on new ideas, new problems, new projects, and move from there. Amos: So, so, so going to the live streaming, um, what was, what was the original motivation for that? And, and what have you seen response wise so far? José: Oh, so, uh, my brother, he is actually my brother and my mother. They are both, uh, life's tremors in some sense. So, uh, my brother, he's a chemistry teacher and in Brazil, we have these, uh, we have this early annual exam if you want to get to a university. So you do one extended that, that is valid to almost all universities. And there's a bunch of, so to say he's a chemistry teacher and he, for a long time ago, like, I don't know. It was probably, I don't know, 10 years at this point has been a long time. He has been giving classes online. So people they pay for those classes. So he has been doing live streaming for him for quite some time. And he has always liked told me like, Oh, you should live stream. Right. Or you should like record classes. You should sell courses online and this kind of stuff. Right. And, and then his like you're going to make a lot of money. And then I'm like, you have no idea what you're talking about. But, uh, but, um, yeah, so he has always taught me that, but, uh, like two weeks ago he came in, he said, you know, you should. So he, he did the same beach, but he said different. He said like, if you did this, it's really going to be good for the community or something along the line. Right. Because he was like, Oh, you can make money with you. And then I'm like, no, I'm not, not, I'm not like motivated for doing money like this way. It's like, I don't think for me it would work because I have like, um, I don't feel, I personally would work under the pressure of producing content every week, which is probably something that you can resonate very well. Like if you have like this commitment and then you need to produce in this context, I don't think it would work for me personally. So it never clicked like when he was talking to me about that. But when he started talking about the community and how it can help the community grow and have people motivated. And then I like, yeah, that makes sense. So I'll just give it a try. So, um, you know, I just just started doing it. We had like four sessions, I think at this point. And we have about, um, 50 to 80 people live, which is really great. Uh, and it's great because, so one of the things that I noticed is that because I have to explain everything I do. So for example, we, the first one we did, I was fixing a bug that I don't remember anymore, but because I was explaining what was the bug and how the fix was working. I actually found out something that would break because of the new solution. And our test suite is not patch, but it did not catch, but the whole process of explaining the thing, uh, helps make it clear, Oh, there's actually a bug lurking around and we'll probably get this bug reported as soon as the releasing release can date or something like that. So it has been really fun. Uh, like two days ago, one of the things we're working on, uh, the solution to the problem we were working on, came from somebody in, uh, uh, in the chat room as well. So I think it has been a really, really productive, uh, even productive in general. I don't feel like I'm wasting my time in doing that, or our data would be faster if I was working by myself. So, uh, in that sense, it's, it, it has been great. Chris: So funny, you talk about like, not necessarily being super motivated by money and how that can actually like turn against you, because we've literally had that conversation before. Um, because like we've intentionally made the decision never to like run ads or anything like that, um, or take sponsors or anything, because then it would be like an obligation to show up and not to say that any of us would like not want to get paid necessarily for doing this, but at the same time it would change the, it would change it into this, this like obligation that we have to perform for someone else now. And then it would like add all this pressure to it where now we can just do it. And it's fun. Like maybe it helps the community in some ways, one way or something like that. That's so funny. Yeah. José: That's exactly my thought process. That's exactly what was behind it. I was like, I, you know, I I'm really having fun and it's right. Like maybe adding this competence is going to take the phone off Amos: Now. Now we, we did say no sponsors, but I do have to jump in cause you reminded me and I forgot twice. Uh, Tonya and Keith, um, from Elixir Cards, uh, would like us to give away a pack of their cards on every episode. Anna: That doesn't count. Amos: I know, but we're supposed to do it this episode and I don't, I don't have any, any plans for how to give it away. José: Hey, you have people asking questions. You can just give to whoever asked the first question. Okay. Amos: Okay. I will do that. And, and, uh, that that'll be pretty easy. Thank you, José. I see. I knew if we get smart people in the podcast, they'll answer our questions. Chris: These cards are great. They're fantastic. Yeah. I got a pack as like a speaker's gift from Gig City and I love Amos and I, we were like, let's check these out. And then we sat down, um, because Amos was staying at my house for Gig City. So we just sat down on the couch or whatever. And I was like, what is the answer? And then we actually went through a bunch of them. And before we realize it, I mean, it was very late at night. And before we'd realized that we'd already gone through like 20 and we just kept going. And we were like, I don't know, we need to like crack a rebel. Amos: Some of them were pretty tough. Um, and, and I, when they originally came out with them, I had just met the two of them, uh, in, in Florida at, uh, Elixir Days. And so that was like right as they were starting to print them. So I bought the original all of them that they had. Uh, and, but they have more now. So they want us to give away one of each until we've gone through all the packs that they, they sell. So thanks. Thanks José. I'll I'll uh, I'll let the first asker, which I will say his name. I don't know if I should, but I'm going to anyway, because he put a question on a podcast. So that's what he gets. It's uh, Jeremy Owens Bogs. He's from the Kansas City Elixir Meetup group. José: Congratulations. We're talking about live streaming - have you ever thought about some live participation in the podcast or something like that? Anna: No. No. I mean the only life thing they've ever done was the recording it, uh, Oh, the Gig City. Amos: It would be interesting. I did that on a, another podcast once I just, um, in the middle of recording, we didn't have much to talk about. So I sent a message out on Twitter and asked who wanted to be on our podcast and then we just had them. Chris: Yeah. I'm not sure how we would. How would we, I guess you can just hook that stuff up to Twitch using what's it called? José: Oh my God. I became my brother. I'm convincing people to become livestreamers. Anna: Um, well we know you have a hard stop. So any, any final thoughts? Just say anything else you wanted to share before we end for the day. Thank you so much for coming on the podcast. José: Yeah. Uh, really glad to be here. It's a pity that it was short because it was really fun, but, uh, I'll blame this. I was telling him, uh, this is daylight saving time, um, fault. Cause when I scheduled the meeting, it was when it was the one week in a year or maybe the one of the two weeks in the year where the United States and Europe they're actually at different. The time between the United States and Europe, it changes by an hour. And I scheduled a meeting at that moment and I just casually at the wrong time. So, um, yay. Timezone. So, all right. But, uh, thanks again. I, I think my connection was not good today. That's why I stopped the video, but I recorded everything on my side. So hopefully everything is going to be manageable. Beautiful. So have a good day. Amos: Thank you so much for coming. José: Yeah. Anna: Bye.