 I'm really excited about speaking here. So at last Elixir days, I attended the conference and had a great time. And so it's a privilege to be speaking here this year. And I think it's a very cool venue. So today, I will be talking to you about why Elixir matters, or giving you rather a genealogy of functional programming. By way of introductions, my name is Osa Gaius. I work at a company called MailChimp in Atlanta that's a marketing automation platform for small businesses. While at MailChimp, I use PHP rather. I don't use Elixir. But for previously in my career, I used Elixir for quite some time. In addition to that, I helped organize the Elixir meetup in Atlanta, Georgia. And I've done so for almost two years now. And so what I'd like to do today is provide you with a historical analysis of why Elixir matters. Elixir's context in the world of functional programming and precisely how we can move forward as Elixir community when thinking about Elixir. The general outline for this talk with you as follows. First, we'll have a short introduction. Following that, we'll discuss what I mean by genealogy. Then we'll explore the history of functional programming before, of course, discussing why Elixir matters. We'll then wrap up with some thoughts on how we can move forward. So a few months ago, I walked into the Elixir meetup that I run in Atlanta. And I sort of ran the meetup and had the event as usual. And afterwards, a young man walked up to me and asked me a simple question. Why should I learn Elixir? As I began to talk through the features of the language, I paused. I realized at that point that I knew nothing about this guy. So I stopped and I got his name. And I began to ask him questions. I realized over the next few minutes that his question was a bit more nuanced. You see, he was attending a full-time programming boot camp and a general assembly and learning to program while working a regular job at nights. He rephrased this question a bit. He said, why does functional programming matter? You see, he was learning Node.js, Ruby on Rails, React.js, Angular.js, and a whole slew of other languages and frameworks and things in just 12 weeks. He was deeply, deeply interested in how to learn programming and how to get a job. And I could tell from his eyes that he was sleeping very little. On the nights when he wasn't working his regular job, he was attending meetups like mine to learn more about programming. As I looked in his eyes, I could see the bags forming. I could see that he was blinking really hard to stay awake. And I realized that his question was a bit more nuanced. His question was, why should I spend the little amount of waking hours that I have left to learn about this functional programming thing? I wanted to admonish him to understand how concurrency affects modern distributed systems. I wanted to tell him to run home and watch every rich, hickey closure video he could find because those lectures changed my perspective. They changed my life in some way. I wanted to tell him about recursion and how beautiful it was. But I realized at that point that this guy was hoping, praying, just to graduate bootcamp and get a job in a few weeks as a junior developer at some local company to stop his bartending job. More importantly, I realized that none of my answers to him were non-theoretical. I fumbled through an introduction to distributed systems, briefly sketched out the cap theorem and then told him to go on learning rails because when he was done with school, bootcamp, that was the best way that he could find a job in Atlanta, Georgia. I went home exhausted and rather tired and sad because I realized that I'd failed to defend my language of choice, to defend functional programming. Tired, I reflected on that event at home that night and I realized that I had a hard time explaining functional programming and why it mattered to someone so new to programming because I'd forgotten why I fell in love with functional programming. Like many of you, I've spent most of my career working in functional programming languages using these techniques, starting my career writing functional react on the front end to building back end systems in closure and then finally landing in the world of Elixir. I've had the privilege to be exposed to and being enamored by functional programming and for that reason, I often struggle to provide a credible and non-circular explanation for why functional programming matters, especially on Twitter. But more importantly, it's tough to answer the question why does functional programming matter today? A size of a portion of the folks that might meet up currently attend boot camp and they have a finite amount of time and so for them, there's sort of this challenge where they're trying to get a job as quickly as possible and just as I failed to defend Elixir, I realized that a fundamental presupposition of this talk is that functional programming itself has failed, which is to say that we, the functional programming community have failed. Failure, I suppose, stings. It hurts by definition and declaration. However, when we look at the top functional programming languages today, as you can see on the top programming languages rather, as we can see on this graph, none of them are functional. Whether we examine language popularity using something like the Tybee Index here, functional programming languages consistently do not rank at all. We observe instead that languages like Python, Java and even Ruby, languages we often make fun of as a community, they continue to flourish, as you can see on the graph. Even more alarmingly, if we define success as the availability of jobs, we come to the conclusion that functional programming languages have failed. As you can see here, in the last two years, functional languages do not offer the same number of jobs as even Pearl or a sort of often lauded language, PHP. So how can we in good conscience, how can I in good conscience, tell boot camp students who come to my meetup every week that they should go study functional languages? Now, I'm sure that we could, you know, however, describe and define success as breaking new research ground, inventing new concepts. However, that strikes me as somewhat dubious because it avoids the hard work of answering the question of why functional languages continue to lag behind. In fact, the prevailing argument of this talk rests on the claim that functional programming fails precisely because of our incapacity to be attuned to the real world performance of the functional languages we build and use. Our capacity to reverse the tide will be determined by how we learn from the mistakes historically made by the functional programming community. More to the point, in order for Elixir to develop a large and diverse community, we must assume that functional programming has failed because that pain is precisely what will generate a different approach. So with that in mind, let us begin then to discuss the history of functional programming. Most commentaries on programming language adoption in both research and industry fail to account for power as a constituent element. In other words, these commentaries assume that functional programming languages are chosen in the vacuum. There is a tendency to focus on language features, i.e. static typing versus dynamic typing. While important, this fails to get to the heart of why certain languages gain significant popularity and while others don't. Moreover, in the case of commentaries on functional programming, we especially fail to discuss why Erlang or Lisp or ML or Scheme fail to take hold. And instead we get muddled in discussions in person, on Twitter, everywhere, about features like currying or pattern matching. And in even worse turn of events, we as a community get sidetracked into discussions where we simply make fun of or malign other languages like Ruby or Java and we make fun of their founders like DHH and we say that they're very strange people. And that's fun and that's interesting and true in many cases, but it misses the point. It misses the point of why precisely functional programming lags behind. What these diatribes miss is what I refer to as a proper analysis of the past, a proper analysis of failure. I argue then that genealogy is a methodology through which we should analyze the past, through which we should analyze functional programming. Genealogy takes on two forms. First and foremost, it is an account of the ancestry and descent of a person, family or group. Genealogy allows us to understand a group of individuals or species that have a common origin. Put simply, genealogy is the story of how you came to be, from your grandparents to your parents and so forth. Secondarily, genealogy can be traced back to this man, Michel Foucault. Foucault was a French philosopher, a very smart guy, who thought of genealogy as an analysis of the development of ideas or truth through history. Now that's a lot so it's unpack it. For Foucault, understanding why one thing becomes more popular or takes precedence over another allows us to analyze or rather forces us to analyze power in a sort of social political sense. For instance, take this question. Why did the JVM, the Java virtual machine, become more popular than the Erlang VM? In today's commentary, the messy details of power and knowledge are left unanswered. Instead, we begin to discuss things like just in time compilation, or whether or not the Erlang virtual machine is indeed the savior of all. But from a genealogical perspective, we must delve into the gray, into the politics of industry adoption, into the undocumented conversations and code bases. So here I will treat functional programming as a family of languages with different species. And I believe that this will help us deconstruct the accepted precepts that we have about the development of functional programming and its adoption. With that in mind, let's turn then to a history of functional programming. We'll look at the history of functional programming from the 1930s up until this point, and then we'll stir a little bit into the future and think about what could happen. So it all begins in what we think of as the early period, what I call the early period. The early period of functional programming begins in the early 1930s and lasts until the late 1960s. We see that Lambda calculus emerges in the 1930s led by Alonzo Church's work. It's a system of mathematical logic for describing computation based on functions using variable binding and substitution. It is a model of computation that can be used to build a turn machine. It becomes a common ancestor for all functional programming languages to this state. In 1958, LISP was invented by John McCarthy. Building upon Lambda calculus, which we think of as this sort of very complex and strange mathematical form, LISP emerges as a way to make Lambda calculus more useful and more interesting. So in 1958, we see LISP emerge. It's important to note that LISP was not truly based on Lambda calculus despite using the word Lambda to denote functions. It instead was based on first order functions equations or first order recursion equations with dynamic binding and S expressions. However, it is considered the first practical application of functional programming to language design. To borrow CKUN's phrasing, LISP is basically Lambda calculus with a user-friendly appearance or syntactic sugaring. We enter the next period of functional programming in the early 1970s, a period that I refer to as the pre-renusance or we can think of it just as making functional programming more practical. Scheme emerges in 1970, marking the beginning of this period. While still academically research focused, we see an overall dedication to taking the early ideas from LISP and Lambda calculus and making them more useful for programming period. This overall sort of time lasts rather until the early 2000. Scheme is one of the main dialesques of LISP. To quote David Turner, the author of Sassel, it is not until this version or until Scheme that we see that LISP begins to actually adopt all of Lambda calculus. Put simply, Scheme took LISP and made it adhere to Lambda calculus. More interestingly, Scheme led to development of something that we'll look further at later called Common LISP. In 1973, ML continues the process of building upon LISP by adding static typing. It also introduces the novel concepts of pattern matching for function arguments. Pattern matching with thereafter become a de facto standard in most functional languages. In 1986, Erlang emerges. As you know, it starts at Ericsson as an R&D project to create a language to build a better type of telephone switch. Interestingly, during the early phase of the project, attempts were made to modify small talk and prologue for concurrent programming. So what's interesting is that Erlang begins not as a sort of functional language, rather as a concurrent programming language based on logic programming. Erlang also is notable because it's the first time in what we think of as functional programming where these basic functional idioms are merged very strongly with a concurrent programming model. This innovation of merging concurrent and functional programming with an emphasis for concurrency will permeate functional programming moving forward and will be something that highly, highly differentiates Erlang from the rest of the functional programming community. So with that in mind, we then move on to Miranda. Miranda is a descendant of ML, the ML language. It emerges in 1988 and it popularizes laziness within the functional programming community. Haskell then closes out the century in 1997. It borrows heavily from Miranda, especially with these ideas of lazy evaluation that Miranda introduces. However, it also introduces static typing, which we can then see as a move constantly to modify the existing lineage. The next phase of functional programming that we'll discuss is what I call the Renaissance. Following the late 1990s, we see a resurgence of interest in functional programming in a period that, although I call the Renaissance, we can sort of term something different. More generally, this period is characterized by attempts to make functional programming useful within industry. So we go from making functional programming practical as an academic process, and we go to sort of industry focused functional programming communities. We see the development of languages being led not by university researchers or industry labs, but by industry practitioners. We see people building languages to solve problems by compiling into other languages or compiling to other frameworks. It all begins in 2004 with Scala, a functional programming language that runs in the JVM or the Java virtual machine. Although object oriented, it borrows heavily from Scheme and Haskell, as well as from ML. F-Sharp, a direct descendant of the ML family of languages was introduced in 2005 and built on Microsoft's net platform. In 2007, enclosure emerges as another functional language on the JVM. However, although it leverages the power of the JVM like Scala does, it does not borrow any of the sort of object oriented features from Java. It instead adopts common lisp, which we discussed before as a sort of main dialect. It adheres to the syntax of common lisp as well as the overall program model. In 2008, 2009 rather, ACCA emerges. Although not a functional language, ACCA is important in the history of functional programming because it symbolizes the renewed interest in the intersection of functional and concurrent programming as we mentioned in the case of Erlang. It was an idea that Erlang opened and sort of popularized and by the point that ACCA emerges, it's better to become the industry standard. Now, what's interesting then is when we leave the sort of phase in which ACCA becomes popular, we see rust emerge as sort of another language that sort of takes the core ideas around functional programming that are developing and reintroduces static typing and some type safety. So we then again see that this sort of emphasis within the functional programming community on safety as the sort of constituent element in language design. Following this, we see our language of choice here, elixir emerge in 2011 as a language built from Joseva Lim's experience in the Ruby community and the Rails community, but rather on the Erlang virtual machine. So again, we see this sort of move to take functional programming ideas and simplify them and make them more useful for industry purposes. And lastly, we see elmi emerge in 2012 as sort of the first instance where we see functional programming really begin to take hold in the functional sort of front end community. We can see this then begin to develop with react and redux and closure script moving forward. But elm sort of closes off the century or closes off the Renaissance period and we then see that functional program is taken hold. We see popularization elsewhere. But then the question is, why does elixir matter? Elixir happens in 2011. Why does this stand out in the Renaissance period? And then what does this mean for us? So with that in mind, I think when thinking about why elixir matters, it's important to contextualize why Erlang matters. This quote from Joe Armstrong, the founder of Erlang in 2007 as he reflects upon the history of Erlang is quite apropos. He says, the rise and the popularity of the internet and the need for the non-interrupted availability of services has extended the class of problems that Erlang can solve. Now I think this is interesting and I think it's quite apropos giving sort of Erlang's place in the community. However, I think that in order to answer the question why elixir matters, we have to sort of take issue with or dive into this quote in a bit more detail. For one, it is true that today industry is focused on building resilient services and systems to solve particular problems. So the question perhaps then is why are we not seeing a rapid rise in the popularity of Erlang? Why are we not seeing Erlang rise to the top of that sort of top 10 list that we looked at earlier? In other words, why is Erlang not the most popular language? If it's designed to solve these particular kinds of problems. I think to answer that, we also have to answer the question, why does elixir matter? Why is elixir not on that list? And I believe that there are three axes for how we can think about this. The first is around syntax. Just as Lisp is sort of syntactic, sugaring on Lambda calculus, we can say that elixir and Phoenix are web focused sugaring on Erlang. Although elixir is a language on its own, a crowning reason for its ability to take and become popular is because it represents Erlang to a new generation. We can then say that Erlang in some way fails or misses opportunities because it's syntax wasn't designed for general purpose use, whereas languages like Java, JavaScript, et cetera, modify themselves and shape themselves to be either similar to each other or to be similar to languages that developers were used to using. Whereas Erlang was such a large deviation given its sort of background in prologue and small talk. So I think syntax is sort of one axis that we can think of as why elixir matters, precisely because it is a syntactic sugaring on Erlang that represents Erlang to the new community. And I think the second axis we can think about is the web. I think we, and when I say the Erlang community, I use the term we because I think we are all part of the Erlang community, although we are part of the elixir community as well. I think we missed the opportunity in the context of Erlang to help shape the web. In other words, although technologies like RabbitMQ and eJabberD are built on Erlang, the language itself does not hold as a general purpose language for building web server programming language, well, web servers. Now, it's true that you can use Erlang for doing these things, but it is not popular for doing those things precisely because Erlang as a community fail to adopt the web and fail to popularize itself as we can see in the case of Java and JavaScript or even Ruby. So if we look sort of historically, we can see that Erlang emerges in 1986. Java then emerges in the late 90s, followed by JavaScript, Ruby, and then finally Rails. So while all this is happening, we're seeing sort of Erlang sort of stay in the background while these new languages sort of take hold and begin to shape how the web sort of forms. Now, by contrast, elixir was built from the beginning with the web in mind due to Jose's background as a Rails core team member. He aimed to solve a problem that he had in the same way as other participants in the Renaissance period, aimed to solve problems that they were having at their jobs. The development of Phoenix and the emphasis on Rails-like simplicity, while some folks like Rob Connery might take sort of offense with that, is actually very useful with regards to web development because it actually helps us sort of take Erlang from being the sort of background language, just sort of telephone switch language to being a sort of general purpose web language. So I think, again, that's sort of a reason why elixir matters precisely in the case where Erlang fails or misses the boat. And the third axis I think of is evangelism. If we examine Java, JavaScript, Rails, and even a modern language like Go, we see an emphasis by companies and the stewarding organizations on promoting the language. The reality is that Ericsson, in the case of Erlang, did not emphasize this. At least not in the extent that, let's say, Sun Microsystems or Oracle did with regards to Java. In the case of JavaScript, Netscape, who, of course, wrote the language in 10 days, and the Mozilla Foundation, were very, very aggressive in promoting JavaScript and ensuring the use of a language on all web browsers. It is somewhat ironic to note that JavaScript was originally based on scheme of functional language before it sort of took a different path. However, if we revisit Joe's quote, I'd argue that it is more accurate to say that elixir extends the class of problems that Erlang can solve in the age of internet services. But how do we, the elixir community, which is to say the Erlang community, ensure that this actually happens? How do we ensure that elixir and Erlang rise to the top tier of programming languages in the next decade? Well, that brings me to the next section. So there's this quote from Meyerovich and Rabkin. They perform sort of this large analysis of GitHub, of source forge, of languages that are popular, and they make this sort of last statement that I think is apropos. They say that unpopular languages are niche languages. And so by definition, we can also say that niche languages are unpopular languages. So I think for us, it's sort of something to take note of and to sort of take creed to, which I think is that breadth versus depth is sort of an important context to think of. When moving forward as a programming language and as a community, we have to sort of make a choice. Do we go deeper into functional programming? Do we begin to implement monads and go all the way down that path? Or do we sort of become more encompassing and wider? Do we begin to build libraries from a practical things? I think when thinking about breadth, I think there are two axes for us that matter. I think when trying to become a wider, more encompassing language, I think the first is libraries, libraries, libraries. So you think of Ruby as being sort of very, very much popularized by the fact that you could have a gem for anything you wanted to build on Rails. If there's a problem you had, there was a gem for that, we can go back and forth on whether that's the best approach to programming. But more generally, the idea that wherever you have a problem as a programmer on your job, that there's a gem or a library in your language community to solve that problem, that generally helps you convince your boss, it generally helps you convince your coworkers that we should indeed use this. So I think for us as a community, sort of the challenge is over the next couple of years is to make sure that whenever there is a library or sort of a problem to be solved in a business context, industry context, that we have the tools already built in our community. So you think of basic things like database drivers for things like Cockroach DB. It might not be exciting and great and functional in computer science work, but it's work that has to be done for us to actually become sort of a large and more encompassing community. I think the second is around domains. I think niche languages are not just niche languages because they go deep. They're also niche languages because they're only concentrated in one domain. So whether that be the web or whether that be sort of particular tasks when it comes to things like Python or regards to scientific computing. I think for us as a community, we have to widen the domains we're in, whether that's going into scientific computing, whether that means things like nerves going into embedded systems. I think widening the domain is something we have to do in order to prevent the challenge where all functional languages tend to have which is that they become very domain specific. They almost become DSLs. So the second sort of axis that I think matters when moving forward is evangelism. And I think evangelism is particularly tough because we're all engineers, we're all builders. We think of ourselves as thinkers, not as like speakers. But I think it's a challenge, right? Because when we look at sort of Java, we look at JavaScript, there's sort of a massive marketing push in the 90s and the 2000s for these kinds of languages to become the de facto standard. And they did indeed become the de facto standard, right? So I think there's work to be done in our communities to market our language. This might not mean having an extensive marketing budget like some micro systems or Mozilla and Netscape, but it does mean that we have to think about how do we market our language to programmers? How do we sell our language to programmers in a way that's not just based on, well, these are the features and here is why it's better, but maybe these are the things that can do for you. And here's how you talk to your boss about it. I think the second is around consultation. I think that there's great work being done by Erlang Solutions and other folks like that to take Erlang into industry practitioners and say, let me help you solve your problems. And I think that's something we have to do as a community. I see this in my meetup where I go give people sort of free consultation on here's how you could use Elixir. Regardless of whether or not they actually use it, that work is necessary because it is actually how you get folks who don't already buy in to function of programming to begin to think about these things. I think the last axis is around fanning out. Fanning out is tough. I think we as Elixir folks like to come to Elixir conferences, but the hard work is actually in going to conferences that are not Elixir based. So going to the JavaScript meetups, going to the Java conferences, and maybe sneaking a talk or two in there about Elixir that folks might not expect. I think that's where the hard work comes because that's about convincing folks who aren't already convinced to use the language. I've already done this, I go to React meetups and I give a talk about React, but then halfway through I actually talk about Elixir and give a one-on-one to Elixir. It's a great strategy. Just don't really tell people that that's your strategy. Just tell them you can talk about React. And then dovetail things into a functional programming introduction. And what I found is that folks actually appreciate that because they learn a lot more than what they learn by just coming to a React conference. So with that in mind, let's conclude. For me, I think the history of functional programming is not static. It is always already political. We, the folks in this room, that we being the airline community, we being the Elixir community, we are responsible for determining what the future of functional programming will be. I think this quote from Franz Fanon, the Martinican philosopher, is quite instructive. He says, I do not have the duty to be this or that. I am not a prisoner of history. I think for us it's true. We are not a prisoner of the history of airline, or the history of functional programming. We have the ability to make history anew. And if we return to the story that I began with, I'd like to couch my hope for Elixir in the context of that story. My hope is that a decade from now, my answer to that bootcamp student of why should I learn Elixir, will be you should learn Elixir because it would get you a job. In fact, you can't get a job if you don't know Elixir. That'd be even better, right? In the same ways, you need to know Java nowadays or Rails to get a job. Even more so, my hope and my prayers that developers like my niece will grow up in a world where she does not even have to ask the question, why does Elixir matter? Because why Elixir matters is already self-evident. Thank you. Thanks for the talk. I thought you made a lot of good points on how to improve success, but the premise of how we measure success, like job postings and things of that nature, anecdotally, in my experience, functional teams are very small and very long running. So job postings is that really a really good measurement of success. And its popularity really tied to people's day-to-day use on the job. So, do you have an opinion on what a better measurement of success would be rather than just job postings? So that's a great point. That's the two things, right? One, thank you. I can't speak to that. I mean, I think two points, right? I think the first is I would caution us against throwing out the measurement of success that exists today, right? Precisely because that is exactly how functional programming has proceeded over the last 20 years to say, well, our teams are really small and we're a niche and popularity doesn't matter. Haters go hate, right? I think that's a move that, while compelling and while as a scientist, I'm like, yes, of course, there are different measures of success, actually betrays us because when other folks in the outside looking in look at us and decide, do I use a language or not, they are not assessing based on our internal measures of success that make us feel better. So I think, yes, success measuring is hard. Do I think that we will ever be in the top 10 or that we should hate ourselves if we're not? Of course, we should not base that as the only measurement. But I think we should strive to be in the top 10 because in that striving, although we might fail and because our communities are necessarily smaller, our teams are smaller, we actually can aim for more. So if you think of it, let's say there are 100 Java developers, we could build a team of just 10 Elixir developers and replace them. But if that's the case, why don't we build a team of 100 Elixir developers? And maybe we can solve even more problems. And then with regards to maybe, are there other measures of success? I think one is like, is the Elixir days conference getting larger? Yes, actually it is. Yay! We had more numbers this year than we did last year and last year we had more numbers than we had the year before. So. And I was here last year, right? And then so like to see a lot new faces and new people and new speakers, I think that's an internal measurement of success that we should hold on to and say let's continue doubling, tripling the size of these conferences we go to. Let's increase the size of people on the Slack channels, et cetera. But I think again, that's an internal metric that we should hold on to and we should share with people but we should not congratulate ourselves too early because again, it's very easy to plateau and become a niche language. Hi, is this too loud? No, we're good. I'm thinking about the point you raised about making sure that we have some outreach outside of our community and it's really easy to keep going to all these events where we talk about Elixir with other people that do Elixir and it's fabulous and we're self congratulatory and super fun and then you talk to anybody outside of the community and they're like, so what do you do with this thing? And I like the idea that you have of going to other conferences and speaking but for those of us that aren't really conference speakers already, do you have any other good places to start for I guess doing some low level of advocacy? Yeah, that's a great point. So actually, I wasn't speaking at conferences for a while so I had to develop some guerrilla tactics to do this. So what I would say is if there are any language communities that you were part of before Elixir, so if you were a node developer, if you've been doing node for six years like Rob Connery, then go to all the node meetups that you aren't in your town, just go and just show up and people will become your friend and ask you questions and then you can slowly start evangelizing like hey, yeah, I don't do node anymore, I do Elixir now and that's a perfect segue because they understand that you aren't like some weird strange person that you care about them as well. So I would say start with going to the language communities that you are already part of like whether it's React or it's node, et cetera, PHP and just have conversations with people and then when you fill up to it maybe tell the meetup organizer, hey, I'd like to give a talk on how to go from node to Elixir or how to go from React to Elixir or PHP to Elixir. Like there's so many talks to be given on that at a local meetup level to 10 to 20 people and then as you work your way up then yeah, you can start going to the node conferences and spreading the message that way. That's really helpful and also is there a way that we can do some outreach outside of just programming language communities so we can advocate more usage within the business community or anything along those lines? Yeah, that's a great point. I think there's sort of two communities that I think are under-served. I think one is the business community so folks who are just solving problems every day, they chose the language five years ago at their company and now they're just trying to go after problems. I would say one way to do that is to think about what friends do you have with those companies that are around your town and just have lunch with them or coffee with them and say, what are you working on? And then they'll tell you, we're trying to scale out this service or we're trying to build this new microservice or be like, hey, check this thing out. I think it's very much around relationship building, not heavy-handed stuff. I think the second community is folks in school, whether folks in boot camps. I taught a high school class where I taught functional programming last quarter and that's a great opportunity because all of those kids now grow up with Elixir and React as part of their knowledge base. So I would say, look for chances that maybe boot camps in your area where you can go volunteer and maybe sneak in some of these ideas by teaching a one-hour class on what functional programming is. Question here. Let's say you've managed to interest someone in the language and whatnot. Now they are starting to interact with the Elixir community. What's your point of view about how that happens today and what could be improved on that point? Oh, man. I think it's great. I think the Elixir community is amazing. I think we're talking to someone about this last night. I think we're very friendly by default because a lot of the folks here came from the Ruby community, right? And we're very humble, but I think there's more work to be done. I think there's a tendency sometimes to want to prove that we are smart and prove that we are smarter than other people. I think that might be useful when at other places, like if we're competing against Java or something, it might be useful to say, we're better. But within the community, I think it's important for us to remain a very beginner-focused community that lets newcomers quickly learn, quickly get valuable language. I think work to be done around improving education is something we can do. I think things like Elixir Fountain, et cetera, are part of that work. But I would say we're in a good place as a community and we just have to continue focusing on being beginner-friendly as opposed to becoming very esoteric. So you talked a little bit about teaching Elixir at boot camps. I'm wondering how long and how far out do you think we are from potentially teaching Elixir as the functional language we teach in a more traditional past like college, like where we could get grassroots adoption? So that's a really fascinating idea, right? Because it's actually an old idea, like a Lisp and a bunch of functional languages like ML were actually invented for teaching, right? There aren't actually languages that were ever invented to do actual programming work, which is the reason why they never got adopted really. But that's good. Like that's a really good thing. Like we made languages because we thought that there would be a better way to teach people how to program. So I think circling back to that, I think one of the challenges is to get a job today, you need to know Java generally or C++, some sort of object-oriented style. And so as a professor teaching at a university, I am not going to teach my students Elixir because I have no idea whether or not they can get a job at Elixir. So I think there's work to be done for us. Like if you went to college for programming, message your professors and be like, hey, I've been doing this Elixir thing and like there are lots of jobs for it and would you consider like letting me come into your class and give like an hour long like speech about Elixir? Or have you considered using Phoenix instead of Rails? Because that's sort of a common thing now is to teach Java in like the first semester of senior year and then teach Rails the second semester of senior year. So I think it's an opportunity to kind of slide ourselves into where Rails is sort of fit in as sort of a web-focused language and tell people, hey, like if you're teaching Rails, consider teaching Elixir instead or in addition to just so your students are exposed to it. But I think that's work we have to do. I don't think that there's gonna be some committee that happens like where all the universities in the US decide like we're gonna use Elixir now. I think it's very slow work that starts with if you've got a prof from college, message them and tell them like you could use Elixir and their jobs for it. All right, thanks, Elsa. Thank you.