*intro music*


CHRIS MCCORD: Hey, sorry. I was arguing with people on the internet.


CHRIS KEATHLEY: After all this time, you really think you’d learn not to do that.


ANNA: *laughter*


JOSE: Better than working, right?


KEATHLEY: Is it, though? Is it?


JOSE: Yup. That’s a good question.


MCCORD: That’s what I was doing. 


ANNA: Now I have to feel like I have to check Twitter to see what happened.


KEATHLEY: Did you hear me typing? That’s exactly what I was doing.


MCCORD: Someone tweeted, “These days I feel like the Elixir community is just focused on code formatting and blog posts about how to use Ekto. Thumbs down”.


AMOS: Ouch.


ANNA: That’s not true.


MCCORD: I responded with literally the - the most recent posts on the Elixir form are about machine learning, virtual actors, gen stage and flow… And anyway I had to respond.


JOSE: And it’s just got… It’s so… I just got - The Elixir Raider. I just got it and was going for the links and it was like two or three about distributed systems, and that’s not accurate at all.


AMOS: You’re much better than I am. I would have responded something like “But look how pretty our code looks with the new formatter”.


JOSE: Yeah, so one is about distributed transactions, the other was about introducing Horde which is a distributed supervisor, the other is about deployment - it’s not that great, but like the latest things in the community is like - if you look at it…But, anyway…


ANNA: Thank you both for having the time. This is awesome.


JOSE: Thank you for having us on the show.


AMOS: Yeah, it’s pretty neat. I was talking to somebody this morning and they - oh, it was actually Chris and Anna. My day is gone. And they asked me if I had - I said I had not much to say today, and they asked me if I was having hero problems since you guys were coming on. And I said “no, I’m having ‘what the hell have I been doing for the last week’ problems.” 


KEATHLEY: It’s Wednesday.


AMOS: Too many busy things.


KEATHLEY: No, wait. It’s Thursday.


ANNA: Exactly. I had that same problem that morning. So, Chris -


KEATHLEY: Wait, we’re going to have to clarify which Chris.


ANNA: Keathley. I’m just going to call you Keathley this episode. I know you had lots of thoughts. 


KEATHLEY: I’m actually glad that you all brought up the formatter, ‘cause I have some questions. It’s on the list. I actually have a whole list here. I can just go down the list. This is really y’all’s show. We wanted to have you on the show to talk about things that are relevant to you. But before we get to that - 


ANNA: We’re gonna time-box Keathley, so you all will get time.


KEATHLEY: So I’m just gonna go down the list here. I have a few things that were picked - just randomly - and I wanted to get y’all’s thoughts on them. Just generally - I think we should talk about how Elixir is reinventing things from Erlang. I think we should talk about the application directory restructuring, we should talk about how Pheonix moved the web directory, Phoenix context generally, formatter, stream data, config…


ANNA: We have an hour.


KEATHLEY: Yeah… These are just topics that I randomly selected… It’s really your show. You pick where you dive in. I don’t think I missed any controversial topics. I think these are really the high points.


JOSE: I think so.


ANNA: We can say we’re officially starting, so everyone is recording.


AMOS: So we have Chris, and Anna, and me, and Chris Two, and Jose. We’re all here.


JOSE: Yes. My suggestion is that we call one ‘Chris’ and the other ‘Chris’, but we use those terms interchangeably. So it’s going to be like. Really productive and not confusing at all.


ANNA: Yeah, exactly. Let’s do that.


AMOS: So, we have opposite sides of the world here today, almost. San Francisco, Poland…


JOSE: Yeah, what time is it in San Francisco right now?


ANNA: 8:40. 8:38.


JOSE: Yeah, here it’s 5:40. So. Almost there. Off by two hours.


ANNA: Yeah, exactly.


JOSE: No, three hours. My math is off.


AMOS: And we know that Keathley has a big list of things to talk about.


ANNA: Or, Jose and Chris. Where ever you want to dive in. Like Keathley mentioned, whatever you want to discuss or have a chance to talk about.


JOSE: Yeah… There are a lot of things happening right now that we would be glad to share. Everything happens publicly, but coming on the shows and talking can help us explain things differently. So I will start with Chris ‘cause I’m keeping tabs on him. So, we’re supposedly working on the programming Phoenix book and are updating to the version one of four of the Phoenix framework, which still has to be released, but we’re working on that. Also what is happening on that side. We have Muscala. He joined the Elixir team at the beginning of this year. And he’s working on this project called firenest that - so a brief introduction. So Chris did this amazing job with Phoenix pubsub and Phoenix presence, and then we look at those things and we said ‘hey, we can actually generalise those abstractions, and instead of being something that works for the specific use case of the web, it can be a general abstraction that we can use for distributed systems. Muscala is the one who is pushing this idea forward. He’s working with Mozilla. Mozilla is actually finding how to work on this project and get those abstractions and make them more general. So, what was really nice was that at the Elixir Conference Europe keynote that Chris did - it would be really nice if you could include a distributed rate limiter, where you have all of the nodes counting but the data would be replicated between nodes and just yesterday we were actually making it work with the instructions that we have and it was like ten to fifteen lines of code - something like that, right Chris?


MCCORD: Yeah, it was a shockingly small amount. Yeah, Jose is very nice because he said ‘the amazing work that I did’ - so like. A common theme throughout phoenix is that I will go like a top-down approach where I have something to solve and I will solve it, and then Jose will look at it and be like ‘oh, wait, you actually built like. Six separate things, Chris’. It works really well. So, yeah, so this is a rewrite of all of the interesting things I’ve worked on, but in a good way - so, like Presence and PubSub ended up having a lot of big pieces in there that could be made smaller, and that’s been really neat to see the work that Michał has been doing - Like just yesterday, just by breaking presence down into like a replicated state - is what we’re calling it right now - just by breaking it down, suddenly this hard problem that I talked about a couple months ago at Elixir Conf EU was solved just using these small pieces of the same thing that I had just written in presence, so it’s been neat seeing how these interactions play out, and usually its me going top-down and not designing - thinking in smaller pieces but accomplishing my goals.


JOSE: Yeah, so if anybody wants to check it out, it’s the Firenast project that is in the Phoenix framework organization, and it’s a poorer class, so anybody can go check it out, drop some comments… Michał did a very good job also of locomenting the API - so he’s doing DDD - documentation driven design, so he’s writing the documentation up front so we can actually see the APIs we expect to work. So that’s really nice. And I am personally - so that’s like, things that I’m involved but not directly… Oh, so the other things that are happening right now, which is the Google Summer of Code. We actually have about five Elixir projects happening, and we can go over those. I am personally the mentor of a project that aims to add tensorflow bindings to Elixir. And it’s been really exciting, ‘cause I’m learning a lot and students are very productive. I don’t have any knowledge of that domain, so I think it’s worked really well because he has the knowledge of that domain, and I’m bringing the Elixir knowledge and we’re doing stuff and he just released a blog post that you can see - so if you go in the Elixir forum and search for Delsar Flex, you’re going to find the blog post, which is basically - so with tensorflow, you still need to train the models in bidone, because that’s where all it is, but after you train the model, you can load that model into Elixir land and then you can perry against that model and do predictions and that kind of stuff. So that’s really nice. And then lately, I personally am working on Ekto tree. So I thought Ekto three was going to be my latest - my dreams did not come true. So, Ekto three is my last attempt at a latest major version. And yeah - and it’s really interesting, so for example, we’re going for the third version, even though it’s older than Phoenix and phoenix is still like solid at one or so, and it’s funny, I guess by being closer to what our domain logic actually is, there are more demands for that thing to evolve. And be better, so… Yeah. We’re working on Ekto three. There’s a lot to talk about there and we can explore this as well. But I guess that’s it for kind my update - oh! I guess there’s also ElixirConf. Chris and I will be keynoting, so… My keynotes there are usually writing my thought process down, but in a presentation. Usually all of those things, they have been decided up front - which is good because we don’t want somebody to say about the next years of the language, “this is what I thought up like next week” - that would not be good at all. No, I really thought about this part of the presentation, but there’s - you know - I think… Chris Keathly, who was saying jokingly about the list of things that he wanted to go through, right, but I think one of the things that we are saying is that there are people who are having some sort of expectations or sometimes even some demands of where they want Elixir to go or what they want Elixir to be, and I have kind of the opposite thought of that - that… So, one of the things that we always say is that Elixir is accessible so that everyone can always get Elixir and bring it to their own domain. So, you know, no body should be expecting us to get Elixir and make it bigger and bigger, because the goal is exactly for it to be a small language that everyone can build on top. So everyone can say “oh, Elixir could be better at this’, and I’m just like ‘go ahead and make it happen - just make that thing be because our goal is to enable - we want to enable you to the things’. Our goal is not necessarily to provide the things. Of course we provide a bunch of stuff, especially in the tooling department. But with everything else, we need to enable, right, so, every time someone says ‘Elixir should do this better, so I went ahead and did it’, I’m like, ‘yes, that’s exactly the point’. Mission accomplished from my perspective. Alright. So. That was way longer than I expected. I am over and out. 


AMOS: So, you mentioned Elixir Conf and you and Chris both giving keynotes there, and that’s one of the things that I just wanted to thank you guys for is that both of you have a way of showing your thought processes in what you’re going through, and even when I think in the community there’s bit a little bit of controversy, you’ve always been very patient in trying to explain why you’re making the decisions you’re making, and Michał has even reached out a few times to try to talk through some of the decisions that have happened in the community and why they’re being made the way that they are, even if people aren’t seeing that or are disagreeing with it, and really bringing to light like ‘oh, this is the best decision with everybody’s information’. And us, being language users, especially for the Elixir core team is - being a language user, the problems that we see in the language on our individual projects may not see the bigger picture of what’s going on, and I think you guys are both able to give that bigger picture back, and it’s been really helpful and exciting in the community. So, Chris, do you have - wrong Chris, but that’s okay. I was going to ask Chris - so, um, Jose had listed off some of the things that he was talking about - I didn’t know if there was anything that Chris McCord here - maybe I’ll just say full names - that he wanted to add to that list that maybe we should talk about too.


MCCORD: I mean, I would just add that - Jose I think used the word ‘supposedly’ - working on the book.


*laughter*


MCCORD: Yeah, so the book - I wanted to touch on that briefly - the book is my main focus right now, but that’s taken like. Way longer than expected to get out. But like. Books are hard, so like… We’ve kinda been in this lock-step-release with Phoenix and the book, which we’re trying to get away from. And Jose warned me about this - never write a book about something you’ve created - so, yeah, so now every time we change the framework, we have to change the book. And we are putting effort into future-proofing the book as much as possible, and I’ve also just had other obligations. So the book is taking longer than expected, but it also is my main focus right now. So that’s the main thing. Outside of that, there’s some exciting features I’ve been playing with just very recently. It’s still too early to talk much about, but - I created Phoenix out of the desire to create like. Trivial real time applications, so I was doing that in Ruby and Rails and kind of created Phoenix to accomplish that, and I kind of wanted to come full circle and kind of realise my initial vision. Like, we have channels - this great real time layer -  and I wanted to see what we could build on top of that to make lots of real time use cases even easier than they are today.


KEATHLY: Does that play into this sort of - all the work with Firenest, or - and I know you’re not ready to like. Tease this too much, but is that more the direction that you’re going to make those things even easier to be picked up and adopted by people?


MCCORD: Yeah, so Firenest is actually kind of a different class. It is to enable people to build - to tackle a distributed systems problem. In this feature that I’m talking about is to build like, real time applications from the web front end perspective. So, basically, can I have a real time application without bringing in ten megabytes of Javascript and having a single page framer off the shelf. ‘Cause you know, exchanger enables you to trigger real time application, but you still have to write a ton of Javascript, so I think there’s a large class of applications that you want some rich interactive features, but not have to then throughout your standard web flow write a bunch of client side code just to get some real time updates. 


ANNA: That makes sense.


KEATHLY: So, man, I have so many questions about all of the things that y’all are working on, so I’m not actually totally sure where to dive in…


JOSE: Let’s do this.


KEATHLY: Let’s talk about - I’d actually like to talk about Ekto three. So… What are the big things you’re wanting to do with Ekto three that’s different from Ekto two. Is that just from input from the community or deficiencies that y’all have seen, or… 


JOSE: So, initially - and this is usually how I approach major releases - so most people use major releases as an exchange - sorry, as an excuse to break everything. I don’t like doing that, so I want to keep the breaking changes to a minimum. So, there are some plans - so one is - and it’s usually - if I am removing something, it’s something that has been deprecated in the past - so when Ekto - so Ekto is one of the - it’s probably the oldest, or one of the oldest Elixir projects. So, obviously when we started Elixir, we did not have the data type - date - calendar types. And we had - eventually we upgraded to run Elixir three which led us to those calendar types so we deprecated the old ones so we are now removing the deprecated code that was like the initial rationale for the way doing the 3.0 - right, so even before we were moving the deprecated feature, it could break people’s code, so there’s that. But there are a bunch of - and everybody can check the change log - I’ll leave it open here so - just to take a look at what’s coming, but everything is already there in the change log - so, yeah, that was the original motivation but there are other really nice features coming as well, so one of the things that in Ekto, when you have to compose queries, those queries have joints and that kind of stuff, the bindings are always positional, so that made it really hard to compose like complex queries, but now we’re introducing naming binding, so you can say “oh, I want to select something that I joined at some point and has this particular name” so this was a very requested feature for a long, long time, and now we’ve figured out how to do it. There was another really nice feature that was a contribution is now we lock the migration table when you’re running migrations. So previously, if you started two nodes and were migrating two nodes, they could race each other. So now just one node could run the migration, so this is really great because you don’t have to worry about those things. And, you know, there’s a lot of small improvements on the queriery part that you’re never going to use or maybe never heard of it, but sometimes it can be really handy, so. I actually did not know many of those things. So, for example, on Orderby, you can say like “Order by ask” and then you can test things like “knows if they should come last or first”, so now those things are supported out of the box, and um… Yeah. There’s a bunch of stuff. I really would look at the change log - oh! And there’s one - I said about the contact types - that’s going to be a breaking change. But another breaking change that we is we’re finally breaking Ekto apart. So, this was requested a lot as well. So, people were like “We want to use chainsets without using Ekto. Can we take chainsets out of Ekto?” And we’re like, this is really really hard because - I completely understand why people want to do this, but if we do this, what problems end up happening is that we end up having to break the problem set api over like. Two or three or four different modules. Because if you go to the chainset module, it has like things that help - that are useful in terms of database constraints, which is obviously a database concern. It has things that help you with associations. So we can’t like. Just say “I want to break those things off”. We can’t just do that. If we did that, what would happen is that somebody who is new and they want to start using Ekto - if they want to do anything new, they have to look at a bunch of different places to try to find what those were, and Ekto already has a lot to learn because you have to learn “what is a query, what is a story, what is a chain set”, and when to use those kinds of things, so you don’t want to do that and um… So, you know. So, people were asking “we should break it apart” and we could not find a way to break it apart, so we were kind of stuck there. So the thing that we realised though was if we take the chain set and the query and ripple story and the schema - it’s the four pillars we have in Ekto. These are the four main things. And if we put those in separate applications, it’s going to be hell to maintain because they’re coupled - one depends on the other to exist, and that’s by design - that’s on purpose - and then it would be hard to use everything scattered around. But we realised, though, we could actually keep those four things together and move everything else elsewhere. So, we’re going to break it in a way where you have the Ekto ripple story and the Ekto sequel - so the adapters - like, the sequel adapters - they’re no longer going to be part of Ekto. The migrations are no longer going to be part of Ekto. So when you say “I want to depend on Ekto, you’re going to say, “I want to bring in a mixed-molar core” and everything else is going to be in Ekto sequel. And this means applications are kind of going to have a breaking change - now they’re going to need to depend on Ekto sequel instead of Ekto, but that’s like one line of code change, so. The changes that we have in mind - it’s a major version - we’re removing deprecated code, the other one - it’s a one-line fix, and I think that’s really nice. And there’s also something that’s completely internal and like - 99% of the users are not going to notice is that we have this project called DB Connection which is how we talk to the databases, and it supports like different pulls - different strategies for handling the connection pull, and we’re getting rid of those strategies in terms of a built-in pull and we’re getting rid of those strategies in terms of a built-in pull that is more efficient than all the other ones, so it performs better and it’s going to be also easier to maintain because now you’re not writing that needs to work with four or five different things. We kind of have the best of everything in a single pull. And by we I mean like. James Fish. He’s the one who has been doing the work on DB Connection since the beginning and envisioning all this stuff, so… That’s really exciting as well.


AMOS: So, the pull work - is that going to be it’s own project, or - that’s all going to be internal, you said? That pull won’t be avalible for other uses?


JOSE: So, yeah, the DB Connection - it’s a separate project that anyone can use, and we’re just removing the support in it’s version 2.0, so we are streamlining a couple things. We’re removing a ton of code as well, so… Yeah. 


KEATHLEY: So now you don’t have to actually support pullboy and soldier and all these things - you just support the one thing, which is nice.


JOSE: Yes.


KEATHLEY: So this actually leads me into thinking about something - so you were talking about this being a thing that gets requested a lot - like, hey, can you break Ekto into its constituent pieces so I can use - If I want to use change sets, I just want to use change sets. Maybe I have change sets - maybe I like that abstraction around change to data and I want to use that. Um. And we talked about this earlier to - this idea that the community and - to your mind - should kind of embrace this idea that like. If you need something from the language or you need a library, build it. You’re empowered to build it, and we give you the tools to go build it, and the ideal situation is that you go build it. So, with those two things as context, how do you - what’s the process by which you take feedback from the community and decide ‘this is a thing that we need to do’? You were saying breaking up Ekto is a lot of work, and now you’ve got to pull in these different pieces that you need, and there is an overhead to learning about that, how do you parce - how do you process or triage issues or requests in that way, versus saying ‘y’all figure it out’. Like, I’m not even saying that this is the wrong decision to make. I’m just wondering how that thought process goes. 


JOSE: I’m going to delegate this to Chris McCord. I’ll just do a very short observation - is that, for example, making those decisions for Ekto is very different from making those decisions for Elixir, as it should be. So, so as we were saying, for Elixir - so, for me Elixir is more about enabling rather than providing, and then when you get something like Ekto, it’s more balanced - you definitely want to enable because if you can’t enable people to solve certain things, that can be really problematic, but we need to provide as well because people do want to use Ekto to develop, or people want to use Ekto and be able to achieve a lot with it without having to bring a bunch of other external stuff, while we don’t have this expectation for Elixir or we find, ‘oh, I’m going to build a web application, yes, and run phx new and brings it’s new stuff - or I’m going to use a distributed system or Nerves’ - it brings what it has to bring, and we don’t have to. What about you, Chris?


MCCORD: So, the easy answer is like - priority wise, I take the selfish approach first. If it’s something that I need that I think other people will need, then it gets higher priority in being accepted. If it’s something like - I’m working on a pi project over and over again, we’re gonna do a specific use case that isn’t solved well, that’s an easy way to add a feature. But I think it goes the other way also where people have legitimate issues or they have a feature request or they need a problem solved or they think they need a problem solved by us and not by them - and if it’s the first time we’re hearing about it in three years, then I say, ‘well, this is the first time that this has come up’, so I prefer to wait to see if it’s a common occurrence. ‘Cause like the whole framework debate versus library - we say we’re batteries included but that doesn’t mean we add everything that could be solved - so, if it’s a common occurrence that keeps coming up over and over - like, one example is - they actually just answered this on Slack like an hour ago - is getting the IP address of a channel socket - like, whether they’re coming over websockets or long polling - you can’t do that today, and we specifically punted on that for valid reasons, but it comes up over and over, and we finally saying ‘yeah, okay, enough people need this, let’s implement it’. That was supposed to be a short answer, but it’s supposed to be based off like, ‘does this make my life better?’ or ‘does this help enough people that I think framework should solve it?’. But I think the biggest reasoning around all this comes back to being selfish - like ‘am I okay maintaining this for the rest of my life?’. It’s like - even if I think it’s a good idea and I think we should solve it, I have to be the one to own it and the core team has to be the one to own it and maintain it. Also I think there’s a line there - like I think Jose was saying - there is a line there where I think we want to allow people - we want to be ostensible from framework level and from the language level and say like ‘if you need this, go ahead and implement it’. That’s why we’re built on top of plug, and I think there’s definitely something to be said for ‘batteries included’ but giving the escape hatch to do what they need, because we can’t own everything, and at the end of it, we have to have a life as well. 


JOSE: I would also say that - I don’t want people to get the impression that if they ask enough, we’re going to do things. So, there are things that people, they ask and they have been asking for a long time, and we just say like ‘no, not happening’. That also happens.


KEATHLEY: Yeah, that was my followup question - is how do you decide to say no to a thing that a lot of people are asking for because you know it’s not a great idea or it’s going to be unmaintainable or you’re going to have this massive burden now - how do you say no to that sort of stuff and how do you sort of redirect into like. A positive way?


JOSE: I have a very easy mantra which is “it’s always easy to add, but it’s impossible to remove”.


MCCORD: Dang it. That was going to be my line - “A wise person once told me -” And then that. Yeah. You put that in my head early on, unfortunately.


JOSE: Yes. Yeah, so if I’m not 100% sure, I’m like ‘not happening’, because we can always do it later - and especially - going back to being enablers and providers - especially if there are other ways - like, no there are other ways of doing this problem - like, can we have it as part of the framework, then I’m usually like ‘no, you already can do it. Why are you upset about having to write like ten lines of code - and again, it goes back to ‘are people really needing that thing that much to justify - that frequently - to justify adding it. So, if I’m not 100% sure, it’s usually like ‘no’, because the no is always easy to revert. The yes is a nightmare. 


KEATHLEY: What do you think it is that drives people to want to put stuff into the core language, or into Phoenix or into - like, core tools. Why does that feel more acceptable than writing a library or bringing in a library - like, is that a mentality thing or - why do y’all think that is? Is it easier to say, ‘well, this was blessed by these smart people who I am already trusting so I feel better about it that way’?


ANNA: Or is it like, ‘let’s ask if they’ll do it’, then somebody else doesn’t have to go and like - 


KEATHLEY: Yeah, like ‘I don’t know how to do this, but I need it.’


JOSE: I think it’s more of a like - so, one is the contributing - just the experience of contributing, right - and we’ve tried to be very welcoming - so, it’s even a good thing that people feel like they can come and contribute, and they do that - they come, they contribute, they help improve things - and sometimes it is a perspective of like ‘I really think this could be useful for others’, and, you know, it’s - in truth, it’s hard to measure. It’s like we were saying - some of those things, we need to trust in our gut feeling or we need to trust in our experiences or what we’ve heard from other people, but I think it’s actually a more general thing of wanting to improve things or help others or being able to be part of the community in different ways, like difficult contributions - um. I would think that it’s more in this direction of being something more noble and engaging.


ANNA: I had a followup a little bit - how do you all parce ‘cause there’s a lot of different opinions, even when there are requests being made about how things should go - like, even going back to that conversation we had about config a couple weeks ago - how do you parce when you’re hearing so much from the community about different perspectives about what should be done - what is useful to you - or, I guess my question is - how could that be had in a more constructive way so that the feedback is more useful to people that are implementing these projects.


JOSE: That’s a very good question. Any takers?


ANNA: And I don’t know - maybe it’s just a question. I don’t know if there’s a right or wrong. I was just curious.


MCCORD: Yeah, I don’t have any constructive thoughts here.


KEATHLEY: What are your unconstructive thoughts?


MCCORD: Oh, yeah well - What should I say? Um… I feel like - and this isn’t the community in general, but I feel like if there are a lot of heated opinions, it’s basically never a productive discussion because everyone just goes on with ‘well, what about my opinion’ and it becomes a discussion on people’s different opinions and not around how to move forward. I will say - one thing with - I mean, the config discussion is one example of this that um - this is some other wisdom that Jose bestowed on me early that I think a lot of people miss - with any kind of decision, like with the config, people look at the state of things today and there are deficiencies - we have legitimate issues with config in certain cases - no one sees the thought process and decisions that led to the current state of things, and there are reasons why things are the way that they are, and kinda as a maintainer, you get to just deal with people saying ‘this is crap’ or ‘this doesn’t work’ or ‘you made a bad decision’  - it’s like well, you didn’t see the hundreds of decisions and the twenty hours thinking about this and the reasons why... things are the way they are for valid reasons. It’s like, yes, there may be tradeoffs, but we thought about those tradeoffs. It’s not like we just dreamt up - ‘this is the way it should be without thinking about the design. So I guess that missing from this opinions discussion is kind of appreciating that there were reasons and decisions made that people didn’t really have the context to when they’re just looking at it from the top down.


JOSE: Yeah, if you want to go into a new section called ‘Things that Make Jose Angry’, that would be one of those - because it’s… It’s exactly - in a way, I feel it’s - so there are two things right. One is I personally feel that in a way, it’s disrespectful when it’s implied that the decision was taken just for copying - but the other thing is - would you use a language or a library where most of the decisions are made based on copying. Like - I know I wouldn’t because what of what you’re going to get at the end of it. So usually those are the things that make me a little bit angry because of those things - but for example, the config discussion, it - so, I think it was - even before it was really long, for me personally it was a productive discussion. I had complaints, but they were not complaints - so, for example, some of the arguments, I had to rehash them over and over again, but it’s because the discussion is long - nobody is going to read everything that is said before giving a comment. So, so - and then, this - it goes on this loop because people did not read back and I have to repeat some of the points and some of the decisions that were taken, and it grows even more, and it grows even more and it goes on forever. Maybe we should have a way of like - having bursts of discussions - like, oh, its three days and then we close and there is a summary of the points, and then we start again - and even for like three days, it’s going to be short. People are going to be upset because it’s short - people have work, they have family, they have a thousand other things to do - so, this is an improvement we can do is that we just let people talk and discuss, right, for a week, and then we come and we sum up - and it can be hard because people go in the admittedly wrong direction - they are 100% sure it won’t work, and then you let that thing happen for a week - like, what are you going to do, just say ‘hey, everybody, that thing is totally not working because of this fundamental flaw that went unnoticed’. Yeah, so it’s a little bit hard, but I think as the proposals get more - I think that was an early on proposal on a very complex topic, so when we do another proposal - we are going to have a rationale over things and maybe we can focus the discussion a little bit better - and one of the things that I like to say - to me, it’s very important for us to agree on the tradeoff that exists. We don’t need to necessarily agree on how much weight we put on those things, right, but we need to agree that those are the tradeoffs - and that’s fine, right - I can value some things at 80% and you can put it at 10% importance, but to me it’s important that people are just like ‘those are the decisions that we made and the decisions we did’, and I think it goes back to something we were talking about at the very beginning - right, like how we make - why - what goes into the thought process - and the reason that it’s important is we want everyone - we want this thing to amplify - we want everyone here to understand the thought process of something because you’ll go and tell your coworkers, and your coworkers  are going to tell other people, and this is very rewarding when it happens - especially at the very beginning of the language, and people were able to come and explain all of the rationale, all the design decisions, it was really really nice, because you could see all of the work we did, and looking at the whys, and it really paid off because now other people are saying it too.


MCCORD: I just want to add - I don’t - I think - it’s hard to improve people trying to appreciate the thought process that led to an outcome, just because like - for Jose and I - and everyone’s guilty of it, even like in their own code - so like, yesterday Jose and I were talking about Ekto optimistic box, and it raises an exception, so Jose called me to talk about that, and he preempted the discussion saying ‘this is terrible, let’s make it better’. So I came into the discussion thinking ‘this is bad’, raising exceptions bad, and we talked through the reasons why things are the way that they are and the raising made sense, it actually shed light on ‘oh, well there actually was a valid reason to do this’, so like even features that we implemented - initially like, you forget why - so even with things that we wrote, it’s like ‘oh, this is bad’, and then you actually try to remember and think why it is - and if we can think like that on our own decision making, it’s very hard for other people to come in that maybe aren’t contributors or have maybe never looked at the library source to come in and try to appreciate the decision making process - so I don’t know how you improve that, but people could at least maybe try to take the benefit of the doubt starting out, and then working from there, instead of just looking at it and saying ‘this is bad’.


ANNA: Yeah, that makes sense - I forget who said it, but I remember hearing somebody - It might have been Sarah Mae or somebody in the Ruby community in a talk a while ago - maybe assume that everyone is making the best decisions they can at the time.


MCCORD: Yes - that’s actually a really interesting thought, because that’s one of the things about suddenly being an open source contributor with people using things you wrote - there’s a whole topic on imposter syndrome that maybe you can come on a future episode with me - but I expected - like, everyone you looked to as an authority figure, I expected that everyone has it figured out, and then you find yourself in a position of authority, and you’re like ‘wow, I don’t know anything’ - and I’ve kind of realised and internalised that all of the experts are just people doing the best they can at the time - and that’s all anything in the world is, honestly. It’s interesting seeing it from the other side.


AMOS: I think it’s important when these discussions get long and maybe people are saying the same thing ‘cause they didn’t notice it before, or they’re putting their opinions in there, they’re also doing the best they can with the information they have - the fact that they’re putting their opinions out there means that they care about the language and the community, even if sometimes they might come across as not seeing what’s going on or even if they come across as attacking - I think that they’re caring and doing the best they can with what they have.


ANNA: Yes. I agree with you, Amos. I do think that they’re sometimes ways that - I mean, this is my personal opinion, but even if you disagree, that information can be conveyed in a way that is not attacking - I don’t know that that’s always necessary.


AMOS: Oh. Yes.


ANNA: But yeah, I agree with what you’re saying. What are you both - there’s so much. I am such a fan and have been having such a great experience the past couple years working with Elixir and Phoenix, and just with the stuff that you’re working on, and as the maintainers and creators and as you’re looking to the future, what are you - I guess maybe it’s hard to pick one, but what things are you most excited about, looking ahead.


JOSE: Oh. Uh, yeah - so that’s actually one of the things that I will be talking about - so you were saying at the beginning about Elixir conf and how I am preparing for the talk - so, that’s actually one of the things that I will be talking about - like, last year - last year we had Elixir conf at the same place, in Belleview, and my talk was mostly looking - so, at the time my talk happened, I had decided to work on Elixir and make it a thing for five years and a half, or like, looking back into everything - into our goals as a programming language, and thinking where we got and kind of reevaluate our goals, because at the beginning - at the very beginning, I had outlined like three goals for Elixir, and if you have ever heard me talk about my goals for Elixir, I talk about those things, right? It’s productivity, which is basically tooling, productive experiences, and so on. It’s accessability, so we talked a bit about accessability - getting the language expanded to different domains and compatibility, which is basically going to be compatible for the Elang DM and the OTP and everything it provides - and when you think about it, it’s like - those goals - they’re not useful to us anymore because we are already extensible - like, it was achieved. It was mission accomplished. The same thing with compatibility - we’re already compatible. Sure, there’s a OTP release, they have to leave some work - now, it’s kind of like looking at the - so I guess this year, my talk will be about the next ideas. So, it was a ‘five years back’, and now this will be about the ‘five years ahead’. And trying to, as you were saying, there are some expectations of what people want from Elixir. And try to get everybody on the same page. Those are written - it’s information available today, but I think being able to have a talk and explain point of views in a different way than you get from text can be really helpful as well. So, what to look for in the future - I think that’s going to be our inspiration - and there are things that, you know - and for Elixir, the hint is that [?] so that’s where we’re going, but there are a bunch of other things that I would like to explore - and some of it, it’s personal or professional curiosity - so one of those I’m doing now, like I said, with my Google Summer of Code project - I’m getting to learn a little bit more about like mission learning and how this stuff works - some of it happens to be firing at us right now, and all the work that we’ll be doing - so some of it is happening now. I’m also very interested in techniques in software verification. And this goes for everything that we do to make sure that our software works the way we expect, and it goes from code review, formatter, tasks, property base tests, types systems, and other types of software verification - this is my current area of interest, and things are always improving there, so it’s a very fascinating area, and hopefully I’ll have some time to start in the future too, but those are like. The things on top of my head.


ANNA: Cool, yeah. Chris, did you want to share any thoughts?


MCCORD: Yeah, for me, I mean, Jose mentioned firenotes, but my biggest area of interest is just distributed systems in general, and making that a - I want to be a distributed systems expert to take advantage of the platform. To me, that’s what sets us apart from the vast majority of other languages right now - is our currency distribution story and the more tools we can put in the hands of people and empower them - presence is one example - being able to solve that problem - the underpinnings of that were incredibly challenging, but if enabling that - where you have four lines of code on the server and suddenly you’re not even thinking about different nodes and what happens if they go away - the more problems we can solve and empower people to solve them on a distributed system, I think the more that we’ll start to see the world - and I think Chris Keathley with his Raft excursion is really exciting as well. So, ya know, not just what’s inspiring us, but the greater distributed systems world as well to me is very exciting. I think it’s going to be one of the things that will let us see the world, ‘cause, ya know, it’s not like there’s going to be one-winner-takes-all, but if you look at other platforms and what it would take to implement any kind of distributed systems story, it’s kind of a daunting task if you’re trying to come at that from another language, so for me it’s the most exciting part of being in the language, and it’s enabled by it - not like having to bootstrap my own - like, you look at Apa and Java, you look at what it takes to bootstrap distributed systems tooling into other platforms, it’s a daunting task, so for me that’s the most exciting aspect of what’s available today.


JOSE: And what about you? What are you planning for the future and looking forward to in general?


MCCORD: Are you asking me or the rest of the…


JOSE: No, Chris.


*laughter*


ANNA: I personally kinda agree with Chris - I have a big interest in distributed systems and diving more into that, like from a personal level and interest in code, and from a professional level. I mean, as far as like ElixirBridge - we’ve been around for a few years. We have a workshop coming up in San Francisco next week - or, in a week - but, trying to grow that and trying to make it more accessible. There are folks in other parts of the country that are interested in that and in having more workshops, and so for me, as much as I want to personally keep working on and am interested in the language, but also helping - putting a big effort into growing the community and helping to bring in more underrepresented folks and trying to grow that organization is something I’m really excited about for the next couple years.


JOSE: That’s awesome.


KEATHLEY: I think for me, it’s um… I am also, obviously, really interested in working on the distributed systems stuff - I do that as a big part of my job - um… There’s a whole other conversation - I don’t even know if we have time for this - but there’s this whole other conversation… Do you - I guess I might be slightly less optimistic that we can just provide solutions that anyone can pick up and not have to be at least a semi-expert in, ‘cause I think these things are really hard - the the big thing that I end up seeing - the thing that I see having done the Raft stuff is people want the guarantees of that, but aren’t willing to accept what it takes to get there - so, they want half of Raft, which is some small subset of the functionality, but they don’t want - like, they want leader election, but they don’t want durable storage - it’s like, that’s not - you’ve missed the fundamental point of why you had this in the first place. Or they’re like ‘I want this, but I want to change these five things about it, but it’s no big deal, right? It should just work out’. It’s like, ‘well, if you want to write the TLA proof for that, you go ahead. I’m not going to do that, but this one is proven to work.’ So like. Um. Like. How - I’m interested to see what your feelings about this, ‘cause my feelings are that most of the people doing Elixir right now are very concerned with app development, right. Like, they’re building apps by and large. Like, we see very little infrastructure tooling coming out of the Elixir world. There is some of that in the Erlang world, but like. There’s less people building an EtCD clone in Elixir, if that makes sense. There’s less of that, and there’s a lot of application development. And I wonder, to the degree that we’re ever going to be able to teach all application developers the subtleties of like. Distributed systems and have them apply that in their applications. So I’m curious to see what your take on this is -


ANNA: We might need to have this as a separate discussion.


KEATHLEY: Yeah, this is a huge conversation.


MCCORD: I mean, I think this is a fair point, and in my talk at ElixirConf EU - my goals are - around this point - we can’t defy the laws of physics. We can’t just say ‘distributed systems are trivital now - you don’t have to think about them. So, my goal is - if you can answer the guarantees that you want - so, there has to be some subset of guarantees that you’re aware of, and if you can answer the guarantees that you want, then you should be enabled to - it should be trivial to accomplish that - trivial in that you still have to understand the guarantees and the tradeoffs you want, but if you can answer those questions, then there should be an easy way to get there, versus what it is today, where you have to be like ‘well, go study this paper and maybe pick up this library’, so from that aspect, you still have to understand the guarantees you want, and then we can do things like - if you look at presence - like - that’s the thing you build… the guarantees are the assignment for you, and then we attack the use case with presence in that, you have a list of users that are online, and that doesn’t need to be updating every millisecond, right? So, by default, if who’s in the chat room updates every three seconds based on what node they join, that would be totally fine. So there are some things we can solve - like Jose mentioned the rate limiter, right? There are some built-in guarantees there that we decided for you for that use case, and if your rate limit diverges - if its not 100% consistent from second to second, that’s fine. I think that we can solve a subset of problems for people based on their use case and otherwise we should make it as easy as possible if they can answer what guarantees they need. I agree, Chris, it’s not gonna be ‘we release Firenest and the next day we write applications differently’. Different databases are great, and there’s something to be said about just putting data in the database.


AMOS: And if people have different choices and tradeoffs they want to make, they can pick a different Raft implementation.


CHRIS: Yeah, and they do, in my experience, so…


JOSE: Yeah, but I think it’s like - So Chris was talking about like, application developers, but… Most people they should not have to care about this. It’s the same with OTP, like, in the way - so, people - we had those discussions of like ‘oh, people are coming to Phoenix, but they don’t know about OTP’ and that’s like - you know, a huge part of the point of having Phoenix - so I can focus on all this stuff and Phoenix solves all this for me and in presence is doing that for distributed systems - like, ‘hey, we took those decisions for you. They’re going to be valid 95% of the cases. Here what you need to understand about this’, and it works like that for other people - it was the same idea - we explain the tradeoffs and um. So, to me - I am more aligned with what Chris McCord said - and we had this discussion in the forum not long ago and you were there, Chris Keathley, as well, so like. I’m not bothered at all that we don’t have people doing a lot of infrastructural work, because if you’re talking about infrastructure, then to me, I really don’t care like. How that infastructure is written. So, even when people ask me - like ‘oh, no we need consistency’, and I’m like ‘just put it in the database’ and - right, like, unless you’re going to have an issue, let that thing be your source of truth, and call it a day. So, to me, what makes me excited about all of this - and it has its drawbacks as well - is the fact that we can create these smaller solutions where no body else can - and specialized solutions that solve one problem well, presence being one example of that. And, you know, I would rather support - I would rather support idioms or tools that make our every day with Elixir more pleasant than tools that make somebody that has never used Elixir be able to use them. Which is what you get with Zookeeper. Like, I can deploy Zookeeper and never have written a line of Java. Right, so it’s a tool for our developer to use. It’s absolutely fantastic if we have those tools written. I don’t loose sleep over it - like, to a point where it’s not like it’s going to make us different if we have something like Zookeeper or something like Kafka, we should have - it’s just another tool and they can use those things separately. I really want the tools I can embed in my development experience and use that. To me, that’s where we can make a difference, and then sure - how to get there is going to be really really hard, but to me, that’s where we can make a difference here.


AMOS: And that’s - kinda going off of that, that’s what I like about being involved with the Elixir community and seeing everything that’s going on is, I think, we’re talking about distributed systems - everybody brought that up, and I think it’s putting things in people’s minds that they’re thinking about and learning more about just because of what’s going on in the community, and I think that that’s really important, especially with the way the world is going and all the servers talking to each other, and um… One other thing that I really like and am looking forward to is the stream data property testing and the stateful stuff that has been being talked about. I really am looking forward to seeing where that’s going - I know that there’s been talk back and forth about it possibly ending up in core - I’m not really sure where that stands right now - but I think that being in core would be amazing for being able to bring more people to that conversation to that conversation and more people to say ‘hey, I’ve been looking at this type of testing’ and I really like that.


Jose: Yeah, regarding the property-based testing, we have a couple more back-and-forth for that if it should be on core - so one of the things. So, the main reason - there’s nothing on string data. String data is a separate library, and everything you can do from string data you can do with it as a library, and the main reason for us to have it in core would be to have people actually doing it and kind of embracing it as a way that we write software, but it happens that just the fact that we started talking about it - like, the Elixir team and other members of the community - it already caused like. A reaction - a positive reaction and more people are talking about it, right? And I think - I was looking at the speakers for Elixir Conference, I think we are going to have three or four talks about property based testing, whereas last year, if we had one, it would be many - which was really presented by like Tomazar from Tumic, which was like, probably top three out of five in terms of like - top two, even - in terms of the world talking about property based testing, but now we have a lot of people talking about it, so in a way, it’s like ‘mission accomplished’, as well? It’s like, everybody is talking about it as well. So… that’s what we wanted. We are happy. And then - and then maybe we’ve got enough attention to think about how to design stateful - the model-based properties as well, because that is hard. To me, it’s like - this has to be - this thing has to be easier or simpler or a combination of both - um, right, because - hopefully we have more people thinking about it and they can try different ideas, because I don’t think - I don’t think we are going to get it right the first time. So… 


KEATHLEY: So, I know we’ve got to wrap up here pretty soon - I wanted to ask y’all one more thing before we do that. So obviously y’all are both busy - you’re working on open source stuff, you’ve got a slew of questions about the formatter and opinions and all these things you have to deal with on a daily basis, so, uh, my question is, if you could sort of magically will into existence one thing in the Elixir community - like, a thing that you feel like is missing or a thing that you would love if somebody would go contribute, what would that thing be? If you could just have a thing out there in the world - or, what’s the big thing that you feel like you’re missing or the community is missing or an opportunity that we should be taking advantage of?


JOSE: Chris? McCord. You wanna start?


MCCORD: That is an excellent question. I mean… I guess for myself the answer would be - the problem that I don’t want to solve that I want - I think we’re actually pretty close - a year ago I would have said durable Pub sub, which is still unsolved and I still would love to solve it, but I think uh… That’s my joke answer. I mean, I think we do a good job - I’m trying to think of something that is super lacking day-to-day. I mean, the deployment story would be one, but that’s being worked on - that remains to be as present - or, as close to present as it could be. So. The community perspective - if we could say, like ‘boom, deployment solved’ - I mean, we have Paul working towards that, we have people working on that problem - but, I would love to say like. ‘Boom, deployment solved’. I mean, from my perspective, if I could fix that problem for the community - that could be a non-issue, a question that’s not even asked… ‘Cause I think this remains a block for both newcomers and for clients. 


JOSE: Yeah. I would go with the meshing learning stuff. So, that’s something that we have Google Summer of Code, and it’s just a first step and not really a tensorflow and the landscape is very dynamic. There’s a lot of things happening. I’m like - going straight to your answer - that being completed is an issue that the community will solve and that other people will solve - that would definitely be my vote. Because it’s definitely part of our future as developers, as engineers, it’s going to be - we’re going to start to rely on those things more and more - and I said about the Google Summer of Code, but there are also other libraries that people are coming out with - so like, matrices. Having good library sources with matrices. It’s fundamental to this kind of problem, and we are starting to see some people doing that already. But. That would be nice. When you look at bite and the way that everyone was able to work together and see a group - a group of people working together, an organization of people, many different teams that are working towards this common goal and they continue improving - it’s you know - it’s really great to look at that and see that kind of interaction - it’s really fantastic. More work, more people involved, more people contributing. 


ANNA: Awesome.


KEATHLEY: Awesome. Well, hopefully people can, uh, maybe take some of those ideas and try to get involved that way too, and start contributing and building new things, and I think - it’s an exciting time to be building new things. The language is still young - young-ish. So, it’s nice - it’s a good time. You can try something new, and it can stick.


ANNA: Yeah! Thanks - thank you - thank you both for your time.


KEATHLEY: Yeah. And don’t forget to get a ticket to Elixir Conf and go hear these guys talk there. Also, while we’re making shameless plugs, I’ll go ahead and plug Gig City again - gotta rep my hometown, which - Chris, you’re gonna be at.


AMOS: Everybody except for Jose on this podcast will be there, so it should be a good time. Just saying. Although, Jose might have a slightly longer flight to get there than anybody else.


JOSE: Okay. Let’s do this. I’ll go if you all go by car.


MCCORD: I think I’m driving, so.


KEATHLEY: I’m definitely driving.


AMOS: I’m right in the middle, if Chris McCord, you just wanna pick me up when you go through - we can just roll.


MCCORD: Yeah, I think actually it’s going to be less than six hours - no problem.


AMOS: Oh, I thought you were in the San Francisco area, so maybe I’m wrong.


MCCORD: No, I’m in North Carolina.


AMOS: Ohh, well, I’m in the wrong direction. Nevermind. I’m in Missouri. Alright. Well, everybody have a great day. Bye!


CHRIS: Bye!


ANNA: Bye!