 So the idea with this panel was during the day, if there were questions that were not answered or if you wanted to ask something, we got all the speakers back. I think we're still trying to get Bruce. He's not yet responding, but we'll get started anyways. The rest of the speakers are here. So this is more of just an open panel for you guys to ask questions that could not get answered during the day or anything else that came up. So it's kind of open. If nobody asks, then you can ask each other questions. So does anyone have a question? Yes, please. Hi. So my question is around cryptography and Erlang slash Elixir. So where I come from is if you look at a lot of hashing or encryption algorithms, a lot of them involve breaking up a file or a binary into multiple portions and then probably mixing them up, juggling them up, playing around with the bits. And if you look at Erlang or Elixir, one of the features that, you know, one of the powerful features is binary pattern matching. So do you think Erlang slash Elixir would, it'll definitely be a good way to express an encryption algorithm, but when it comes to performance, what are your views on it? That's my question. That's a great question. I know. Okay. I think that doing cryptographic stuff in Elixir is a terrible idea because it's low. And usually it's a lot of CPU to do these kind of things, but most stuff that most cryptos stuff in Erlang is implemented through NIFs, right? So that's a very good combination to, you can implement stuff yourself, you can combine it through like the OpenSSL library or there's a bunch of rust implementations that you can use as NIFs. So it's a good idea if you can use NIFs, then it's like to get the raw performance for the cryptographic requirements, like CPU requirements for cryptographic stuff that mixed with the Elixir's and Erlang's ability to very nicely deal with binaries in general, like in files for sure, as binaries, it's a very good combination. So yeah, I think it's good to be in general. I don't disagree with you at all, but I am unable to recollect what, but I feel like I've seen one implementation of I think some hashing algorithm or something that was pure Erlang for some reason, and that was my first reaction to why is this in Erlang, but yeah, I'm not sure if I'm imagining this, but I feel like I've seen that somewhere, and with a good, I mean, it did address this particular question is why is this in Erlang? Does that answer your question? So Eternity blockchain also uses one, I think, B-Blake, two for their blockchain needs. So that's a pure Erlang implementation that I could find, and that's when I got this question as to whether I've read it in a lot of places, as you said, is that Erlang's Elixir will be very slow for cryptographic algorithms, but this was one question that I had in my mind. Yeah, this is what rather made me think. I'm not sure about the specific performance characteristics of even that implementation, but yeah, I do think that a lot of languages can borrow this feature, definitely. All right, any other questions now? Moving to the next one. Also, there is some sort of a documentation about binary pattern matching in the Erlang documentation, so it goes more in detail about performance characteristics of using binary pattern matching, so yeah, so you should look into that. All right, I'll ask a question if someone else is not asking. So if you had a magic wand and if you could fix one thing on the beam, or in any of the languages that work on the beam, what would it be? I'd like to hear each of the panelists view on this. If you had a magic wand and you could fix whatever you wanted, what is the one thing that you would fix in the beam? For me, right now, the only problem I have with, not beams, especially, but not having access to Erlang documentation right into Elixir. So that's a problem, but Elixir has a documentation of the first class, so that's not the problem, but only right now. If you're able to fix that, having all the work of Erlang right into our ID and having access to that, so we have type signature and all, but not able to access that. So I think if that would be fixed, so it would be perfect in my opinion. All right, cool. I'm in the state where I feel that Elang is at the best, because I've been working in Erlang for like only two years now. So I don't see any problem as such, so I may not be able to answer your question. All right. I think there should be some things left. Anything that is perfect would be really difficult to grasp. So things that are not there should not be there. Maybe we can try to get closer to the idealism, but idealism could not be achieved. So. I think you're giving very philosophical answers. Yeah. So you're saying basically Erlang and Elixir and the beam is perfect and whatever is there is perfect, nothing needs to be added. Nothing is perfect, but as you work on it, the gap that remains towards the perfection, it actually inspires us to learn more and reach towards perfection. Okay. I think one of our biggest problems has been with the ecosystem, especially across different Phoenix versions and different Ecto versions, Ecto's ORM. It was, we had some issues around migration not being as straightforward, or our dependencies working with specific versions, but not working with other versions, which was unfortunate. I think that was the most painful thing for us during our work. I'm really glad that nobody said types. That the magic thing that I want to add is types. I'm really happy about that. But for me is Erlang syntax, get rid of the commas and the periods and the columns and semicolons and sometimes nothing. That's, I think, confusing for beginners. And I would like to get rid of a lot of legacy stuff that is in Erlang and make Erlang a better foundation for even what Elixir does. So it's moving in the right direction, but there's a lot of stuff that is in Erlang that is inconsistent APIs or modules that are there for legacy that can't be removed. But I wish there was more isolation of these components so that you don't need to bring them. And one thing that I encourage everyone to look at that I would really like to get rid of is the three different APIs in the queue module in Erlang. If you have ever worked with this, it's amazing. There's an API that's just, when you have to get an element from the left of the queue, it's spelled like cons, maybe, for example, or something. And when you get it on the other side, it's just spelled backwards. It's knock, yeah. Yes. Number one feature request, please. Let's get rid of that. I think with the existing state of types and gradual typing or whatever it is that you do get with Dialyzer, it has been extremely slow. We did spend some time looking at typing everything. But I mean, the benefits are obvious and all, but it was painfully slow. And yeah, I think that could definitely, if that was not that slow, we would have definitely used it. Good. What do you mean by, like, what was slow? I did not understand. The type checking, the amount of time it took to check. So the type checking is at, like, a runtime type checking? No, it was a separate step for us. I am not sure if there's anything else in the ecosystem right now. There's something else other than Dialyzer. Forget what it's called. It's some otherizer. So you're saying that Dialyzer was too slow? It was at least in our situation. It wasn't something that you could run at every save of a file, for example, which is what? I am Karthik. When we talk about robust machines, it generates huge amount of data, obviously. So we need to deal about that huge amount of data. Anyway, we have to store that huge amount of data persistently in any database. And we have to handle it efficiently. Is there any way Erlang could help in this, doing this? How exactly huge data can be efficiently handled, like performance or something like that? Does anyone want to take that? Yeah, can you be a bit more specific? Like, first of all, for example, if you're taking a bus, as we saw in the morning, she was saying like, she was using the Erlang term for using search criteria. So where in a large amount of data will be there in a database? We ought to fetch, and it must be faster. We must get the response faster. Is there any way Erlang helps in doing that? Or is there any role for Erlang to play in this, or it's only database? The thing is, you can use multiple process to fetch concurrently. So that is how you can achieve the speed in this case. That's what I can think of. Okay, how exactly, can you give me? For one single search request, you can spawn multiple concurrent process to fetch the data concurrently, in a faster way. That's what you're trying to ask? Even if you concurrently pass, the base, the best thing is the already database. Anyway, it's going to hit there in the already database. Is there anything like you can match, map and reduce or something like that, which we can improve performance or something like that? Erlang, I mean, I am not aware of any library which provides this. Erlang, as a raw, it doesn't have anything of map and reduce. I think, what's always tempting with the beam and with Erlang or Elixir, for me is that, it feels like a lot of problems you don't have to reach out of the system, whether that is to the database or to a cache or whatever. It's one of those workshops where you're in the workshop and you know that to build the thing you want to build, you can just be here and build everything. You don't need to step out. And that does, I mean, if you look at the classic example, the reason chat servers are so trivial to implement is because the language and OTP allows you to think like that very easily. Like, going from step one where you're like, I know how to write functions. I know how to spawn processes. The next thing you do is, oh, I can now build a cache in my service, not outside. I can build an index for this thing and treat that as a separate process and do something. I think the fact that the language enables that thinking helps. And that's definitely a thing that people use in practice also, I think. At least we have. Thank you. Thanks. It's a follow up to Nareesha's question. I know some of you like Sujata has prior experience with Java. So if you had a magic wand and you took, you could take one thing from Elixir or Lang to your past life as a Java programmer or as a closureist. I've also written a year of Java, maybe. Oh, so you're one of us. Okay, so what is it that, what's that one thing that you'd love to take back to your past life that would have made your life much more easier? That would be the supervision tree. Self-feeling capability of L Lang. That would be one thing I would like to take into Java. For me, it's a supervisor, yes. It was selling point for me. It was one o'clock in the morning. I was reading Francesco book and I just had a aha moment and I knew it. I had to learn going deep in this language. So yeah, supervisor. Every other language should have. It has to be supervisor trees. Yeah, I mean, I am actually not able to answer that question in a straightforward fashion because it feels like the 10 different things or the three different things or whatever the number of things that you get with L Lang are all very intertwined with each other. I mean, if you're saying supervision trees, you also are saying I want processes in the first place. You want lightweight processes with immutable data, with inboxes on those processes and these processes are isolated. Like you're asking for a lot when you just say supervision trees. It's very, I'm not able to answer that question in a, like this is the most first thing I would want. Basically, you're saying that if you took supervision trees, that would be a bad idea. No, you just bring all, you just bring. You will not get everything else in other languages. Yeah, yeah, that would be a bad idea. Yeah, that would be a bit difficult. Yeah, that's a bit difficult to imagine even. But if you're doing that the right way, what you're saying when you say I want supervision trees is I want all of the language in Java. It depends on the language where I'm bringing this stuff to, but the number one for amazing immutability. So you just make it easier to work. And then, yeah, the process model that Heralang has is amazing, I think. And that's, you can't really take, like we were discussing, you can't really take away, like immutability, message passing, and isolation are, and mailboxes are, and like, yeah, they are tied to each other in a way that you can take one of them, it doesn't make sense. So, but that's what I would, like the main feature that I would want in every other language. Supervision, you can implement yourself, on top of that. Yeah, yeah, yeah. But if you have the process model that Heralang has with links and monitors and message passing, I think that's a killer feature. One of the things which is quite inspired by Heralang in Java world is ACCA, which is pretty similar. It has lightweight process and message passing and immutable messages and such. And it's used in a lot of big systems, like these days people are building huge distributor systems based on ACCA. And ACCA itself has like, distributor storage and et cetera built on it. So, how would you, like how do you compare like Heralang and Elixir with the JVM equivalents and, I mean, why are people using ACCA at all instead of Heralang? Does ACCA do per process garbage collection? No, I don't think it does that. It's on JVM, so I don't think it does that. That's an advantage of the beam, but I've never used the ACCA. Yeah, I don't have, I haven't used or looked into even ACCA, so. Since it's a JVM, I believe it's a shared heap memory. So, being a shared heap, mutability, I believe I'm not sure of the language, but if there is a shared heap and mutability to the language, then concurrency is hard in itself because you have to take care of the safer concurrency so that multiple states do not modify the data. So, I believe it's little complex even though they have simplified from Java. I'm not sure how the language actually works, but if you need concurrency, Heralang should be the right choice to start with because of its advantage with immutable and being process-wise and heap is within the process, garbage collection happens per process. So, I think that's the advantage we have in Heralang. Any other questions here? Hello, I'm Krishna. I'm actively working in Heralang for the past five years. I'm facing a problem in Heralang regarding code version maintenance. As you are aware, Heralang will have an application architecture and each application will have a major version, minor version, and a build version. And you can also have version numbers for individual modules. So, if I make a product release, initially I will make the module versions and application versions similar. But then even, then after if I make a single change that involves a single module, I have to obviously change the application version, but should I change the remaining module versions also? So, I just want to know how you guys maintain the module versions and application versions or you update the version every time you make even a single change or how do you do that? How do you do versioning, basically? What do you version? As such, how you follow versioning for any particular application holds good for Heralang also. No, Heralang has a lot of beam files. Each application will have a package of beam files. Each beam file will have its own version. Some beam files will be specific to that application. But why do you have to version each file? Yeah. I am not understanding. Why do you have to version each file? Not each file, I think he is talking about each module. Okay. That's very similar to any other language, right? Like if you take Java, for example, you would have jars and each jars will be versioned and then you have a package which basically... Yeah, that jar will be a collection of class files. Correct. But each class will not have any version. So, when he says each module, it's actually effectively each file because you have one module in every file. I haven't done this in Heralang and in Alexa, you're not really versioning your modules by default or something. I'm not sure if the question is about writing applications or writing libraries. Like if you're writing an application in Heralang, if you pin a version of Heralang or OTP, you have a fixed set of versions of each module, right? An application in OTP. If you say 22.1.0, that's just a fixed version that's not gonna change, right? So, in application code, we just pin a specific OTP version and we pin a specific elixir version and then for dependencies, we have requirements, right? So, we say, for example, 3.0 and onwards, but not 4.0, you know, like till the greater than. If you're writing a library, so that's an answer question if you're writing application code. So, what I understand is we don't care about the application-wise modules, versions. I've never looked at application, the version of an Heralang application, no, never, in my career. Like I look at the OTP version and that entails some application version, but I don't really care what the application version is. Also, OTP doesn't follow semantic versioning, so it's very fluffy, you know, what it means for version change. Like OTP can do preggin changes or like they don't follow semantic versioning, sadly, so. Okay, thanks. Sorry for asking too many questions. If somebody else wants, please take the mic from me. My question was, so what kind of applications, since you all of you have, you know, worked in Heralang and elixir, what kind of applications do you build in it? Like, you know, when I say kind, I mean like is it like a chat server sort of thing, a game, is it like a CRUD system, is it an analytics system, is it like, I don't know. What kind of systems have you generally built in Heralang and elixir? Just to give us an idea of what it is good for. I mean, for example, you'd probably not build a compiler in Heralang, so that kind of thing. For me, a bunch of web apps, like APIs, for example, I've built with elixir and a lot of asynchronous systems for either processing events or yeah, mostly processing events. Like, for example, you want to send a bunch of push notifications, you're like, an event happens, you process these events and this event leads to going to a database, fetching a bunch of rows, sending push notifications, talking to external services and push notifications, like an asynchronous system for processing, general processing of events and that's what I'm building now as well at work, it's just an asynchronous messaging system where we just process, basically services are there to process events, process and generate different events. I think in general, elixir and Heralang excel at IO bound applications because they're very good at managing IO and they're very good at talking to other systems, so whenever you have to integrate a bunch of systems, they are a good choice, I think, and for web, they're a pretty good choice as well for the reliability and isolation properties and the process garbage collection and this kind of stuff. And I've built a bunch of libraries, that's the stuff that I've built with elixir. Yeah, I think most of my categories I've, most of my career, I've worked on things that are behind websites or mobile applications, whatever is running on the server and I think nearly everything I've done, I could guilt free pick elixir or Heralang for it except maybe that one time I had to build some sort of search index effectively, which is, yeah, CPU bound. So it's not, it's not something I'm immediately reaching for and I might look at doing something else there but I think everything else, if it makes sense for your team and whatever, I think that's any backend server side. At Redbus actually we have used Elang for backend servers for both booking and search engine, basically a rest layer for serving the search results as well as booking a bus ticket. That's one use case we are using it for today. For me is two. One is like a fault-tolerant GUI application. There is this library, I just forgot the name. So each of the GUI elements are like individual isolated process. What was the name? So, see any cap. So you can imagine, and the NERC project, so you can imagine having IOT applications and you have some GUI and each of those individual elements, the GUI elements are independent. So there is, they can crash independently and I have. So I'm really excited about, I think in the future these two projects is going to have a much bigger impact on the Beam community because if you just want to build an API you can do in any tool you're already familiar with. You don't need another tool technology but I think IOT is the space where Beam is going to shine. Maybe I don't know how many years. I am currently working on a cloud side command center for IOT enabled Wi-Fi routers. So the routers are also embedded with Elixir code. Cloud is completely Elixir over here and we have a mobile app. So we have a REST layer that communicates with the cloud and so whenever there are some events, so for example, we have, we are developing for a smoke detector system that is connected to your Wi-Fi system and this system then sends a notification to the admin or the owner of the house if they detect a smoke. So we are really creating something for a soft real-time system. A good example can be this one and we like suppose some new person connects to my Wi-Fi I would get a new notification immediately. I would be able to keep a track of the signal strength that end users, end devices are getting. I am able to check the network speed on my router. So these many tasks can be performed mainly because the Wi-Fi router and the cloud, there is a consistent socket open over there and we have a heartbeat signal that goes approximately every 15 seconds to the cloud and that gives a pretty much fair idea of what is going on. So you can gauge the amount of work that can be done in Elixir. So just to summarize, is it fair to say your typical event-driven applications probably would be a good starting point to look at this. IoT will kind of fit into event-driven, quite a few web applications would kind of fit into that domain as well. Zoll event kind of something triggering. So in some sense like event-driven in general across different verticals, would that be a fair summarization? Yeah, because the basic of a beam is it mostly acts on message passing and here we can generate a message whenever an event is triggered. So we can easily apply Orlang or Beam ecosystem on an event-driven application. Go user again, somebody is clicking something, so it's an event. So you mentioned IoT. Is that the same regular distribution of Orlang or Elixir or is there like an embedded version of Orlang that gets deployed on resource-constrained devices? And if so, is there like any constraints on how you communicate with them? I am not sure about the firmware side. Implementation if they are using NERVs or is it plain Elixir, but we are directly communicating with the end devices using RPCs. So that pretty much makes sure that we have an Elixir system or an Orlang system that is running over there in the end devices. Yeah, I don't think we are quite equipped to answer that. Hi, in one of the closer talk, I heard like when a list or something like big object, if it is passed to one function to other, so it uses a special technique called like persistent data structure. So when like if it is thousand elements list and one or two element is modified in the other function, so it will instead of copying the entire list into, instead of copying entire list, it intelligently maintains the linked list. So I couldn't find much information like how it is done implemented in Erlang or Elixir. So any idea about like how it is managed? I haven't actually looked into that, but I've taken that for granted with any language that has immutable data structures that the implementation is roughly some version of the same thing. Maybe someone who has looked into that can speak about it in detail. I think the purely functional data structures book, I think all these languages that have implemented purely functional data structures have derived. The only information I could find is like when it is message passing to other process, like if it is more than 64 bytes, it will maintain the memory in the heap, like in general memory, but I couldn't find within the process like how data structure is maintained. Yeah. I can't answer this question for you specifically about Elixir or Erlang, but if you want to learn about how the data structures are implemented in general and the thinking behind complexity of these data structures and whatever not, I'd recommend this book, it's called purely functional data structures, Chris Okasaki. Okay. Yeah. Bruce can answer all questions. If I may, the question was immutable data structures in Erlang and Elixir. In Clojure, we know that there's chunking and the way immutable data structures are implemented, they're optimized to take advantage of the persistence and stuff, in that if you add an element to a list, the copy of the list is sharing the rest of the list with the previous list. We couldn't find, or none of us have looked at the implementation in Erlang. Is that similar? What is it like? So I don't know about taking advantage of the persistence, but a list in Elixir is essentially, it's made of conge elements. Is that the same way as Clojure? So it's basically connected elements. So that means that when you're copying any kind of list or a structure that uses a list, if you copy from the head forward, it's much more efficient, and if you copy from the tail, then you're basically replacing everything all the way up to the tail. Is it the same in Clojure? I think so. I think that's the same. Yeah, and I don't know that level of detail. So not all questions nourish. Thank you. Hi there. Dabbler in functional programming. I come from a Ruby background mostly. And for me, choosing between Elixir and Erlang would be very simple. I would choose Elixir. For the people that choose Erlang, why? The people who don't like Ruby. I think that's my answer. I agree on the question, like why. But I think that mostly, if you're writing applications right now, unless you're very particular about some things, like tooling, for example, Erlang has some better tooling on some particular things, like some people find the common test, what is it called? Some testing framework that Erlang has find it better, and it's hard to use from Elixir. So unless you're very particular about that, I think that if you're writing applications, right now Elixir is probably the better choice just because it's a super set over Erlang. It has arguably a better developer experience than Erlang, and it's easier to consult a documentation, for example, like you can consult you from the shell or whatever. So if you're writing an application, it provides a bunch of features that are just on top of Erlang, like protocols, for example, right there. You get that for free if you want to use it. You cannot use it, but if you're writing an application, you don't really care about, you're the end user of the language. So I think that Elixir makes more sense most of the time. If you're writing a library, it's different because right now it's really painful to use a library written in Elixir in an Erlang application. So if you want to write a library and you're writing the whole BIM community, it's much easier to write it in Erlang and consume it from both Elixir and Erlang rather than writing it in... And it's not always possible. I personally struggle with this because I would like to write Erlang libraries, but I also like some things like structs too much to give up and not use, right? And the same goes for, in some cases, where you have macros and if you write a library that uses runtime macros, wait, runtime macros meaning you use macros in your code that you use at runtime, then you can't use them in... Like you can call the macros from Erlang, right? The Elixir macros from Erlang. So if you need those kinds of things, you have to end up writing your library in Elixir, but I think Erlang, like the most important library in the ecosystem should probably be written. If they don't need Elixir features, I would think they should be written in Erlang. And a good example of this was recently was Telemetry, which is a matrix library that was written in Elixir, and then the authors realize why close it to Elixir, right? Like everybody can use this, so they rewrote it in Erlang, and if you're not using macros or protocols or structs or Elixir features, the port is pretty straightforward, usually. And yeah, that hopefully answers. Thank you. I haven't picked Erlang, and I wouldn't right now for most of the cases that I encountered, but at the same time, the Elixir does... Because it's more modern in terms of what the language looks like, it's more approachable, but once you've done, say, Elixir for some time, looking at Erlang code, it actually feels a lot more succinct. It feels like it's lesser code doing more work, and it maps. It feels like some of the rubies that are in Elixir are noise, almost, and not allowing you to directly talk about, like, I am sending a message that is it. I'm unable to give you a good example right now, but I have had this sense. I think Francisco, maybe a year ago, tweeted about this specific aspect, trying to compare that it's actually much more succinct to directly express in Erlang, and I think he should have been here, probably he would have taken the other camp, but... Well, I think that sometimes the choice of a language is an emotional thing. I mean, if you look at just strictly the expressiveness of the language, Elixir is a more modern language with more modern constructs, with almost everything that Erlang has. It has, especially the macros, that's a game changer when you can write code and code, because Elixir is basically expressed in itself, and Erlang can't be. When you're thinking about some of the macro-types extensions, you're doing that with essentially playing bytecode games in Erlang. So, part of the reason that we use languages is how they make us feel, right? And Joe Armstrong was a great friend of mine, and I didn't have the same experience with Prologue that he did. And so I can remember being in a room at a conference like this one with probably about the same number of people and sitting down at lunch, and he must have had bionic ears or something, because I mentioned something about Erlang's syntax. And Joe stood up and yells across the room at lunch, with conversation way over there, what do you mean Erlang has a beautiful syntax, right? And I was just incredulous, but there were so many people in the room that agreed and loved him. But it's like a comfort food. Languages can be that way for many people. So, yeah. And I now think Erlang is beautiful expressive for many problems. For me, although I'd love to write Elixir, but I find Erlang code easier to understand, because it doesn't have those modern constructs. It's very clear, but writing is difficult, but reading is like reading a book maybe, very to the point. You're just reading line by line. Nothing is going on, because you can't re-bind the variable itself, but it's the name itself. You can't re-bind that, so it makes it more clear. But writing is hard. Thank you. That was really interesting. Right. I know Robert Wording doesn't use either. He prefers to use LFE. He's a spirit heart, so he likes none of the above. I think we've just overshot the time unless someone has another question or we can start wrapping it up. Keith? Yeah, one more. What is the state of Phoenix in the world of web development these days? How does it compare in its maturity and tooling with Rails and Django and to what extent is it enough, if at all? Okay. In terms of the tooling, they're really different animals. But in terms of productivity, well, I think that one of the things that's happening is something is becoming important that has not been important before in the history of Rails, and that is really raw scale and raw horsepower. And that's because what we're trying to do is render a model for those of you who saw my demo on LiveView encoding the game of life, there's a new programming model where you're trying to update a model on the server side and based on that, build a web page and change only the values that have changed down to the client side. And to do that you have to have a very consistent transaction a transaction length, right? A very consistent latency on the user. And if you if you vary widely at all, which languages like Ruby and Python do, then you don't get that unified the super crisp user experience. And so I think that that's about to become really, really important and maybe the primary driver in web development. So my guess is that Phoenix is about to be really, really important even more so than it is right now. Thank you. I don't think at this point I would even compare Phoenix to this, they are slightly different piece. In my experience, Phoenix has been more like Sinatra or whatever the current word in the current Sinatra is, which is a thing that allows you to build your API and do that. It has had some features like live view which are you know, maybe a bit more complexity over just giving you a language to build an API. But there's definitely if you're building web applications, there's definitely some lack of maturity in certain like if you're talking about device for example to do authentication you wouldn't find something say as comprehensive or it's less likely that you'll find something as comprehensive in the Alexa ecosystem. But that said, like Bruce was saying the foundations for modern challenges which is performance and stuff are quite solid and I think for me at least it's more pleasant to be working on that foundation than being happy about device having some specific features that I need right now. Thanks a lot. Appreciate your time. Thank you everyone for joining in and that's it. That's a wrap.