Elixir and the Future of Phoenix

I'm Joseph Ali and you're listening to the Changelog. Welcome back everyone. This is the Changelog and your host, Adam Sokoviak. This is episode 194.

It's a big show today. We got Jose Valem. On the show we learned about the early days of Jose's start as a programmer. Jose took us back to the beginning of Elixir and shared why Erlin got him so excited.

We broke down the features of the land. We talked about functional programming, we talked about concurrency, developing for multi core systems. We talked about the Elixir community, the future of Phoenix, Ecto and so much more. We had four awesome sponsors.

Toptal, Rollbar, Linode and Truesight Pulse. Our first sponsor of the show is our friends at Toptal, the exclusive network of top freelance software developers and designers. Top companies rely on Toptop freelancers every single day for their most mission critical projects. At Toptal, you be part of a worldwide community of engineers and designers with the flexibility to travel blog on the Toptal Engineering blog.

Apply for open source brands or for scholarship options for our fellow women developers out there. Lots of opportunity inside of Toptal for you. Head to topta.com that's T O P T A L dot com to learn more or email me at adamsball.com if you prefer. A personal introduction for friends at Toptal.

And now onto the show. All right, we're here today talking about Elixir and Jared, you know we've, we've wanted to have Jose on the show for so long. We had several issues come up and just I think you and I might have exchanged some sort of GitHub message way, way back in the day trying to get you on the show and you were still working more so on rwby. But it's been a long time coming, my friend.

A lot happened in those. I don't remember when, when we talked, but when I look back, there are so many things that happened last five years, which is just crazy. And Jerry, like any good show, it begins with issues. How does one come about?

Yeah, multiple issues like you said over the years. I think the last time around was like the end of 2014 and we couldn't quite schedule an hour lineup of shows a day. But we had Chris and Cord on the show talk about Phoenix specifically, which was a great episode. If you're interested in that, check out 147 which was like last March.

And that kind of counted to our Lister show for a while. And then recently in December, Jose, one of your counterparts there, platform tech George helped me with the name Jose Georges. Yeah. So shout out to George for hollering again and saying, you know, we had some big milestones.

Elixir 1.2 or Zacto 1.2 and Elixir 1.1. I can't really exact version numbers and it's time to get him on. And. Yeah, Elixir 1.2, Ecto 1.1.

So thanks, George and Jose, we're really happy to have you on the show. Thank you. I'm glad to be here as well. You had Chris back in March last year.

Yes. Yes. So we have a lot to talk about. Yeah.

Lots of change in Phoenix as well, right? Yes. I think March, it was not even 1.0 yet. And I think March was when I was actually starting to contribute to Phoenix or I had just started and then we had like this great, let's say Sprint, where Kriez and I were working and we're improving things and I think we got like the 10 about July stuff like this kind of middle of last year.

Yeah. So we have a ton to catch up on. Adam and I are quite excited about both Elinixer and Phoenix. So we have tons of questions for you.

It was like one thing we like to do kind of as an intro to the show is to get to know the people behind open source, because we find that's super interesting and enlightening. So from the Internet, you know, from following you and your work, we know a little bit about you, which is that you're Brazilian and you live in Poland. We know that you crank out a ton of open source stuff. You also seem to be, just from my experience online, like, super nice and a positive person.

But we don't know very much about beyond that really, of your background and how you came to be where you are. So we'd love to hear developer origin stories on the show. And so if you're willing, you'd like to hear kind of your origin story, where things began for you in software. And then how did you get where you are today?

Oh, okay. So I would say things like my first real contact with software was at university I went to do. So I grew up in the center of Brazil in a small city called Nunes, and I moved to Sao Paulo, which is, you know, big city and everything, for studies to do, my university, which end up being Automation, Control Engineering, which I don't use for anything. But anyway, and the first year I had a programming and that's how I started programming.

And I have very good. And I have Very good memories from those classes because I remember, you know, the professor would program the whiteboard, which is a little bit weird, but he would say now you need to declare this variable like int. And he would say you need to do this. And then every time he said like you need to or you must do this, I would ask why?

What would happen if you don't? And he was like very, he was a little bit peculiar with the professor but he would always like entertain my questions. But that's the point. He got like he couldn't take anymore and then he like, why do you want to do it?

Your software? Like you need to follow those rules. Why the rules in place, man? Tell me.

Yeah, exactly, right. I just wanted to know what was going to happen. And you know, but he said that like it was also interesting because you would say like, oh, the variables would need to be initialized, right. But you see, if you don't initialize, something is going to happen.

Just going to have whatever. His memory and those weird questions actually made his. Made him tell this stuff as well, right? Like what are the consequences if you don't do something?

So I feel like you could learn. And hopefully I was not just the annoying person in the classroom getting in the way of teaching. But that was pretty much like my first contact with it. And then it's still the first year university, me and a couple friends, we had a band, was an acoustic band and one of the players of the band with me is Hugo Baraumundu which is a co founder of Platform Attack with me.

So we had like a lot of star together at Sardis at university and we had a band and I decided to make the website for our band using Flash and Action Script. So this is like the first time I was like, hey, I'm going to learn things for myself and I'm going to try to make this work. And I was doing it out of, you know, it was not because I had classes, even though I enjoyed like the C classes. I was actually doing this because I wanted anyone to learn and that went pretty much like that.

I also remember that at some point I went from. I started learning more about databases, you know, my SQL probably at the time. And then I ended up going to do PHP and MySQL. It was a very short period of time.

I did a couple projects as a freelancer. I remember like a couple interesting stars as well because we were seeing the band. I was always very passionate with music. I remember at some point while I was still in university I went looking for like a music school.

Like I don't know if it's conservatory in English or how you say that. And I remember I was checking on the Internet which ones had really horrible website and I called them and I was saying like, hey, if you give me like classes on singing or guitar, I'm going to do a website for you. Like, if you give me six full of classes, I'm going to do a website for you. So that's something that happened at the time.

Did that work? It worked. I got, I got my six months of singing classes. Yes.

So you're basically trading website for educations. Oh, sorry. So you're basically trading website work for an education and singing. Yes, exactly.

I couldn't afford to sing classes that I thought really good. But so, you know, that was a plan that worked. And they're like, well, we really appreciate it in my side. So.

Yeah. So, you know, so it was pretty much that. Nothing serious, just doing things on the side even. Because the engineering versus, you know, required a lot of time.

And it was at the end of 2006, I had, we were a couple friends and that was when I actually met George. That got us here on the show. It was about 2006 that we got closer and then he had some ideas for startups and Rails was already, you know, a lot of people were talking about Rails. I decided to try it out.

That's when I got started with Rails. And yeah, and then a lot more happened regarding that. I was, I was doing Rails for quite some time and at the end of my university they have an agreement between. So at that point I was still in Brazil, but the engineering school had an agreement where I could go on and do my last year university in another country.

And that's when I moved to Italy and that's when I left Brazil. And it was really funny because when I left I was like the whole course was like two years that I had to finish and then I was thinking, well, you know what, I'm just going to go stay there six months and then come back. I'm not even going through the whole two years. And then I never came back, I never came here.

Yeah, but that's how I went abroad. And that's kind of what explains how someone from Brazil is leaving Poland. I met my wife, my wife's Polish and now I live here. I'm living here in Poland for five years.

I was gonna, I was gonna ask what kept you in Poland, but then you told us you found a wife and settled down, so. Reasons congrats on that. Yeah, exactly. Thank you.

So you mentioned you're doing Rails work and many people I think probably in our audience who know you and may not yet know you with regard to Elixir, probably know you with regard to the Rails work that you did, which started off as device. Right. Or maybe that's not the starting point, but that was the gem that you and your team at Platform Tech built that became kind of one of the de facto authentication tools that people use on rail even to this day. Can you tell us about that kind of that section in your software career with regard to devise and working with Ruby and then eventually on the Rails core team?

Sure. So yeah, it was a little bit before that and there's a very nice start here because I remember my first open source contribution which we had. This was brought back 2006, 2007 and I sent. We had a plugin called Upload Column, if I remember correctly, for Rails.

And I remember sending a patch by mail to the altar like, hey, what if we did those changes? And it's really nice because I later, you know, the author, the owner of that package is Jonas Nicholas and he went to write Capybara, he wrote Karawave and the new Refile plugin for Rails. And this goes like way back and probably 2006, 2007, like you're exchanging. Exchanging patches.

And it's nice because recently he started coding with Elixir as well. So that's a fun side story. But that's like what I remember as my first. My first Dabney had open source and a couple years later, I think it was 2000-8009, I actually created something called Inherited Resources which was.

I don't know if I ever got to use it, but it was the first thing that started that I've written myself and started to gain some attention. I also, I don't remember for those who are doing Rails for a long time as well, I don't remember the time, but we also had something called Rails Footnotes, which was a plugin that you had to. You could define a reciprocation and it would add a bunch of footnotes at the bottom saying, showing like what was the request parameters, what was in the logs. So it gave access to a lot of information.

It would show like which queries ran and how much time it took. And I also contributed to that. But the first one was exactly inherited resources. And with inherited resources.

So this, if I were 2009 and we had the Google sort of code happening and this was when Rails 2 was starting to become Rails 3, right? The work towards Rails 3 had already started and Google summer of code was happening and I was still a student at the time so I wrote a proposal for the new generated system which I specific is the very system using today in Rails. And the way I got the proposal was, you know Rails 3 is meant to be agnostic and everything, right? You can bring your own Orion layer to bring your own like task framework.

But then I said like we cannot really say that Rails is going to be agnostic if the generators they are still going to generate only active revpar stuff, right? Like at rails 2 if you're using rspec you need to use like rstack scaffold rspec modeling not play together. So I wrote this gooser of code proposal and for the Legionary system it was accepted. I worked with Hibudicat that he was my mentor and that's how I started to.

It was a really great opportunity because you know contributions on GitHub was not that easy at the time like how the it was new so it was hard for you to be really in touch, you know like with the people actually building the software and those I got really close to who they became good friends and that's how I got like my first decontribution to Rails and then you know, I started contributing more and more eventually became part of the Rails core team. It was also at the time that we started Device and Device it was part of our platform attack. We hired at the time our first person we were in 2009, the company had just started so we were for the four founders and we hired Carlos Antonio and one of the reasons we hired him was actually because of his other contributions to other open source projects and he started working on Device and working together. I was kind of more doing a mentorship role and days but then Device grew up, a lot of people started using it and it's our biggest open source project for the Rails community in particular.

And we have other ones like SQL 4 and so on. Yeah, I actually forgot about Inherited Resources we call it now. And as you spoke about it it kind of reminded me of what you were mentioning back with your professor in college asking why because correct me if I'm wrong, wasn't the purpose of Inherited Resources was to really dry up the controllers quite a bit inside Rails and remove a lot of the the kind of the boilerplate which is scaffolded out in a typical Rails controller. And it just seems like that was you basically asking why with regards to how we do controllers in Rails and kind of your answer to a different way of doing that.

Yeah, so the whole idea is that you inherit from inherited resources base or something like that. It would bring the whole, the whole, you know, it would have the point limitation that does everything the Rails upload supposed to do. And this is usually like what VR controller typically does is that, you know, you need to have like the query part where you need to say, you know, if I want to get the current, the current manager for this project inside this company, you need to build the query. Right.

And often use it. So that was one thing, the other one is how to render those resources. And that's kind of what was in there together. And eventually at this point if you go to the herd resource projector and say, hey, don't use this, we don't want this anymore.

We don't recommend people to use it. Exactly. Because it just hides too much. If you have some place like ah, this stuff would really rarely rail.

There's a lot of border plate and the hairdresser has none. We had to find a balance somewhere. And a hacker was too much to the extreme, to the point where you look at a controller and you're not really sure what it's doing or you would have to, or you would summarize like one of 20 callbacks and then you actually have not a lot of confidence at how that works. Yeah, that's actually my exact experience.

I had one situation with it. I actually inherited a project that used it and it took me a really long time just to figure out what was going on because where was all this activity coming from? And then once I, once I realized it, it started to make more sense. But again, like you said, it's funny that the question is why?

Why are we doing this boilerplate. And it's a super useful experiment. Like let's, let's see if we can just dry this up and not have to do it. And then over time you learn.

Well, it's also helpful for it to be obvious what's going on. And so you're hanging a lot on the covers there. So yeah, interesting stuff. And so devise came later and was like you said, part of platform tech.

We're going to do a break here real quick, but can you just give us a real quick synopsis of your company and platform tech that you founded with four other people and its purpose and kind of how it plays into open source? Sure. So platform tech, we are a consultancy based in Brazil. I said like 2009 we were four, but now we are about four developers and we work with both well established startups and big companies, Fortune 500 for example.

And what we're really good at is to go there and if you're having hard problems to solve, you come in and you're trying to make your whole process around the software development more efficient. And the relationship with open source was exactly when we started was I was doing open source. So you know, we started us four and for a while we didn't have any clients. So I had a lot of free time and that's when I wrote Inherited Resources.

And what happened at the time is that we started to get a lot of clients because of our open source work. So we knew it, we knew at a point like hey, investing open source, it also helps us to grow the company. And as I said, the first person we hired was also because the open source contribution. So it's not we can get clients, right?

We can also it helped us to attract good talent and that's how it, you know, was our relationship with Open Source. But, and it changed a lot with Elixir, I would think because with Elixir it was when we decided to make a huge bet, right? When you say like, hey, what's investing in Language. You're no longer talking about, you know, making a small project for the community.

You're talking about, you know, investing in something for a long period of time that has also a higher risk because you can invest like three years and nobody uses it, right? So what, what's going to become of that? We did a great job there teeing up the next thing with the shows and we obviously want to dive deep into that, that big bet you mentioned, which is Elixir. So we're taking a break, you know, great learning about your origin and all that.

I guess it will definitely delve quite deeply into your passion for multicore and Elixir. So let's take that break. We'll go down deep. We come back, I'm excited to say about a new sponsor of ours, rollbar.

One of the most frustrating things about being a software developer is dealing with errors. Relying on users to report your errors, digging through log files, trying to debug issues or a million alerts, flooding your inbox and ruin your day. With rollbar's full stack error monitoring, you get the context, the insights and control you need to find a fixed bugs faster with a lot less noise. Rollbar is easy to install.

You can start tracking your production errors and deployments in eight minutes. Or less. And rollbar works with all major languages and frameworks including Ruby, Python, JavaScript, PHP Node, iOS, Android, Elixir, and more. Integrate rollbar into your existing workflow, send error alerts to Slack or Hitchat, or automatically create new issues in GitHub, Jira Asana Pivotal Tracker we have a special offer just for you, our listeners.

Go to rollbar.com changelog Sign up and get the Bootstrap plan free for 90 days. That's basically 300,000 errors tracked for you. Totally free. Rollbar is loved by developers at awesome companies like Heroku, Twilio, Kayak, Instacart, Zendesk, Twitch and more.

Give rollbar a try today. Head over to rollbar.com changelog all right, we're back from our break. We got Joseph Lim here. Long time in the making this show, as many shows shared, it came from an issue, but it goes much deeper.

Fuse. It came from Ruby roots and you came from roots where you kind of got. I don't want to put words in your mouth, but it seemed like you kind of got bummed about the lack of multi core systems and concurrency and all these other things that other languages bring. And obviously we've got Elixir now.

So maybe let's begin with that. Tell us a story about how it began for you and Elixir. Where were you at with Rails, where you at with Ruby and what kind of sparked this interest of multi core concurrency and ultimately Elixir? Yeah, that's a great question because I was working with Rails and I was one of the ones responsible, not responsible but working with making Rails try safe and it was really hard and we worked a lot on improving Rails.

So if you go back in time like rails 2.3 said that rails was finally thread safe, but it was thread safe by putting a huge locker on your application which is not what you want because you're not going to leverage your currency. And then we wanted to improve this more and more of time. It was a lot of work. And then when you thought like hey I can finally make this work, then you realize that it doesn't work on JRuby or Rubinius because they give you different guarantees regarding thread safety.

So it was really frustrating work. And as you know, like if you're using Threads and Mutexes and so on and have a lot of state around, which is what we have in our regular Rails applications, sometimes you do know that there's a resolution, there's a compressive coin there. It's just when you're running in production under certain scenarios or particular high loads, right. That those issues are going to show up and then they are even harder to debug and try to give a guaranteed safe for sure, hey, this is thread safe.

So I was working with that and then what came to my mind was that, you know, I was already hearing this was I think spasmodic 2010. I was already hearing like, you know, concurrency is becoming more important. That's why one tried to save it in the first place, right? So we could get our resupplication, put it in standard production and if it had like four cores, it would use all the four cores efficiently without needing to start for instances, for example.

So I knew that and this was become important. But I said, you know, like if this is going to be the future, right? If the future is going to have like 8 cores, 32 cores or 128 cores, we need to have better abstractions because the ones I had working Rails, they're not going to cut it. So I decided to study other languages and see what they're doing.

And the idea was exactly to kind of see what happened there and try to bring it into Ruby and into Rails. And I did. I spent a good period of time studying on languages and so on. But the one I really, really loved was Erlang.

And the reason why I really liked Erlang as not only the language but also the whole virtual machine was actually because to me they were no longer, they were not doing the concurrency. They're not worried about concurrency, they're actually worried about distribution. Right? You're not writing software and you're saying, oh, I want to make this software concurrency.

They're saying, hey, I'm writing this software and this software can be distributed, which means it can run on multiple machines. Right? It just happens that you know, our model when you're running multiple machines, it also happens it can run everything in the same machine in get concurrent for free. So I'll expand a little bit on that, which is so when you write software in Airlink and now today in Elixir, all of our code, it runs inside the processes and the machine is like it's 30 years old, it has been there for a while and when they were writing it, they were not worried about concurrency, the multi core concurrency at the time, because you didn't have multi cores at the time.

But so when you're writing code, had your code running processes, right? And those processes are not operating system processes. They are very lightweight threads of execution. They're very cheap.

You can create literally millions of those and it was everything done in a way where, you know, I can have a process running this machine, I can have a process running on another machine. As long as the machines are connected as part of our cluster, we can exchange messages between them and all the processes are running at the same time. And that's what they built at the time. And then when they needed concurrency, they just realized that concurrency is a special case where you have all those processes, but instead of them running in different machines, they're only running the same machine.

So you just can get a little bit extra guarantees for that. But it's really a special case for the model to have that. And when I saw that, I found it beautiful. Right?

Because if you think like we as software, you know, the industry is changing right now we are hearing more and more languages oriented towards concurrency. It may be at some point that we're going to hear more and more languages that are oriented towards distribution. And everything is already there, has been there for 30 years. Right.

So that was really fascinating to me and I was like, no, if I want to try software in the future, I want to try software that's going to run on these robot machine. And that's what got me excited and led me down this path. So just to give us some context, what year was this when you were formulating, you were conceiving the idea of Elixir? What was the time period?

This was 2010, at the beginning of 2011. So the first coming to Elixir was like January 2011. And it was the time I started software. I started writing more and more early.

But there were a couple things that I really feel like was missing in language. The way I like to sum it up is that I liked everything I saw, but I hated the things I didn't see. I wanted, for example, really good Unicode support, I wanted good abstractions for working with Flash. Things that I was used to.

Right. And could not really debuffle them. So after. Yeah, go ahead.

No, I was just gonna say, sounds like, you know, the programmer happiness angle that Matt took with Ruby, you know, it spoils you when you get used to it. I know I'm spoiled in many ways by it and I look for those features everywhere else I go and I judge other languages in terms of semantics and syntax with regard to how I can express myself. It sounds like you're hitting that same thing where like everything you saw about Erlang, the foundations, the distribution model, all these things were great and you loved it, but there was just missing pieces that you just didn't feel like you could live without because if you live without, you could just kept writing more Erlang, right? You decided, no, I'm going to actually start something new that's going to be kind of melding these two worlds.

Is that fair to say? Yes, that was kind of the. It was an idea at the time, but it's what it came to be. So at the beginning, like I said, the first commitment was January 2011.

And so I knew what I was missing but I was not sure what I wanted, if that makes sense. So for example, I was like, oh, I want better support for collections or I wanted a way to do polymorphism. So the first, if you go like to the early chromatographics, the early history, it was actually an example language, it had a prototype based model. But everything learning vertical machine is immutable.

So I was trying those things. So I know I had a problem, I wanted to solve it, but the answers I had at the time, they were very Ruby centric, let's say. So it was more guided bias towards object orientation and however Ruby was solving those particular problems. So for the map programming it was still, it was a metadata similar to Ruby where you know when you need to do fester things in between classif strings and things like that.

So I knew I had like those problems and I was trying to solve them. And then I played with it for three years and the N word was really bad because you know, I was like, I know I had those problems, those are the solutions I know. And they didn't map really, really well. Right in the sense that the things I was trying to bring doesn't mean to fit in this new ecosystem, this new way of doing things.

So I stopped working on Elixir at the time and I said, okay, I know those are the problems and I know that some of the solutions I'm looking right now, they are not going to fit. So I need to, I need to study more, I need to see how other languages they are solving those problems and how they can fit into this new, into this virtual machine. And so that's why, that's when I started saying, okay, so I want, I don't want like Ruby in Erlang, I actually want, you know, I want to solve those particular problems. And if I need to take some ideas from Ruby, I'll take my ideas from Ruby.

But if the best ideas they are from Python that will fit here, they're going to be from Python, there would be from Haskell or there would be from Closure and so on and yeah, go ahead. I was just gonna say it's very interesting. It kind of reminds me of what Jeremy Ashkinis did, you know, with Coffee Script back in the day, which was, I'm not just going to do a nicer syntax by Ruby version of JavaScript, I'm actually gonna pull in what he considered and what the community considered best ideas from all these different camps specifically. But that Python +Ruby was major influencers.

So I mean that's definitely a winning strategy. It's like, let's just not take Ruby ideas and move it over here to Erlang world. Let's actually come up with the best thing we can and for each given circumstance. But that seems like a really big green field and there's so many decisions to make.

Was it daunting? Were you intimidated by this task that you had just taken on? That's a great question because I think a lot about it. And one of the things that makes it really easy is that, you know, if we're building software, if you're building language stock of the only virtual machine, there are a bunch of decisions that they to be taken from you.

Okay, so that narrows a lot the scope of what you can do, which is, you know, it helps keep you sane. Right. Otherwise it would be too much. I already feel like, you know, being a engineer, being a software developer, I want to build the best software I can possibly build.

Right. And sometimes I have like those things that, you know, I see something different, I see something new and ask should Elixir be using that instead? Right. How could, you know, how would that affect the language if I had made this other decision?

And those things can be quite consuming because also if the answer was yes, life was much easier because okay, I know how to make this better. But the answer is not yes, it's maybe you need to consider how detracts with the other, you know, all those other things that you have in an image. Right. I feel like it's like a Django game.

You need to have like the pieces well together and sometimes you can, you know, take a piece out and put a barrel in place. But you know, maybe you do that and you're going to put your beauty on top until you find out that oops, that piece was a bad piece. So yeah, so I, I get it a lot and I say joking that it's something I would never do again, creating an up programming language because of all those questions that you can have, it's just such a wild scope and you, you cannot really, you know, choose how like this other person better than the other. But the other combination helped a lot.

So I could get a lot of concerns, a lot of things like, okay, even if this is cool, I know I can have it here. So. And that's fine, right? That's life.

And I also, when I decided so after I studied and I. I decided to give Elixir another try, I had a better foundation. What I wanted to say, for example, okay, if I'm building for the Erlin virtual machine, what I want to do is to leverage this virtual machine as efficiently as I can. So I made a decision to, you know, I want to stay.

So when you're compiling a code had like many compiler steps, and I decided to target a compiler step that was semantically very close to Erlink, and that would give me. That would add even more constraints, right, to language development. So that helped a lot. I also had already made decisions of what I wanted the syntax to be and that I wanted to have a macro system based on AST and so on.

So all those things that were like initial decisions like this variable to be on top of helped make it a little bit less daunting. So you just go into a. Into a cave for two or three years and write code or. I mean, you obviously were taking influence from other places.

Were there any books? Was there any influence? Was like, I'm right, programming language sounds like you have at least a second start there, which is always nice to throw away those first efforts and spread over when you get a little bit of solid foundation. But we'll have process light from May, not until 1.0, but here's a new guide post.

So in 2013, there's a post by Joe Armstrong, who I'm sure you know, but to the audience, he's one of the designers of Erlang and he published a post about Elixir, I think it's called One Week with Elixir, in which he said, and I quote, this is good shit. So I think that's a milestone. That feels like a milestone to me. From conception in 2010 and a false start to a certain degree, or restart in 2011-2013.

One of the inventions of Erling is impressed with what you've done here. Can. Can you walk us through that time period and the process you went through to create it? Sure.

So at the beginning of 2011 was when I made a prototype. It sucked and I threw it away. And then it was the end of 2011, the end of 2011, beginning of 2012, where I had like, I built a Conceptual model that I said, okay, I think this can work. And this was also the period where I went to Platform Attack and said, okay, I think we can build this thing and I think it can be useful.

Because at the time we were looking at, what I said was something like, you know, concurrency becoming that thing, just that concurrency become more important. And today, if you want to use a language that, for better or worse is it's a dynamic language and it focuses on concurrency and it focuses on productivity and being expressive. The option we had at the time, the main one, was closure, right? So, you know, if you get something like you have Ruby and Python, but they are still not conqueror as other languages, right?

You have Go that has a static type system. They are not very focused on being expressive as a developer, right? So it's like the only image that has everything that I could think of as using at the time was Closure. And I said, you know, we need to have more options, right?

And it would be really nice to have an option that runs on the alien vertical machine. And that was January 2012. And it was when the company made the commitment to, okay, we're going to like to invest part time, you know, half of our time into developing this. So that helped a lot, right?

Because it was not me being, you know, cold at night or something like that. It was part of my job for that moment. And so I had this idea of what I wanted the links to be. So as I said, I wanted to be closer to Erlang and I knew I wanted the macrosystem I knew I wanted for polymorphism, for example.

I had completely ditched the idea of objects at this point. I adapted something that's very close to closure protocols and similar, a little bit like classes in Haskell and a little bit retfing goes have the same idea. So that was like, okay, this is what I want to build. And then I started working on it.

And I don't remember how much time it took me, maybe six months to have something like, hey, I kind of feel comfortable now for releasing Elixir, what I would say like 0.5, which is what people use when they say, like, okay, this is probably usable up to some extent. And I also made the plan, I think it was even at the beginning of the year to speak at Strangeloop. They had at the time, an emerging strike. And I went there, I was able to speak about Elixir.

It's probably one of my first public talks about Elixir. And at that moment, some people already started to find it So I always had access to a good part of the community. Like, a lot of people follow me on Twitter and stuff like that. So I was always talking a little bit about it.

And some people decided to try it out and they decided to explore the language and some people started contributing back. So we see a little bit of a community forming and important contributions to the language. They came about that time. So, for example, one of my favorite features we have today is the idea of DOC tests.

So the here Doc syntax we have, like, if you want to do a very long text, right, we got it from Python. And then someone said, you know, Python has this Doc testing. Sorry, got rid of us. Look at the Doc task, which allows you to write documentation.

Oh, tasks. And it can guarantee that the documentation is up to date. Right? And that's something we got at the time.

It was a contribution. So the link was growing a little bit. You know, I was pouring my time. The community started to help it grow and help it move forward.

And it was. I think so. And then that was 2012, right? I was working on it, the company was investing it, but I was always a little bit uncertain, right?

Because, you know, like, I know the company was investing, but for how long are we going to actually invest in it? Like, if we spend two years working on this and nobody's using it, does it make sense? So I always had like, the feeling that, you know, maybe next year would be my final year working on this. And yeah, it was, but it was like, you know, if that happened, it'd be like, oh, the ride was fun, right?

Like, I learned a lot and people use it and Giant, so that was worthwhile. But it was in 2013 that we had like two very good news, you know, in a row, which was Dave Thomas. He sent me an email asking if he could publish a book about Elixir. And a little bit actually before that, also Simon, seth Laurent from O'Reilly, he wrote introducing early and he said, I want to make this.

Introducing Elixir 2, which is probably the first Elixir book announced. I don't remember which of the student became. And it was just fantastic, right? Because now, like, there are other people, you know, actively investing on the language as well.

Right. And, you know, like, if one thing I had in my mind is that I didn't want to write a book on Elixir, I felt like, well, maybe this is something that's. It's probably necessary in the long run, but I don't want it to be me. But if nobody does that, I would probably do it, let's say.

And you know, and then Dave Thomas come and say, hey, let's write the book. Like, that's great, right? Like Steve Thomas, he wants to write the book. So that was very exciting.

And that was. Yes. And that was what led Thomas, that led Joe to do that. Because Joe, he got to know that Dave Thomas was writing a book on the thing.

I was like, okay, I need to try this. And we started growing more and more from that, from that moment on. So surely you read Joe's post and you saw the quote, you saw his take on it. Can you recall your thoughts and feelings with regard to Elixir when you see one of the designs of Erlang saying, it's good.

Oh, it was, it was really great. I don't remember exactly, but Joe and Joe and Robert are both crazy around here. We always are open. We could always have conversations.

Also the OTP team at Arsenal, at Montes, Erling, they're always, they're always are open. So I remember when I first announced Elixir, the tagline was Elixir a modern approach to the alien virtual machine. And it was a horrible tagline, but the modern word, like, made some people mad. And I remember getting mail from someone that, you know, at Ericsson saying, you know, like, it's fine, you know, ignore that, just continue, just continue doing stuff.

Right. So that was very encouraging and getting Joe's feedback and later Robert feedback and so on, which was also very courageous to continue. It's doing the work. Right.

So I pointed it out here for the listening audience, just in case they didn't kind of hear what I think I heard, which was, here's you. And everyone sees just this really great software developer, especially well successful with Elixir and they see you. So what you just said basically was that you got a couple years into this and you thought it might not work out and then you sort of hit this stride where I'm sure one of your heroes, Dave Thomas, who wrote the Ruby programming book, which is the most bought RWBY book ever, I'm sure. So here's one of your heroes.

Bless basically what you're doing and then want to write a book about it, like how that all worked out to me is just like a really triumphant moment for you. Yes, yes. It was like it gave you a lot of confidence, right. To continue moving forward.

You're going right away. Yes. It takes the, you know, the uncertainty, which helps a lot. Right.

Remove the uncertainty that I may not be working on this next long. Right. So that was really nice. And you know, the benefit of this is that I became closer to the town as well.

So when we had the first NC conference, it was in Austin and my flight was from Dallas, where he leaves. So we took a car ride. We're able to talk a lot there. Sometimes I'm like wondering things.

Now I have like the perk of being able to send like these thumbs and memes, like, hey, what do you think about this? Right? So those were very nice perks that came as a consequence of the book as well. I want to tease them up here.

Jose, before we head to this break, I'd like to hear from you what some of the overarching features of Elixir are. When we come back from the break, we'll dive a little deeper into some of them if we can. But do us a favor, share kind of an overarching feature set for Elixir. Okay.

Yeah, so that's really hard. So the main thing is that you're going to use it to build maintainable and scalable applications. But Elixir is also an expressive language. So we want to, you know, allow the thing like developers that can get the language actually not to say expressive, it can be express as well, but accessible.

They can get the language that's always on the idea to be able to get it and extend it to whatever domain you're working on and the focus on productivity as well. So we have our goodies. So that's like the macro overview of what you can build with the language and then features. There are so many, but I think like the tooling is really fantastic.

I like features like focus on documentation and what else? I like our way we can do polymorphism, which is a language specific trait in this case and so on. Yeah, I'm not sure if I. But yeah, that's what we're looking for.

We're getting ready to go into this break so we want to kind of get a breakdown to leave the listeners hanging, so to speak. A little cliffhanger, so to speak, on what Elixir is built upon. I think the plain language in which you put in wasn't like, here's the feature list of Elixir. It's more like, you know, from your, from your mouth, so in your own words.

So it wasn't like this scripted list. Cool. You got anything to add before the break? No, that's good.

I've been writing those down and we have a list of things we can definitely use as jumping off points to talk about on the other side. Cool. Let's take that break. We'll be right back.

Our friends Linode are huge fans of the show and many developers that work at Linode listen to the show. They're huge fans that we're handling the support we're doing. And we will invite you to try out Linode, one of the most fastest efficient SST cloud servers on the market. Use our code changelog20 to get 20 in credit.

Basically two free months plan started, just 10 bucks a month. They have eight data centers spread across the entire world, North America, Europe, Asia, Pacific. You got hourly billing with a monthly cap on all plans and add on services. You get full root access.

For more control, run VMs, run containers, or even your own private git server. You can enjoy a native SSD storage, 4 gigabit network, Intel E5 processors. Again, use the code changelog20 to get a $20 credit with unlimited uses. Tell your friends it doesn't expire until the end of this year, so use it as many times you want.

Share it to everyone you know. Head to the note.com changeloft to get started. All right, we're back from the break and we got this feature list and we're looking at it and one of them stands out more than the others. And it's maintainable and scalable applications.

How do we qualify that? What exactly does that mean? How do we break that down? Jose?

So that's a very good point. I, you know, I, I don't like to say, oh, what is the future like, better matching. Because unless you use the push operating language, you don't know what it is. So I started with like the, with things like know is the focus and the focus and notability and scal.

And one of the things about maintainability, in my experience of like this so far and why I think it's a maintainable language is all behind the idea of processes we were talking about. Right. So for maintaining. If you're thinking about maintaining application, there are two aspects of it.

It's like it's running production and you know, part of maintaining it is to ensure it actually runs properly in production. So if you never. I know you're already playing with Elixir, but if you've never used it before, we have a tool called observer that you can install your node or connect to a node in. Run this tool, it can show the whole tree of our system.

So Elixir applications. So sorry, your Elixir software elixir system is built into a bunch of tiny applications and you can go one by one and introspect those processes, those lightweight threads talking about earlier. So you have really a great amount of introspection of how your system works. And this matters a lot to, you know, to ensure the software is running properly in production, which is not that fast.

Just to give an idea of how this is. So one of the things that we did with Phoenix and the whole channels idea and Web Socket's idea is to make sure we got a very powerful machine for Rackspace. And we wanted to. We were able to have 2 million connections on the same machine.

So we had like 2 million clients that have the same machine connects to phenos and we broadcast for example, a wikpd article to those 2 million clients in like 2 per seconds. Right? And in order to make it go that fast, we had to improve it. So what we did is that we connected the clients and then when we, for example, at the first fire, what 300,000 clients, where we reached our first bottleneck, or even 30,000, I remember exactly what we did.

And we connected the server and because it gives you this whole idea of the system, right? We could say. And because all the code running to processes like right tries and computation, when things started going slow, we went to a pane and said, wait, which process is the one that is slow? The one that's doing a lot of work, because that's the one that's going to be my bottleneck.

And they say, oh, that's the one that's being slow. Let's optimize it. And then we optimize. We moved the bottleneck elsewhere and we did this a couple times.

And I think over the period of two days we were able to go like two minute connections just by relying on this tool. And this we use as an optimization job, which is also part of maintainability, right? If things are slow, you need to go and try to understand your system and try to make things fast. So that's one side that we have to eat.

The other aspect that we have augmented is also related to code. So we were talking about this during the break. So for example, I think the whole idea regarding immutability helps a lot with that and the whole idea of functional gaming. So okay, let me just do an statement and everything to explore it.

I think a lot of the reason why Pixel Software table is because of ideas that we have that come for functional programming and functional programming. If you ask someone like what is functional programming? You're going to have to get a bunch of different answers. So one of the things that usually associated with functional programming is the whole idea of readability.

And I'm going to expand this soon. But to me, the big thing about Fuchsia programming is that it pushes parts, it tries to make the complex parts of your system explicit. And that's why it's so helpful. So, for example, mutation, right?

Like changing things in place. It's a source of complexity because Rich Hickey has great topic, great talks on the topic, right? Because now you need to think of how that thing is changing over time. And if you remove the mutability aspect, right?

If you make things immutable by default, you remove that whole time question of understanding your system, right? So mutability is a source of complexity. So it needs to be more explicit. It can't be the default.

It can't be something that you do automatically. And what. And for example, another way this shows that people should program if you're using more strict languages like Haskell, is the whole idea that any side effect that you have in your system, or if your system's changing the world around you, like talking to the database or so on, in Haskell it explicit and use a monad. But here we'll have monads, right?

But we go with this idea. If you want to do something that's changed the world around you, we want you to be explicit and put it somewhere more explicit in your code. And we want to put it apart from the code that does not change the world around you. And what's going to happen the other day you're like writing functions that receive data and transform this data instead of obtaining it.

Which means like every time you call function the same input, we already get the same output. It's easier to understand what is happening with it. They state that it proceeds. It's always explicit.

There's nothing happening behind the scenes. One example to try, the people seem to try to visualize that. And for example, like when you're writing tasks for jumping into. Sometimes we always have to write a test or we have to set up a bunch of or mocks or relationships, or set up the state you need to get to before you can write the test, right?

And that's because it has a bunch of states, a bunch of things related to it that it can take that it depend on implicitly, right? Right. It's like inside the object. But here you don't have that, right?

You have functions and everything. There is an object state that is a calling something, right? Everything that you receive is explicit and you need to return everything explicit as well. And I think that makes one or two make your function more maintainable.

Because I can look at it and say, hey, I see what this is doing. Because I can look at a function and see everything it needs to work on. There are no inner state right there or a bunch of relationships that can change and affect the whole system. So those are some of the points for maintainability.

I'll just expand on that and maybe bring a specific point. When it comes to functional programming, one thing that you often find is you have this, like you said, you're just transforming data, right? So you pass the data this function, then this function, then this function, and they all change it some way. We turn a new thing that's a mutation of that previous form.

And so you end up oftentimes passing around the same, like I call treasury just a bag of data and doing things to it. And so my question is always like, why don't you just make that bag of data smarter? And then it's an object that now has its own internal things going on and you can back to object oriented programming. One thing that Elizabeth does, which I think is really cool when it comes to like passing that same thing into as the first argument to all these different functions that are going to mutate it is you've introduced a way of just alleviating that little syntax pane which is your pipeline operator, which is kind of like the pipe symbol and the gradient symbol.

Can you explain us? I think that's one of the language features. I think that's a big one. And maybe it's just syntax sugar, maybe not.

But can you talk about the pipeline operator and what it does and why it seems to resonate so well with so many programmers. Right? So the whole idea of the pipeline operator is exactly to help you and to express like the whole, like, I have the data and I wanted to go through this step, this step, this step, like the pipe in your terminal, right? And I added it, I think it was.

I added it because I saw it in F or ML or something like that. But who really took it, like to the next level was Dave Thomas. So if you buy like the pipe line parade is right there in the COVID And he was the one who saw like, hey, this is the thing that's going to make actually click to a lot of people, right? And.

But yeah, the idea is very simple and Elixir kind of said, okay, the subject is always going to be the first argument, which makes everything easier to pipe. And yeah, and that's it. And I agree with you that it kind of gives it the idea well, this is kind of right because I could think of I had like this bag of data and I could be calling functions and the pipeline is going to resemble that. And that's why I think it resonates a lot with a lot of people.

But there's one very important difference, which is if you have like if we made it objects and the thing about objects is that you are putting the data with the things that actually together, right? Data plot code, right? Yes. And one of the things that ended up with realized I ended up realizing later is that it brings a bunch of awkwardness into our software and then it kind of becomes a problem and we end up trying to solve it and ends up creating more problems with recurrent languages.

I hope that I do not sound like a what is these knob saying those things? I don't think so. Yeah, just like things that I built with time those perceptions. Because for example, after you put those things together right, you say okay, now if I want to add something new that works on this data, I want to couple it together as well.

So then I have like your object that has a couple of methods that work on the same just couple them and then you have an idea for a new method that you want to add to it. If you call it differently as different from the other methods. If you want to say object but you can't say object. My new method, it's awkward, right?

So we want to put it in there with the rest of the things. And for example, Java does not allow you to do it after defining can't extend it. And then people are like oh, landing subclass and so and so on. And Ruby is much more flexible on these methods that we can extend things later.

But it generates all kind of weird coupling now, right? Because I have now external code that may be monkey patching an existing class and that has issues. And that's all because we tried to couple those two things in the first place, right? In Elixir it doesn't.

We don't when we're using the pipeline there isn't this coordinates because we are saying have my data and I'm going to call the function bar from the module foo. And if you want to add your own module with your own functions, you just call it next to the pipeline, right? I'm going to call my newfound my new function in this other module, right? It's natural because that's how we're calling everything.

And you can swap easily, you know, change things, you can compose, can replace function calls and you never feel that need to couple it together with the data, which to me it's the big win, right? It also has the big win that, for example, if you have an object to say object foo. Where is that fully find? For example, in Ruby you can find things everywhere.

It's really hard, right? And you can even it's defined somewhere, but some other file kind of replaced it by something else. But here you have modules and after the logical pile, it's done. It's a sealed deal.

And I know it's in that place and if I'm going to look at there, it's going to be there for sure. It's going to move somewhere else under my feet. So I think those things, they matter a lot and it's going to help us write more maintainable code. Let's talk about another aspect which you bring up around productivity and you say it's because the tooling is good.

And recently we've had a lot of fans of ELM talking to us, especially after our show recently with Richard Feldman. One thing he said on that show, which was that the most exciting thing about ELM to him, which again, that's the best functional programming in the browser, as their pitch is that the compiler itself is a huge benefit of using elm. And I'm not sure it was him or somebody else who said this idea of a few main compilers where they're like there to help you and to be useful and not just like Segfault or destroy syntax error, not giving you any information about what's going on is huge for productivity. And that's something that Elixir seems to support.

As I said, I've been doing a little bit of Elixir and I'll find sometimes it tells me not just what went wrong, but like, gives me a code snippet. I'm like, if you just replace your code with this code, everything would be all right. That seems like a pretty big feature. Was that a focus for the language early on?

And can you talk about why that's such an important aspect of why Elixir is the way it is? Yeah, that's a great question. So I always said, like, if you see a bad error message in Elixir, you should open up a bug report. Like, if you get an error and say like, I don't know how to fix this, I don't know what is the next step and what is wrong with my code.

Open up a bug report and always try to make it better. And I don't think our compiler is as Good as the ELMS compiler in terms of like telling you what is next. Evan did really a great job with Elmo and having a static type system in that case helps a lot to provide the proper information. But it's something that we really try to do, right?

Like, hey, I don't want to make a clueless right, something's wrong. I'm going to try to tell you as much as possible why that happened. And it was there since the beginning. Because what happens is that I want people to use Elixir, right?

And if they're using Elixir, they need to learn a lot of things, right? They need to learn about parameter matching as we're talking about, you know, immutability. You no longer have objects and things are immutable, so you need to think in terms of immutability. There's recursion, there are a lot of things that you need to learn, right?

So those small things that can get in your way, the silly thing, right, they're not the important ones, like when I do a typo and do a small mistake, we need to get them out of our way. Or if they happen, I need to tell you how to solve this problem, how to think the proper way. So that's the reasoning for this. And it was kind of always there.

It was something that we always worried to let's make this learning process easy so we can focus on the things that matter and not on those small details, on those hiccups that everyone have when they are learning how to program a new language. I don't remember who said this, but they said that their first Elixir code, they would just type whatever they think, what it should be, and then the compiler would tell them, hey, that's not the proper thing, and they would fix it. And they got it working only with those steps. And he didn't have to search on the Internet, go on stack overflow, because the compiler, every time he did something that was not like the.

The VL is supposed to be done for the guides came towards, which is really nice. Yeah, absolutely. Getting stuck on those little things is always a burden. It can really turn you off to language when you just can't get it to work, you know.

So having it hold your head as much as possible is huge. I think another aspect of features, a huge feature in any language is the community, the ecosystem around it. We've been mentioning offhand Phoenix, which is the web framework. There's also Ecto, which is a database layer, and other projects that aren't Elixir Proper, but there are things that you appear to be personally invested in with regards to time and effort and decision making and stuff.

When we had Chris Cordon back in episode 147, I asked him kind of, I asked him about you and I was kind of wondering aloud and I said, I wonder if the reason why you've been so highly involved specifically in Phoenix at that time is because you see it as a chance to give Elixir a greater success. So if it has a killer web framework, you know, Rails put Ruby on the map in America at least, and made it something that was more mainstream. And so maybe if Elixir had a Rails esque type of a project, or let's just say a really viable web framework that people could build web apps with that would increase the chance of success of language. I asked Chris if that's why you did it, and he said, well, I can't really answer that.

I can't tell you why Jose does what he does, but you might ask him sometimes. So I say all that to say this, Here we are, I can finally ask you, you've been highly invested in this web framework and in these web tools and I just wondered the reasoning behind that and if I was right on in the sense of you see this as a path of giving Elixir's greatest chance for success, right? So I try to not mutilate whatever I'm doing with the chance of success, you know, like directly I obviously want to succeed, right? But I try not to do things like directly because of that, right?

So for example, for the web in particular case, I said at the beginning, Web platform attack, right, that we are consultancy and then we're working projects and most of our projects were web projects. So back in 2012 when I asked them to fund, the idea was that eventually we would have ix0 and eventually would have the good webull so we can use it ourselves, the company could use it and can start using Elixir in production and use of our clients, which is one of our goals. So that was pretty much the idea. So when I was working with Elixir, I had like, I don't want this to be a web centric language.

So I'm not putting like physics only for the web here. That's not what I want. But after we got Elixir out of the way, I said, okay, step two, right? Like this is the second lesson, which is to focus on webpool.

And that's why I started to work more with Phoenix and work more with Vector and, and so on and other than that, for example, before this one came out, I kind of built my own web framework that was supposed to be used for anything. But just to give you an idea like how what a language was and what could I do with it and what could be improved. So that's something that happened. But I always try to keep this of type stuff apart.

It was never the focus. So the main reason was really, you know, if you want to use this platform that we want to use this with clients, we need to have a very good web story. And that was actually the goal for last year. And I'm like.

And we, I think we achieved it with a lot of success because Phoenix Uno came out and it's not me. Right. Like the nice thing about things is that I didn't have to solve that problem. Chris did.

Like most of the work I'm just helping and this is great. And then I think we're able to get really far with Phoenix Window last time. When it comes time to grow, we can see more and more companies using Phoenix. And now in the last step I'm working on Act 2 right now that's going to improve based on some of the feedback.

I'm also working with Chris and Bruce State on the programming Phoenix book which is also going to help with all those things. Right. But the main question was exactly, you know, it's just something that we need to use and that's what I want to focus on. And yes, I kind of knew that if we had that it's going to, it's going to help of adoption because when you have just a language, you don't have, let's say a tool to use it with.

This was actually very interesting because when things start to become more popular it started to attract different, let's say kind of developers that were they aimed on different things because they're learning only the language of school. I want to learn the language, they want to master it. And when it comes to Phoenix I will start to see more developers are like, hey, I want to build something. And of course learning the language is part of the process of building something, but it's not my goal on its own.

Right. Per se, which is completely fine, but it's just interesting how the dynamics change. So yeah, so that's kind of the reason I think I maybe possibly answered your question. No, you did.

I found it someone interested in you. You don't necessarily like to think about it in terms of what you do directly leading or increasing the chances of Elixir's success. I would expect it to be the exact opposite. Like you would.

You want all your efforts to specifically try to advance the chance of elicit success. Maybe it's just not that deliberate. But that led me to this thought, is what does success look like? I'll tee this up.