 So why don't you, why don't each person on the panel introduce yourself? Who you are, what you're doing? Francesco, founder of Erlang Solutions, I've been dabbling with Erlang for a long time now. Oh, okay. I'm Jose Valin, creator of Elixir, co-founder of Plataform Attack. Robert Villing, one of the original creators of Erlang, and our work for Erlang Solutions. I'm Eric Morris Johnson, I'm on the court team, and I created Exo and Hicks. I'm Dave Thomas, I'm a programmer. I'm Chris McCord, I created Enix, and I'm the lead developer at Little Lines. I think we'll start this off by asking what you see as the biggest barrier to adoption for Erlang or Elixir, your choice, whichever one you work with the most. Starting with you, Francesco. Good question. Why don't we start with Jose? I don't know. Okay, okay, let's use. Yeah, so. This isn't a clear conference, so let's start with Jose after the floor. Okay. Yeah, so I think we actually talked about those things throughout the conference, which is exactly thinking functionally and thinking concurrently. So for example, today, the Elixir material in particular on the website is mostly a language reference, the intro to our material, and then we go to a defensive guide. There isn't really an intro to tour guide about thinking functionally. The only material I can recall is Introducing Elixir by Simon St. Laurent, and he also wrote Introducing Erlang. He actually wrote Introducing Elixir, and then we got Introducing Elixir, which is really start at the foundation how you need to think about pattern matching and everything and so on, and then builds at some point to concurrency. And I think this is how we, as you said in your talk, right, is how we can push. I think just to add to what Jose was saying, we were translating our Erlang training material to Elixir, and Jose was giving us feedback and his first reaction was, oh, interesting, you're focusing on the concurrency aspect of the language, which is, in our words, what the whole Erlang virtual machine and the beam emulator are all about. Yeah, I'll say it's not running on the JVM. And worst thing. Best thing and worst thing, yes. I think that's seriously a problem. I think a lot of places, the using the JVM in the system and that's what they want to continue using it, seeing it start running on it, it's really not interesting. There are alternatives. There is our JVM, which is our language on the JVM, which I'm guessing would probably run Elixir straight off. It does. It does. Okay, yeah, well, yeah, it does, it does do that. So yeah, there are alternatives, but I think I honestly see that as a real problem. Right, a great package winner, of course. No, but I really think that something that can help the ecosystem grow and flourish can help, of course. I think that's really important right now, now that 8.0 is coming, that we get a good ecosystem and that people start creating things, basically. Yeah. Okay. So I see one of the big problems that the sweet spot for Elixir and Erlang are applications which are non-trivial. And non-trivial doesn't have to mean massive, but it means complicated, highly connected, or whatever else. And the problem with that is it doesn't really lend itself to 12 line examples on a blog post somewhere. And so it's really, really hard to come up with compelling examples to show people the benefits. And that's why talks like the ones we had this afternoon about the game system architecture and Chris's stuff, all of these things are really vitally important because they illustrate how it helps, right? Everybody talks about, oh, it has concurrency and oh, it has immutable whatever and everything. Yeah, but what people really wanna know is how is this gonna help me in my day job? And those things are the kind of things that help people understand that. So the more of those we do, the more use reports, the more sort of blog post videos, everything you do, but not on just like, this is how pattern matching works, but this is how Erlang saved my butt, this is how Elixir made my life happy. Those are the kind of things that we need to see. Chris, two mics. Yeah, so just to, I think Eric said it, I think very much if you build it, they will come atmosphere right now. I think that we have awesome technology and awesome standard library. It's just a matter of building compelling libraries and that's what I'm trying to do with Phoenix. And I think another issue is some people are so outside of the ecosystem that they don't understand what it can actually do. I think what I try to show is like no.connect and showing how easy distributed programming is. I usually like blows people's minds. And I think for me coming outside into Elixir, when I first saw that, it clicked in my head the possibilities, but I think people on the outside don't actually really think the fundamental shift that the ecosystem allows. So if we could address that without saying it's distributor fault tolerant that really doesn't drive home, being able to set up your laptop, someone across from you be able to do node connect and be running code distributedly just with no fanfare. So I think if we could address that to really drive home the benefits somehow with some specific vocabulary or video or blog posts that would be really beneficial. So there have been some comments or blog posts about tension between the Erlang and Elixir communities. Could you give me a take on that? Okay, there have been, well, if you look at it the way I see it, if you look at the online community, there is a small portion of the online community which are pretty negative to Elixir. And some of those are pretty loud. And they're usually loud about everything, right? So they're not allowed specifically about Elixir. If they don't like something they're very loud about it. There's a small portion here which are quite favorable and I'm guessing quite a few of them are here. And there's a large block in the middle which are neither, really. They're not, some might know about it. Some just aren't interested in changing. They're working with, they're happy with what they've got. They're not interested. Do you agree, Francesco? Absolutely, just to add to what Robert said, those who are negative, not necessarily negative, they're critical and they're just as critical towards internal airline libraries and towards other activities, internal people within the airline community are doing. And I think that's sometimes the price you pay when you start growing to a certain amount, you start attracting characters. And looking at some of the blog posts I've read from the Elixir side, I think a lot of it was based on misunderstandings. I think there was a lot of writings about videos on the airline factory not being released immediately and that they were forgotten or filmed on iPhones and other serial stuff. And well, I mean, none of that is correct. There were two tracks which the producers were able to actually process whilst they were filming and release the same day, pretty much. And there were two tracks which we had to process ourselves which took about two weeks to do after the conference and after you've recovered. And same camera teams, and we didn't even tell the camera teams which rooms to pick. You've got so many things when you're running a conference on your mind, telling them to go in and pick one track or the other is the last thing on your mind at these points. And yeah, I mean, that's, so there's no, there's no conspiracy theories behind that. It's just trying to get as much done as possible within possible time frames yet. Of course we're out for them, right? So I'm suggesting, I'm warning, should I say, and Eric, to be very careful when you're out, we've got these exit teams out ready to send you a shutdown signal, right? So, yeah, no, of course not. Sorry. Let's take the first question from the audience. So I think that Elixir is a larger thing than just something that would lend itself to one killer application or one specific purpose. But I think that sort of thing can really help to drive awareness of and adoption of something like DHH's famous 10 minute blog, a video that he did for Rails. I think that really helped propel it forward in a lot of people's minds. And in my mind, one of the big things that Elixir could make more accessible would be concurrency. But I have a hard time thinking of a good example that you could do a short problem or demonstration of it to show concurrency solving or a concurrent processing in a short period of time. Like when I did concurrent processing in one of my classes, we did the model of a fake video store. And I'm not sure if having a 10 minute video of a fake video store or of growing food in fields and having it harvested would have quite the same impact because it's not quite as imminently practical as the 10 minute blog post. Can you think of an example of concurrent processing that might be a good demonstration of that? You should look at having the movie part two. Well, in less than 10 minutes, the demo a chat server which scales to tens of thousands of users. Maybe you said a video store or something like Netflix. All right, thank you. Yeah, I can just one comment to that. I think you're absolutely right. I think every time someone does something serious, the product which is actually being used and the company's happy with it and makes money, it's a benefit. In this case, I'm saying both Verilex here and Alling, in one sense it doesn't make any difference when it's sort of in the same ecosystem. So if you do make something and it's successful and it works and it helps you, tell the world about it, literally. I think all too many times you saw the list of icons I had on my last slide. Most of those companies don't say anything. Now they're not being secretive, they're just not saying anything. They just don't think it's interesting, which means we lose these free ads, right? So yeah, so if you do something, when you do something that's successful, tell the world about it. I think that's a big help. And Dave, do you have something to add? And the next question from the audience. So right now, Phoenix doesn't have a model layer because you want to be flexible, but as far as I know, there's not a good, even a GitHub project to do validation. And so validation is, it doesn't really work with paramension because the whole point of validation is to gather all your errors and present them nicely to the end user. So there's not a good way to do validation. I think there was one library that was, when there are silver records, and the author abused the fake methods that records allow to do validation. And so I don't know if there's a good migration path for having active model-style validations from Rails. Yeah, I think Josie or Eric may be able to answer. I know Ecto has validations now, right? And I know that there's some, I forgot the name of the library now, some kind of valid EX. There is a standalone library that just handles data validation without any kind of model layer that you can just include into your model and it has some nice rules set up for you. So there's definitely a couple options today. Is there anything? I'll echo what Chris said and also what Dave said, in that there are some models that are springing up that do validation much like Active Record did, that I would love to see an approach that didn't mirror the Rails approach to validation. Yeah, so that's what Ecto does. We focused, we actually, I think, borrowed from, was it from a closure library? I think so, yeah. That focused more on composition. You should not be forced to write a macro with a pretty name just because you want to validate something, right? Yeah, so there is something in Ecto and we plan to have to put more sources into Ecto after Alexi will know it's out. So, yeah. Is there any integration with the I-18 sub? The way Rails validation works is all the error messages are actually from the I-18 end. Right, there isn't any right now. It's just a matter of time. We'll get there, yeah. Okay, and does the I-18 end integration in Phoenix now read the YAML files from Rails? So, right. Yes, one question per person. Oh, sorry. Hi there. Apologies if this is a bit of a beginner question, but I just started learning Elixir two days ago. I'm having a good time with it so far. Welcome to the team. Thank you. On the website, a lot is made of Elixir's metaprogramming capabilities and as a Rubyist, that's a big draw for me. What I haven't been able to tell since I'm trying to learn Erlang simultaneously and I haven't quite gotten that far in my studies yet, are Elixir's metaprogramming capabilities the same as Erlang's macros or does Elixir also add metaprogramming capabilities that Erlang itself does not have? Okay, so, no, they are very different. So, you are calling me from Ruby? Ruby and a number of other procedural languages before. This is my first functional language. Okay, awesome. So, yeah, so, Erlang once is closer to templates, right? In the sense. C macros. Yeah, I can say. Stash define and C. Yeah. They're C macros. They're literally modeled on C macros. It's basically, you define a macro and you kind of go get the variables and you just inject in there. In Elixir it's actually different because, so it's closer to least macros because you're actually passing code representation from one place to the other. And that's different from Ruby too because in Ruby, all you do evolving, you do string evaluation, you do class evolve to define functions in the class or you do something like define a method where you rely on the binding. Yeah, so they have three different approaches between them and Elixir is closer to this because it's about, so in my talk, I talk about the code representation, right? So it's interesting because it's not only about code generating code or code replacing code, but it's ultimately about code transforming code. And that's why we can have unless implemented in terms of if because unless you just transform it into a negated if. So that's the general idea. I can just make one question. Okay, no, well Alang has one more and that's a parse transform. Oh yeah, parse transform. Yeah, I'm sure Sam mentioned it. But that's sort of the ultimate because you get the whole module in one go and you can do whatever you want with it and return it with a completely whole module. So it's, you can do anything, but it gives you full power to really kill yourself, right? So from that point of view, Elixir macros are extremely safe. So with Elixir, it's pretty easy to work with Erlang code, you know, just bringing in and running depths and so on. Are there any barriers right now for Erlang projects to use Elixir code? And if there are barriers, is there work being done to make it a, you know, just a complete homogeneous system? Any questions? So today, I think the barriers for someone to use more of Elixir in Erlang is that you need to challenge to compile Elixir code. And so you're most likely, the best way for you to do that is to use Mix. So it's kind of a tough one because you kind of need to change your view tools. But there are some mobile plugins. They don't work as well as Mix because Mix is really smart. It compiles everything in parallel. It's also able to figure out what changed in between compilations to avoid compiling many things. It dumps a graph of your project and can find what changed it in the graph. And the web bar wouldn't have all the things. So that's one. I had, yeah, I had something else, but I forgot. And there are plans to make it better, Eric. Sure. So we have plans for bringing Hex to, right, for bringing Hex. And one way to do that is to bundle both Hex and Mix together so that you don't, so you get Mix without installing, right. You get Mix without installing Elixir. Yeah, exactly. Yeah. Yeah, and then expose. And then expose not only Hex, but some of the Mix tasks as well. So kind of have a subset of Mix running for developers. Yeah, but still need to figure out how you're going to configure Mix because today is very based on Elixir terms and so on. But we are having those discussions back and forth. So we have a follow up real quick. I just wanted to add to this. I mean, what I'd love to see is much more interaction between the two communities, developing frameworks. We're in desperate need of a distributed framework which allows you to go in and start providing different architectural and distributed patterns. And Elixir will need it just as much as the airline world. And I think this is imperative that this kind of interoperability between languages is sorted out in a standard way. And my question was a little bit of a leading question because we've been talking about adoption rate and so on. And if they're between the airline community and the Elixir community, if it was all very easy on either side to mix the match and so on, I think all over we'd get a better adoption rate, so. And my view there is the right way is in OTP you've got the applications which you use to bundle software. And that should be the most basic package with well-defined APIs which could be used then from respective languages. I think that's the right component, the right level in where you start bundling. And just to follow up on that, I think that's a really important education issue on the Elixir side because it's very counterintuitive to think about creating these applications. I mean basically when you see the word application in Elixir, think library. And if you think of it that way, then go forth and start creating these little applications. They're not necessarily things that do something on their own, they're just libraries, yeah. And that's how you can contribute back. Should we say library or components? Because rather, components. Components are a better word, you're absolutely right. Okay. Binary component? Again, doesn't it cross-burning this? Oh yeah, yeah, yeah. There's no problem with that. So that's why getting back to, well, the applications and components, they're a collection, usually a collection of Beam files at that level. That's right, go on. Yeah. Well, that's another problem. That's a higher level problem. How you put, package all these things together, but at the module level, or the Beam level, that they're completely compatible. That's right, go on. Okay, thank you. Sorry. In theory, after you compile, you're golden. You don't need to worry about inter-operation. Yeah, at all. But you need to get to the point until you compile, right? Okay, so this is kind of inspired by the first question that was asked from the audience. And then also something Chris said in his talk, kind of combining the idea of like, what would be a killer, the killer app, the killer feature use case? As opposed to concurrency, something to demonstrate that Chris brought up the internet of things. And I think about killer applications and one of the things that made Rails this big wow moment for a lot of people, particularly me, was that you don't have to worry, active record did the database stuff for you for whatever database you're using, Postgres, SQLite, MySQL, whatever. What would it take to, or is it worthwhile, or is there something we could do to be, like, to have the active record for the internet of things? Like, I can't afford a smart refrigerator, so I don't have one yet, so I don't know what that would take, but what would that mean? Is that a potential use case? Would that demonstrate something worthwhile to people? Well, actually it's funny because when he was doing his talk, I was thinking I got myself a Spark call last week or week before and I'm having a blast playing with it. And when I get home, I'm gonna try to tie it up to one of your channels and have this thing talking in there. The idea of a demo that you had, like half a dozen Spark calls, talking both amongst themselves would also up to servers and somehow communicating or whatever else would be really, really cool. I don't think, my understanding is that we're not yet at the point where everything talks differently and there's no current set of protocols that you could try and map into one thing. But I think we certainly could start looking at, for example, the Sprout people already have a server that when they're, when you want to do a little Sprout call, a Sprout call is like a system on a chip plus a Wi-Fi chip, and it's about the size of my thumb but only about an eighth of an inch thick, right? You plug it in, it goes online and connects up to their server. You can then talk to it just over the web via our rest interface, via their server down to your Sprout call, really cool. But we do the same thing into our own servers using Phoenix, for example. Do PubSub, do event looking, sort of monitor for events, has someone just opened my front door or whatever else. It'd be a real simple demo to put together but I think it'd be pretty compelling. There is going to be a, I believe there's like a hackathon happening in Las Vegas like AT&T is paying a bunch of money for. I just happened to have someone involved and it's going to be all around automated home stuff. So if there's some way to get something together, I think it's in September. I'll send an email or something because I'm really curious what we might be able to provide to those guys. You're going to be playing around with that anyway. You know, it terrifies me to think of, you know, the death copter in the maid and Dave programming his own car. I don't know if I'm going to sleep for weeks after this conference. Yeah, so just to expand a little bit on the last question. I was talking to Chris actually after I saw Martin's talk. It could be interesting to, it could be interesting to, because in Martin's talk, he was doing explicitly a call to protocol JSON, right? So all this realization details, the word there. And maybe we could treat the client, the browser. I think Joe actually has a project that does that as an learning process. So I can just send the messages to it transparently. And then, startization is taking care of office. It's something I don't need to worry. So in the same way, I'm going to have two earning nodes talking. I don't need to worry about how those things are serialized and so on. We could actually do the same for clients and not sure if it's a good idea or a bad idea, but it's one of the ways to explore this kind of everything connected. So one of the best and worst things about like Ruby and node ecosystems and these things is that you can find packages to do anything. And one of the things I'm curious about is that like we were still a fairly small community and is there a punch list somewhere of like libraries and frameworks of things that we really need? So like for example, earlier we had service discovery and then we chimed in more from the lab saying, yeah, I've got discovery, check this out. Or the work being done on Phoenix, for example, like is there a list of things that we don't have yet that we would like to have like the priority of getting like better GUI toolkits or better numerical stuff or, you know, internet things stuff? Is there a place that we can find that? So the list of things that are missing? And that's mostly, that's basically the question? Or- Not like issue tracking stuff, are you done? Yeah, yeah, yeah. I'm going to use more overall, here's what we want to take over the world. Okay. So I'll ask you in a week. Try it out and then, yeah. Don't see if it will be missing. It's, and yeah, and then you have your list and then we can start working on that. I think maybe, yeah, maybe some of us have some suggestions or some ideas. So Francesco just said something that can do distributed processing, be able I guess to, so Chris also referenced that it's basically all I have, I need to crawl pages, right? How can I do that using eight nodes available to me? Something like that. So that's one. Well, I was just going to say that my, I think we don't have a command economy in libraries here, sorry, components. I think instead, and it's the same with Ruby, the best things came along because someone needed to solve a problem. And I think the same thing is true here. If you don't do that, then you're going to end up with a whole bunch of wishy-washy, you know, not particularly exciting libraries. I think the most important thing is discovery. And if we can settle on Hex, for example, as being the place that things go, possibly maybe add the ability to add, I guess you can do that already, kind of like nascent empty projects to Hex, just to like, you know, put a placeholder to say, hey, I'm working on whatever it might be. And that might be an interesting start. But I think that's, you know, you've got to let the community work it out for itself. Yeah, so yeah, that's what I said today morning, right? I have my own ideas, but what matters is like your ideas, right? Because. And one thing that Elixir has that Ruby never had is I have forgotten or lost count of the number of conversations I've had with Matt about, hey, can we try this as a syntax extension or that or the other? You know, dozens of things I was asking about. And the way Ruby is built, that's really hard to do. And he was very reluctant to make those changes. But here, everybody gets the whole language as a playground and you can pretty much hack what you want to. So it's not just libraries, you can write, it's new syntax. And, you know, that's the kind of thing again, where you put it out there, if people like it and it gets to be popular, who knows? A very minor follow-on to this along the same time I've been is just, again, as practices, should we be trying to come up with things from scratch or should we be looking towards the airline community and either wrap it or just call it across from airline? Like what is our? So our official recommendation is don't wrap unless there is a really good reason to. So there was a talk about ETS, for example, right? That you need to use the airline module. So, yeah, and that's the plan. We're probably going to continue using the airline model for a while because there is absolutely no reason to wrap. And then, yeah, if there are existing solutions, just go and use that. So for example, I talked about Kung Kua Hor, which is a fantastic tool that is in airline. There's absolutely no reason to re-implement it or something like that. Yeah, and usually they are very open for extensions. So, yeah, so for example, I had some suggestions for the particular tool and I'm very confident that they would be open to those kind of improvements. All right, so, yeah, so if it's in airline, we should try to reuse it as much as possible. And then if it's outside, right, from other communities, then it's a good idea. Let's definitely try and see where that goes. I'm sorry to keep jumping in here, but actually more things keep occurring to me. The other thing I'd say is when it comes to implementing stuff for the community, let's not just implement stuff that like, hey, we need JSON encoding, we need this, we need that. I think coming out to what I was saying on the first day, we have here the ability to start totally green field. We can do anything we want. It doesn't have to be practical out of the gate, right? So if you've got some fantasy about linking all the world's thermostats together into some global, whatever, go for it. It doesn't have to be practical. It doesn't have to be wrapping an airline library or creating something that is gonna be popular out there in the community. I would much rather see a whole bunch of really, really exotic failures that had one raging success in the middle of them than a whole bunch of boring JSON libraries. So my team and I have been working in Elixir for about seven months now, and we've found types, specs, and dialyzer super helpful. It doesn't seem like there's an emphasis on that within the community, and I wanted to get the opinion of the core team about what they think of the future. Yeah, perfect assessment. Yeah, so dialyzer is super useful. A lot of people find it extremely useful, but we've always worried about accessibility in the sense the tools need to be easy to use. I should not feel lost. And there are some projects, so there is one really good one that allows you to run an external project that allows you to run dialyzer tasks with mix and it's probably going to continue as a project for a while because we need to do work on dialyzer because most of the times I get a dialyzer ever and I have no idea what it should do after that. It requires training, maybe it's not the best word, but you get the idea. And the terms there are printed in our link which doesn't help. So if you want to make it first class, we need to have a lexiformity formatting for the terms, come up with how to make the message better and clearer. And sometimes it's an issue intrinsic to type systems. Sometimes it cannot make it, but we can probably have bigger reports, right? Like, oh, you got this error and then it can show some examples or in which occasions those error happens and how you can fix it. So there is a bunch of work to be done there for me to first to consider like, this is super accessible, I'm not going to feel lost, I can navigate for those waters nicely. Yeah, you said if it's to be considered first class, just whether you believe that it is, that it should be first class citizen within the lexical? Yes, exactly. So we can ship with dialyzer tasks out of the box to meet those would be requirements. Just a side note on dialyzer, one of my favorite tag lines from my team is, oh, God, the bees are in my eyes from all the errors and stuff. That's neither here nor there. My question becomes, I'm still pretty fairly big early on new. I've been programming in early on for like seven months now, but we make really heavy use of common test. And I was wondering if there's any plans to bring that into a lexer or expand upon X unit or anything like that. Um, there isn't, there aren't any plans for bringing common test. It would be nice to have discussions on what we are missing from common test or how we, or maybe I've heard other people saying that they would like to use common test with a lexer. So we could try to figure out how to make it possible as an external library, but it would also be really nice to hear what we are missing from common test, test to make X unit go there. Because one of the reasons that we decided early on to go with our own test framework. So Macros was a part of it and having a nice formatting when you get an error and so on. But it was also because of the development cycle. Because if you are depending on a tool from OTP, like a test framework that is really essential and there is like fast iteration cycles at the beginning, it would slow us down, right? Because if there is a bug or if there's an limitation that we need to add, we need to wait for a six months release cycle and so on. So even for the OTP team is fantastic and they're really open to the exchange, to additions and improvements and extensions. It's a slower cycle that we cannot afford at this point. Yeah, I just wanna say the difference, I see it, is that I mean common test is really designed for testing systems. Setting up a system and running tests on a running system, rather than say testing one module or something like this. And I think you should be able to run common test with Elixir, although the output will probably look like Alangra. But I think you can fit around with that if you really want to. It's quite programmable. It might look a little bit funny, but it should work. It's, there are some lackers, but they are extremely trivial. Literally very trivial. So it should actually work. I don't know if you've actually tested it, but I think it should work. It works. It works, yeah. Is it open source? Do it. Have you done anything special? A special interface, just running it straight off. Yeah, the module games would look funny, but that's about it, right, I think. Awesome. All right, super important question. In the Ruby community, Gorbipuff's kind of the unofficial mascot. I was wondering if we could make Moose, the unofficial mascot of Elixir. It's already finished. You'd have to ask him. He seems rather indifferent right now. Well played, sir. So this is a question from the internet. TrueDroid, Lexi Sholuk, who really wanted to be here. Very nice for going to the internet for questions. Yeah, yeah, yeah. He wants to know what the panelists think of validating options like passing a keyword list or property list. Is it a good style to raise on bad options? I think, I say yes, because I actually got bitten just yesterday by calling a standard library and I misspelled one of the options and it took me forever to discover what I'd done wrong. So I think there are definitely times to do that. And I think it also goes along with the idea is, okay, so right now we're passing in keyword lists, right? But imagine instead we're passing in maps. Well, then I would get the checking. So, that's an implementation issue, right? Why, you know, it's both dicts, so maybe I should have the checking with the other side. It's still a subset thing. If it was type of key, we still aren't going to find it. You match on the subset of the map. So, the only way to do it would be to say, this thing should only have those keys and not anything else. So, fetch bank, just say the key is there, but if, yeah, so fetch bank, it's, yeah, but not all options may be required. The issue is that there is an option which is optional and yeah, you just mistype it and it doesn't work. It's, maybe there's just room for one extra function in dict, which would be make sure there's nothing in here apart from the following. Yeah, take call or something like that, yeah. Designed by internet, that has to be the first. Oh, there's just a question down here. Yeah. Yeah, so assert valid keys with check, just those keys exists and nothing else. Yeah, yeah, good. So, the first thing that I thought when I came to Luxor was syntax was nice and the second thing I thought was, what's a cool thing that I could do with this? I know Dave, you mentioned there's no real easy problem that utilizes extreme concurrency and massive scalability, but I was wondering, I mean, Phoenix looks like a great opportunity to do something cool right off the bat. Do you guys have like a personal thing that you've done that's kind of noteworthy and worthy of bragging about? I've heard you help your telephone switches and stuff like that, Robert. Yeah, that was a long time ago. We're all just modest. They got nothing, he's done some panel, maybe he should go get a book. Okay, so. One second, can we extend the previous question to the audience? A chat server. A chat server. Who's got something better than chat server? No, road will be judgmental. No, that's not how it works. This is an arms race and we've got to raise the bar. Chat server's great, let's get better. Yes. Community-driven tutorial site actually written at a lecture conference. That's pretty cool. Other ideas from the audience? Yeah, it's back here. Okay, that's awesome. Telephone system, yes. Oh, you copied that from Dave. Fibonacci sequence, yeah. Bruce, I was gonna take one. Wasn't anything crazy, it was just a simple OTP app but what I run for my Elixir workshops is I call it a distributed tweet aggregator where I have all the attendees connect up on a cluster and my projector node globally registers itself as the aggregator and then all the clients spin up a Twitter client, ask my aggregator node for my Twitter, personal Twitter off key and token and then they fetch Twitter search results and send it to the projector and the projector displays the results. So it's a really, not an insane app but it's a really easy way to show the benefits to newcomers about how we can run on a cluster. So that's been a fun thing that I've been able to do. Anybody else got one from the audience? All right. So my question is now that I actually have two people who actually implement languages, like I'm gonna draw from the back story like CoffeeScript and JavaScript. Like all the CoffeeScript had like a lot of great ideas to improve the syntax of JavaScript that at the end that they got implemented. Is there something like that for Erlang like version 18, 19 will have some syntax trigger that Elixir has? I very much doubt it. So yeah. So one thing and it was actually really nice to see it that it's going to come with Erlang, the next Erlang version, the 18th is that, so today when you're defining supervision trees in Erlang is a bunch of tuples and you need to define everything. And now on Erlang, the next Erlang version, they're planning for two pass maps and you don't actually, so the maps already help because when you have a tuple, you don't have the name of the fields. So have like one and five, but you have no idea what they actually mean. So having the fields help and they're also going to have the full values for some of those things. And that's something that we are doing already for a while, which was cool to see and the discussion on the main list when they were proposing this feature is exactly to make it more accessible. So yeah, that was cool. Okay, I got a question. Can you hear me? So I'm just thinking out loud here. I'm not sure we're going to get serious adoption until we get like reactive programming in Elixir. I think Robert wants to take that on. I won't say anything, I think it's best. Okay, yeah, there was this reactive programming manifesto. Okay, so now everyone will know. And in principle, I thought the text was okay. What annoyed me was, what really annoyed me was it was presenting reactive programming something new, something new and innovative. And okay, for the other point of view, we've been doing it for over 20 years and we definitely weren't the first. If anyone's ever written anything for a processor using interrupts, you're doing reactive programming, right? And that's from the 70s. So that really annoyed me. That's the reason why I didn't ever sign it. So no, she didn't know it was that. No, no, what a question. So I was just, wait, wait, wait. I actually want to discuss on that because there is that, right? And there is functional reactive programming which is slightly there, but not really. And this conversation is happening because reactive is now both word, right? Yeah. So what should we do? Because there is one option which is, you know, yeah, but there is one option to say, you know, this is okay. It's good to know that everyone is speaking about reactive now and look, here's how we actually do reactive properly, right? And it goes to your talk and to Francesco talks, like you need to have a dedicated channel for error handling. Error handling is a very important part of writing reactive code. And then we can at least go on the waves. I tend to get allergies when, you know, when people try to be buzzword compliance. It's, you know, the way it used to be with Corba and everything else, you know, back in the mid 90s. But I think, well, if they ask, just say yes. Elixir is reactive and it has always been and always will be, you know. Yeah, great answer. So, I just want to, yes, I'm all for reactive programming, right? Reactive systems, that's it. If you really look at it, literally every system is reactive. It's just that whether you want to call it that or how it looks, but in principle, everything's reactive, right? But just a little step further, I think we could actually lead in a kind of less dramatic way than going the whole, you know, Francesco route in terms of right now, we don't really do clever things with streams. And I think that we could start looking at using streams as a serialization method for otherwise temporal events and creating reactive code that way. And it'd be an interesting, you know, we have the ability to play with that, to experiment with that. We just don't, we're not currently, you know, really pursuing that actively. I mean, we can, what you'll discover is that it's, you'll throw something together in 10, 15 lines of code, you know, versus other technologies where you really need applications and frameworks to deal with it. So that's why, you know, we've been dealing with streams in the airline world. Oh yeah, yeah. But we just, never occurred or agents, and you know, you'll throw together an agent with 20, 30 lines of code. And so, you know, we've never gone out and said, hey, we've got agents. It's just, there's actually a big difference, I think, between having the ability to do something and having the intent to do it. So, giving something a name is more than just marketing. It actually helps you think about it and helps you partition your system when you're designing it. So say, for example, we said, okay, we had a kind of stream, which is a quote, reactive stream. And that allowed us to do things like zip between different event streams and all this kind of stuff. And then say we could make it distributed same way that Jose was saying between browsers and, or sorry, between clients and servers. And then say it was supported by Phoenix, right? Now start thinking about the cool stuff you could do, right? I mean, I know you can do it right now, you know? We could do it in Assembler as well. What I'm saying is we need, so I was just anticipating Robert here, but yeah. Yeah, yeah, of course you can do it now. Of course you can do it now. In the same way that you could have written a web framework in Ruby now. I mean, you didn't need Rails, you know? You're all just slackers. And it's the same thing here, right? You know, all you need is a set of conventions and that's what I suppose we could do. Well, there's two things, right? One is the technology and one is the marketing associated with the technology. And the marketing associated with the technology has value. When we can attach words and techniques, they're idioms and the idioms are the things that we need to process and build bigger ideas. They're like macros for the brain. And I think from that perspective, I totally agree with Robert that Erlang has been reactive before reactive was reactive and that the manifesto is, you know, a little bit of smoke in some ways. In other ways, building that idiom would be tremendously valuable for both ecosystems right now. So I'm not sure what this says, but you know, that whole question has been a joke. And we just had a 10 minute serious conversation. So it's the way you tell them. So the real question or maybe you guys have already thought about this, but go back to Erlang and Elixir and the module or package manager, what do you want to call it? And I'm just kind of thinking here about, you know, if we build, if we take Hex and Hex actually works to build Erlang, right? Erlang only. So if I have an Erlang dev, fine. I have, you know, I understand, I may have to install an extra application that I never use to manage my package and build my libraries and stuff. You know, I eat, in this case, Elixir. But you know, if it's nice and easy for Erlang people and they can build completely, you know, kick butt, you know, Erlang packages or applications, and it works the same for Elixir people, and it might be a good bridging tool. And now if you did that though, you know, I heard you guys talking, you may want to include this inside Elixir, right? So really all I need is Elixir. I've got my package manager in there, but it works just for Erlang. I don't have to use, I don't have to generate Elixir code. Yeah, so that's what is on the roadmap for Hacks, how we can integrate better with the Erlang ecosystem. Not only Erlang was talking to Duncan about Elixir 2 and how we can integrate that with other languages. So yeah, there's a little bit of back and forth and still until we figure out, should say a little bit of tinkering till we figure out what is the best way to do that, to avoid code duplication and everything that comes with it. We also don't want to, so usability should go both ways because today's a very, there's a bit really good from the Elixir side, but you know, we don't have bad usability from the Erlang side, right? It should have good usability too on everything. On the API you use to configure it, on their home messages, so you're working on it and we'll see. Have you guys thought about, with a system like CompileNFs automatically for various architectures, kind of like RubyGems does, or is it totally beyond the scope of what we're currently? Yeah, so today is just like, you compile Bing and that's it. You don't need to worry about anything platform dependent really. For NFs, right? Yes, yes. But there are NFs and we actually had a plan, so one of the Google Summer of Code students for this year, his plan was to improve the window support and eventually to get to the point where we have NFs and have compilation in between different platforms, but we never got to it because it started working on the Windows installer, which is more important to have a good workflow and installation on Windows. Francesco has been doing a similar work from the other side, right? Have a good other installers as well for Windows and Mac, Ubuntu, Debian and so on. Yeah, so we, yeah, it was postponed. So that's about wraps it up, we're out of time, and does the panel have any, you guys wanna make a closing comment in each of you guys? Definitely, thank you for organizing, Alexi Comf. Thanks, it has been fantastic. Thanks everyone for coming. It's really amazing to see everyone here. I know that everyone here is responsible for the language growth in many different ways, right? Or is it the language, or it's the documentation, or is the community where we live? So yeah, it has been two excellent days. Okay. All right, well thank you everybody. Thanks for. Yeah, I just wanna say one thing. For all of you people who are tired of syntax and love parentheses, there is LFV, right? People can't do that. We can translate it to anything, right? And that concludes the comment.