Elixir Wizards S10E01: The Next Ten Years of Elixir
Sundi: Welcome to another episode of Elixir Wizards, a podcast brought to you by SmartLogic, a custom web and mobile development shop.
Bilal: This is Season 10, where we are looking to the next ten years of Elixir!
Owen: WeÕll be talking with our guests about what the first ten years might tell us about the future of Elixir.
Sundi: Hey, everyone. I'm Sundi Myint, engineering manager at SmartLogic.
Owen: And I'm Owen Bickford, senior developer at SmartLogic.
Dan: And I'm Dan Ivovich, director of Engineering at SmartLogic.
Sundi: Welcome everyone to season 10. I cannot believe we're at 10 years of Elixir. A little bit past the 10-year anniversary mark as of recording this, but we're also at 10 seasons of this podcast now. What's the 10-year anniversary medal? Is it bronze? Maybe?
Owen: Mmmm.
Sundi: Nobody knows this.
Owen: I can't recall. Google! Save us!
Sundi: In any case, we're celebrating the Big 10 today. So, we're looking towards the past, looking this season at the past 10 years of Elixir. Learning from our history and figuring out what do we hope to see from the future of Elixir? The next 10 years? What is the next 10 years gonna bring us? And that is something I'm really excited to delve into today with our hosts, but also in the future of this season with our wonderful guests that we're gonna have on. So why don't we go ahead and just dive on in. I did think it might be interesting to first talk about what were our first impressions of Elixir overall? We've all had different experience in the last 10 years. Dan, maybe we can kick off with you.
Dan: Yeah. Anyone who's a 10 season, all in on our podcast has probably heard me say these things before, but, you know, the pipe syntax, pattern matching, and then changesets. I saw those things and I was just like, okay, I'm done. Forget it. Like everything else. Don't wanna bother with it anymore. You know, and I say that a little in jest, right? I still really enjoy writing Ruby. If I need a quick script for something, I'm probably still gonna write it in Ruby. I think even if I stopped writing Ruby for years, I'd probably still go back to it for that kind of task. but, for web application, functional pattern matching and, the repo pattern with changesets over, callback soup, to put it nicely, that we've experienced in other platforms, other frameworks. So yeah, my first impressions, hey, this feels like Ruby. Oh, I gotta figure out what being not object oriented means. Oh, okay, great. I get it. Now I'm all in. I think it's probably a pretty common path for a lot of people. Maybe not anymore, but certainly 10 years ago or, well, I haven't been doing it quite 10 years, but, you know, early on, that was a very common path for a lot of people, and I think my experience mirrors that.
Owen: Do you remember where, or how you heard about Elixir for the first time?
Dan: Coworkers. We had a very small project that we were, you know, felt like it was a good fit to try out Phoenix and Elixir with. We'd had several employees who were interested in the language, had been kind of following its development, as it was, you know, I, I'd say pretty well advertised in the Ruby space. We gave it a shot and that project was extremely successful on time, on budget, and then just ran rock solidly for years until the product was no longer necessary. And we figured, you know, financially as a company, the risk was pretty minimal. If, if a two-week project failed and we had to redo it in two weeks in Ruby, you know, that really wasn't a whole lot of risk compared to, you know, our typical three-plus month-long project.
Owen: No regerts!
Sundi: Owen, you had a, a different kind of story, like when you found it, you were working, were you already an engineer at that point or were you still teaching yourself?
Owen: I was yeah, I was still learning. So, I was working customer service back in the day at telecom, so big enterprise stuff and, helping people get their TVs on the right inputs and that kind of thing. Plugging in fax machines. But anyway, so, I had already started learning JavaScript. And, just in the nutshell, like, because I was seeing a lot of recommendations about React, and those React either talks or tutorials would always talk about functional programming. I started trying to understand that and some of like, some of those concepts. And as a result, this was around the time that Elixir was starting to pick up steam, I think like 2014-15 which I guess is almost eight, seven, or eight years ago now. So that's wild.
Sundi: I do think about 2015 as just a few years ago, but we keep getting closer to 2015 being about 10 years ago.
Owen: Yep. And now we're all feeling old.
Sundi: Yep.
Owen: So, yeah, long before I understood any of it, I was starting to hear about it, and yeah. So kind of like, when you're really, really new to engineering, it's easy to kinda like see a bunch of shiny objects and try to like learn them all at once. I realized pretty quickly that that was not gonna like get me very far. So, I kinda like set Elixir to the side for a while and focused on JavaScript and SQL, which has actually paid off really well. Having that as a foundation has been great. And then kind of dipped into PHP, but then kind of started coming back to Elixir. And I think in the summer of 2020, was when I finally, I'd had the book on my shelf for a while, but I finally read Elixir in Action, the second edition, for the first time. It kind of took a lot of discipline for me to like, focus for that long. But, it came out with a lot of, a lot of great knowledge from that book.
Sundi: It's so interesting to hear these different perspectives because I was also in a very different place because I was mid-career, had done a lot of JavaScript and React, and was just starting to understand it. I think React at that point was changing every year. Is it still changing every year? I haven't kept up with it. Um, and you know, I started at a job that was using Elixir and so I was using Elixir. You know, I think that that was just normal in my brain. Okay. I'm starting a new job. They use a language I don't know. I'm just gonna get there, and I'm gonna learn it. And I didn't expect to like it or dislike it. That's not how I really thought about programming languages. And I think my first impression was, I don't know if it was pattern matching or when I wasn't writing. Yeah, I think it was pattern matching, where you can just write several functions with the same, like the way I, I was reading it was like I was reading a function written 10 times. And it was pattern matching on the input, like the intake. And I was like, oh, is this kind of like Props, but inside the parameters, you're matching, and then you output?
But then I was like, but why would you wanna write this function 10 times? But then I started debugging and I realized that rather than being in an if statement that had 10 different kinds of, or like, a case statement or something, that had 10 different options. to be able to just like know which line of code.
Okay, so that case, that particular, when we get that parameter that means, or that argument comes in, that means that's the issue. And that was when I started thinking, oh, that feels more intuitive to me, actually. And then there were some other things where I started getting to learn more about the language and it felt a little bit more readable.
Like I was reading English, like reading a sentence than JavaScript or any React programming language ever felt like for me. So, that was my impression. I always used to say: "Elixir feels very English readable or human readable." So, that was my first impression. All different impressions here.
Owen: Right.
Sundi: What are we hoping to hear about from our guests this season?
Owen: Everything! It seems like Elixir is kind of, it's not the most popular language still.
Sundi: Mm-hmm.
Owen: But it does seem like any of the areas that it would've been a bad fit for, that is shrinking like every year. Like there's, there's a lot of work happening. It's been rock solid, you know, as a web stack for years, thanks to Phoenix especially, but, we're seeing it, move into, numerical and machine learning stuff. So with, Axon and a lot of work even in, in like Livebook, which is kind of like primarily a documentation thing, it's being used in some very interesting ways to kind of prototype and demonstrate how to do things with Elixir and Numerical Elixir, which are really cool.
Sundi: Yeah. I'm really curious what our guest opinions will be on what they want to see from Elixir in the future. Because, usually what people want to see from a language or something that they're working in a tool or a language, both, it's usually something that they run into, like a problem that they have had a harder time solving.And, so everyone's experiences are different. So, you can never really predict what people want. I know what I want, and I know what I've just faced that's making me want that thing. So, I'm really just super excited to talk to different guests, who have different experiences, maybe very little experience in Elixir or maybe ... the creator of the language, just saying, you know, to see what we might expect from the future or what we hope to see from the future. Dan, what about you?
Dan: Yeah, I think I just, I like hearing about problems being solved. Especially, you know, I like doing things in ways that, maybe are a little novel to the language or novel to web programming or novel to the problem space or things that would've taken, you know, a larger team, a larger. A bunch of specialized knowledge that are now more accessible. And I think that, you know, we've done a pretty good job on this podcast in particular of trying to find those people and ask them kind of, you know, where this is fitting in their work. Not necessarily just talk about like the news and what's new. And I think that's interesting and it's always good to hear, but, I like the practical application and so I'd like to continue to see that from our guests. What's the practical application of some of the latest developments in Elixir and this community?
Owen: Yeah, and I think best practices too, now that we're at 10 years, there's been a lot of change in how these applications are deployed. I think early on, probably a lot of people followed the pattern of microservices because that was the way for a while. And it seems like a lot of people have been burned or like, have, have kind of evolved on how they like to deploy apps. And I think that's, that's been fun to watch.
You know, there are differing opinions still about like where you put your code and how you organize things. And it doesn't always follow the way the generators do it. So, it'll be fun to hear like different ideas about how we deploy apps, how we structure them, and high-level thoughts like that.
Sundi: Yeah, I definitely know people who vehemently hate using the generators and then other people who swear by them. So, patterns in Elixir is definitely something that is almost like a, a trend or a fad, right. Comes and goes through the years. So that could be an interesting thing if that comes up.
Well, cool. I definitely am excited to talk to our guests about the season. I'm also curious what this team, like our teams at SmartLogic, but also this team of hosts, is interested in seeing in the future ourselves. So, Owen, maybe you could jump in.
Owen: More LiveView!
Sundi: Be more specific.
Owen: Yes. I've worked a lot on the side with LiveView. More lately on client projects have been working pretty strictly in the backend with database, doing a lot of Ecto stuff. So, I've gone pretty deep on that. Learned a lot of things and, you know, with different database models and everything.
So that's been fun to put it diplomatically. But yeah, I'm looking forward to one seven of version one seven of 1.7 of Phoenix is pretty great. There's a lot of good changes in there, and I'm happy with, I think we're getting a good balance of which batteries are included with that, including all the gizmos, you know, so we're getting just the things you would need in any app, and then you kind of have all these other features you can kind of opt into or just install as a hex package when you need to do something else. But, yeah, I'm excited to write more LiveView and, and think in LiveView terms.
Sundi: Dan, we were talking about this earlier today, how Owen has paved the way for our team at SmartLogic to help us use LiveView, but Owen is not currently working on any LiveView project.
Owen: Right!
Dan: I mean, sometimes that's how it goes.
Sundi: We'll get there. Owen.
Dan: I think what I latched onto what Owen was just saying though, is the, what's the starting point? Yeah. We, we've been talking about this today too. Like, what's our starting point when we say, okay, we're gonna spin up something new. Where do we start? Through the history of this podcast, my opposition to LiveView has been well documented. But I think one thing that maybe I didn't articulate is what does this then mean are the best practices for certain things? And I think that was a kind of an unclear picture at least until maybe 1.7, where now it is a little bit more clear. But I don't think, it does seem like to some extent, and maybe this is because I don't do a lot of our Phoenix new building, but you know, what is the starting point? What is included?
What can we exclude? What do we still have to pull in? One of my struggles with the latest version of Rails is, it comes with everything, and then it's like, but I don't want everything. Right? And then what I loved about Phoenix was it comes with like nothing, and you also barely have to add anything.
And then that's also kind of changed and it's grown and, you know, I don't know if we've like crossed a tipping point or, you know, kind of anything else there. I'm not suggesting that we have or haven't. But I think when we talk about best practices, when we talk to guests about how they're using these things, the new project, the Greenfield project doesn't get talked about a lot because I think for most companies, they're not doing that that often.
As a consultancy, as an agency, spinning up new things, we do that probably more often than most. But then I also think about long-term maintenance because we've got, you know, 10 years of Elixir where we've got Rails apps we've been supporting for 12 plus, and pulling those things forward through the framework revisions has gotten easier, but at times was very difficult. So, it's upgrade path concerns, it's new path, you know, new greenfield concerns. It's an area where some simple content, some simple videos or audio to listen to, to kind of help explain some of the caveats could be really helpful, and I hope we get to dig into some of that.
Sundi: I think I did see a YouTube video on upgrading to Phoenix 1.7 or Phoenix 1.6, when I was searching for something else.
Dan: Yeah, I think there was a podcast episode I listened to from one of our friends in the space a few weeks back. I think the episode was actually pretty old, about the upgrade path to 1.7. This was still back in some of the Alphas or early release candidate times. The long and short of it, I think this is something that the Elixir community does particularly well, is that it does just work. You may not take advantage of everything. You may get some deprecations, but nothing's ever actually been deprecated.
Things just continue to work, but there might be a better way of doing things, which I think is nice. But then it also, then you create a whole bunch of inconsistency if you, if you don't then take the time to move everything under the new paradigms. But, you know, I think we, we are now a mature enough community. We have enough, you know, years of, and revisions of things underneath us to say this is less trivial than it used to be. As a framework and as a language, it's certainly been easier than other places where I've had to do it.
Sundi: Yeah. I think what I've been facing recently, maybe as recent as of this morning, has beenÉ not exactly a lack of documentation, but a little bit of confusing documentation from the LiveView side. Not knocking anyone's documentation, but I think the style in which I would like to receive documentation is not there. One thing that makes me feel pretty good about that is like, I actually know what I want, and so I'd be happy to contribute it back kind of thing.
Owen: Absolutely.
Sundi: I don't think I read documentation in the way that the LiveView docs read to me, if that makes any sense. Owen, maybe you can articulate this better for me.
Owen: Well, yeah, there is a kind of interesting thing. LiveView is part of Phoenix officially now, and it's built into Phoenix whenever you use Phoenix 1.7 especially. But, the documentation is still two separate, you know, repos. The documentation for LiveView, because it's actually a Phoenix package that's installed with your Phoenix app. There's Phoenix Docs, but then there's Phoenix LiveView docs. I think whenever you're learning LiveView, and you're trying to understand which functions are LiveView functions and which functions are Phoenix functions, or which functions are plug functions, which are also in a separate repo there, just knowing like where to search the docs. Sometimes having two or three tabs open for each, you know, packageÉ
Sundi: Where none of the tabs tell you the answer?
Owen: Or that, yeah, so this is something we were talking about earlier where there's another kind of a thing where we kind of discovered that, you know, whenever you generate your Phoenix app, you get a lot of things out of the gate, like these core components. And those are documented in your app, but they're not, they don't show up in the Phoenix Docs. So, it would be kind of cool to see. I'm not sure how this would be documented, but it would be good to see at least some mention of where to find those in the Phoenix Docs.
Sundi: Some of this opinion of mine is actually kind of formulated from having just worked in Flutter. Flutter is very verbose, and by that, I mean my VS code is very talkative. I hover over anything, and it will tell me everything about that function. Everything it needed, everything it could possibly have functions, variables, everything. I felt a little bit in the dark when I moved back to an Elixir project, a new Phoenix 1.7 project. An example is I was looking up something today, and I was just looking for a very simple example of something, and I was trying to find -- I found it in the documentation, but it was like one line. It said, tÓhis is the thing you need and it takes this parameter and this parameter.Ó And I was like, but why would I want that over the other thing that looks like that? What does that look like in use? Like, give me a code example, what does that look like? And then just could it take a, this, could it take a that, you know, there were just things that, like questions I had about it that I couldn't find just Googling because maybe people did it very differently, drastically differently. Two years ago. And the last instance I found of it was in 2020.
Owen: That's true.
Sundi: So it's, it's a little fragmented. I think it could be cleaned up. I know that LiveView was changing a lot just up until maybe the last Elixir Conf in August. So I think what I would really love to see from the future of LiveView, I guess specifically, and maybe just like Phoenix is some documentation that reads a little better to somebody who's learning it, who's trying to understand what are the tools in my tool belt, and how can I use that?
Owen: Yeah, and I happen to know what you're talking about because we were talking about this literally an hour ago before we started recording. But, a couple things here. I fully expect this, this is a newer module that we're talking about in Phoenix, so I think that's part of why the docs on some of these functions are a little bit sparse.
But, the other piece of that is anytime I've found some docs that I think could be a little bit clearer. It could be like an extra sentence or even just a word or two that would clarify things. I've found that I can open a PR on Elixir, Broadway, Phoenix, Phoenix Live. And they really appreciate any contributions.
You know, those docs don't write themselves. So, I've tried to train myself to, anytime I'm confused about something, and I have a conversation or discover, I try to open a PR as quickly as possible so that I can clarify that for whoever else is dealing with the thing and then get back to working on the other stuff.
Sundi: Yeah. And I will say, this is like the first time in my life, I feel confident where that contribution, if I opened up that PR today, would actually be helpful because I, I went through it, I looked, I couldn't find another example of it anywhere, I spaghetti-ed at the wall kind of situation until I got the one that worked, and then it worked. And so, I feel good about a contribution there, cuz usually when somebody's like, "oh, you could just contribute to Phoenix Core," and I'm like, "okay..."
Owen: Yeah. Docs are great for contribution and you'll usually get a pretty quick response and if you, if you've kind of thought through everything and it's clear and easy for them to approve, you'll see, you'll see the five multicolor hearts from Jose and
Sundi: mm-hmm
Owen: that will make your day! And yeah, that's, that's a good feeling. So, and I'm sure they feel great whenever people are enhancing the docs as well.
Sundi: Dan, you looked like you had a thought there like a minute back.
Dan: I think a lot about documentation, right. I've been at SmartLogic a long time. I've been doing this a long time. My role has changed a lot over the years. My own ability to recall things has changed a lot as I've gotten older. And that the sands of time have fallen through the hourglass or what have you. I think something that is always important is like, who's the audience of what you're writing this for? And the reality is, wonderfully our audience is growing within this space as the community gets larger. And I think Owen's point is, is super valid of, what was written for someone else, may not be interpreted by somebody else, in the exact same way. And if we can add some additional cases, some additional examples, some additional context to documentation that's certainly a big help. Harkening back a little bit to the top of the podcast, right? Things that impressed me about Elixir early on was the documentation. The documentation as kind of like a first class in the language doc generation, module docs, using packages like Credo to enforce that you're putting in that kind of documentation. And then something that I've been discussing a lot with our staff engineering team is the importance of documenting why we're making changes in commit messages and in the tickets and referencing those tickets in the commit messages so that when we have to revisit things in the future, we kind of can help pull all that context together. And Sundi, I think a lot of what I'm hearing of what you're saying is like, okay, this is the function and these are the parameters and this is what it does, but you're missing context over why I would use this over something else.
Sundi: It was the why and like the actual, what in the heck does it really look like when you use it? I guess that's a little bit of, give me the answer, but not really when it's just like, is it a double quote? Is it the, the bracket with the percent? Is it the curly bracket? You have different options when you're working with a LiveView file in the HEEx. You have a lot of different options when you're trying to get into something there and it's changed a lot. Like in the last even five years, you're talking about the past of Elixir, it's changed a lot. So to know which way, which direction it looks like is, is helpful. Cause I tried four different ways.
Owen: Yeah, I've gotta brush up my knowledge on forms. Because I think form the way you build forms has changed a little bit, even over the release candidates from the, over the past few months with 1.7, I think it's supposed to be getting easier. From what I hear like they're optimizing, like how much data gets sent back to the server whenever there's a change.
So that's actually really good news if that's true. I'm kind of, I'm not sure how to put this, I'm not excited. Anytime there's like a economic downturn, if you think of some of your... curve ball... Look at Sundi's face. So, curve ball.. Yeah. If you think of some of the biggest companies that we all know and interact with today, like they came out of the 2005 to 2008, 2010 kind of time range.
We're kind of entering a phase where there is a bit of a downturn, and maybe even in the engineering world, a lot of folks are kind of learning that we're kind of going from like unlimited resources to constrained resources. Elixir and Phoenix operate very well on minimal resources, I wouldn't be surprised if we start to see some very cool stuff happening in Phoenix and Elixir and like, just the way that they're being used to build some new startups or technologies over the next few years.
Sundi: That is actually incredibly interesting to think about because I, yeah, we are, you know, truthfully seeing downsizing of teams across the board. We're recording Q1 2023. Wow. I really had to like check my date there. And we do see that we, we've always heard that Elixir has helped teams run leaner, which is interesting to think about.
I've thought about this on previous podcast episodes where we talked about, I think it was the travel one. The travel company I worked at, we needed teams of about five teams of five. The engineering department was ridiculous. And then I think the Elixir engineers who were working on a similar kind of travel software did not have a team that large.
They didn't really need one, which is interesting to think about. And then there was another thought there about, I actually do have some, some friends who've started startups recently who, who chose Elixir again because they were able to quickly establish a foundation that they could be proud of, that they felt they could scale up.
And wasn't one of those messy MVPs where, you know, the running joke is MVP. Just an MVP straight to prod.
Owen: Yeah. And, and when I say resources, there's, yeah, there's like people resources, over, you know, the past 10, 15 years, some of these companies couldn't hire as many people as they wanted, and that happened during the pandemic especially. But, also like machine resources. An Elixir app just doesn't need necessarily the same specs as like a larger app.
And I don't wanna shade any other languages, but, we all know some other languages that are very resource intensive and, you know, Elixir can, it can take advantage of all the resources on a machine, but, I think we frequently find that it requires fewer resources than some of these other languages and it can do a lot more within the same machine than some other languages can.
ÊI think there's also just, even outside of Elixir, just more thought being put into the load we're putting on our, on our users' devices as well.
Sundi: Mm-hmm.
Owen: Like, how well our apps run on low-powered phones and laptops and that kind of thing. So, I think Phoenix and LiveView helps a lot with that. Kind of keeping a lot of the logic on the server so that it works well for any phone that can support WebSockets, essentially.
Sundi: I don't think I ever really thought about that too heavily, like the resourcing on someone's phone in an application until I think it was. When Snapchat released the video feature where you could video call someone, I don't remember if it was before or after FaceTime. I think it was after FaceTime. But, I don't think Android had any kind of face calling, and Facebook Messenger didn't have any kind of face calling. If Facebook Messenger was a thing, I can't remember. And, if I Snapchat video called anybody, I could not hold my phone for more than five minutes before it was too hot to hold it.
Owen: Wow.
Sundi: Yeah. I won't tell you what year that was.
Owen: Right? Yeah. So, I try to, when I try, when I make an app that someone's gonna hold in their hand, I try not to make it, you know, a hundred-degree app.
Sundi: A hundred-degree app. That's a good, that's a good name. Dan, do you wanna talk us through your ideas for types?
Owen: You got some hot type, hot take, hot type, hot takes.
Sundi: Oh, Owen...
Owen: I tried.
Dan: Yeah. I think that I would like to see more embrace for types. I mean, I could go so bold to say some sort of first party typing, but I think that's unlikely and I don't know that I would see that as critical and I wouldn't want us to like head down some sort of weird annotation path beyond what we're already doing with typespec.
So maybe what I'm really asking for is just like more, better tooling around Dialyzer and typespecs, or more embracing of that by the community. Any kind of compiler type hints like that can really improve refactoring and understanding.
And, you know, Sundi, to your point about what VS code can tell you about the code you're looking at. Kind of all of those pieces could really come together and provide just a better experience, maybe an easier experience, a less stressful experience.
Sundi: My notes for this point for, for myself were ducks like I'm ducking and then "types?", question mark. I had a very interesting, I mean, good overall, if I had to look back at this in five years, my overall thought about my experience with Flutter and working with a heavily type system would be impressed.
The overall thing would be impressed. I was confused for a long time. When I started to really learn how to use it and learn the power of it, I think, yeah, overall impression was just impressed. I was, I was happy that it was there. I was happy that it was double checking me and like I said, when I got back to Elixir, I felt a little bit in the dark about what I was doing and I was trying to use the same brain process.
I think actually Owen and you and I were pairing and I did something and you were like, Sundi, your "OO" is showing.
Owen: Yeah, you were like, "property equals," I'm like, oh, "what are you doing?"
Sundi: Yeah. So yeah, switching languages is kind of fun. But yeah, I thought about what can I, okay, so I don't have types in Elixir, but what can I use from what I learned about using types in Flutter and what did I, or Dart, I guess specifically, what did I like and how did it help me think ahead. The one thing that I was like, frustrated originally about Flutter was I wanted to map through something and it just wouldn't let me, because the thing I was trying to map through was not an iterable list or something, and I was just like, I just wanna map through it. I wanna see if I can do it. I just wanna get to the end result.
But, you know, no, it forced me to think about, what am I putting into it? What am I expecting it to take out? Or what am I expecting it to give me back? What's the return? And I think, Owen, you even programmed this way in LiveView, right? You always think about what is the return value and like you put it at the end of your function before you even write the rest of the function, right?
That is kind of the same thought process. So, I learned a lot about how to think about those things differently. It did make me want types in Elixir, but I was like, do I actually want types in Elixir? Do I want myself to think about that more? Do I wanna use typespecs more? Do I actually wanna play with Dialyzer? You know, that kind of stuff.
Owen: Yeah, I think looking at the module that we were kind of kicking around earlier, I think what's missing is consistent use of specs. Even in some of the packages we're talking about. Some of it's because these are new features and you know, they're taking contributions from a lot of folks and, even within projects we work on, you know, I myself will be more consistent sometimes than others about adding specs to things. But, once they're in place and they're correct and once you have all these typespecs and you have, you know, Dialyzer and all the right extensions in your VSCode editor, it's not quite as robust as like a full static text type system, but you do get at least some information, as long as the specs are also clear, like if they're being written out with real words and not just like single letters. You know, they're conveying...
Sundi: There's only so much it can do for you. The engineer.
Owen: Right, right. Yeah. So it's some of it's just quality of, of writing and, and things like that. But, I think whenever we're contributing, I think contributing additional lines to the docs and examples are great, but also adding some specs to these, any of these functions we might be touching would be helpful to anybody as well. So...
Dan: I think the history here, right? Is kind of running, what do I look for? Like cowboy coding, right? You know, like they're just like, throw it together, get it to work, write good unit tests around it, write good tests around it. And that's certainly important, and that's a way of mitigating the kind of suffering of not having types at times, depending on how you wanna think about it. It's all about speed, efficiency, maintainability, right? These are all trade-offs and you can't have it all. Even with our experience with Flutter and Dart. You can write a Dart app and you can use Dynamic everywhere, and it'll be like you're using Ruby, you know, uh, it'll all just say, yeah, sure, I'll compile, I'm not gonna run, but I'll compile.
And then you can kind of layer in things as you want to, or you could write tests so that your non-type code could actually run pretty well. Well, I guess even with Dynamics, you still have to deal with nullability, which is something that Dart will just force you into, which is nice.
When we talk about 10 years of Elixir and what's coming, I think some amount of this needs to be, like we were saying earlier, best practices. You know, like yes, the language is flexible and that flexibility has power, and that lets us get stuff out the door quickly. But then if it takes off, you know, we were talking about like, you know, MVP v1, I worked with somebody once at a previous job, was like, there's no such thing as an alpha.
Because as soon as you put it in front of a real user, it's in production. It's not a beta, it's not an alpha, like that thing's like you cannot take that away unless you like just shutter completely, because people will be upset as soon as taking it away makes people upset or as soon as breaking it makes people upset.
Like, you're done. You know, you're out the door. You know, so that time to market's important, and then being able to iterate on that is important. But then, you know, eventually you gotta support it. And the nature of the project, the nature of what you're working on changes, and that's where these things around upgrade paths and deprecations and typespecs and testing and all of that become critical.
Otherwise, it's unhappy for everybody if you don't kind of lay that groundwork early on. I'm thinking about documentation in that regard a lot more than I used to. And so that's how that kind of dovetails to the rest of this conversation.
Owen: And I think it's great having a perspective from you, Sundi, about having worked on some Flutter apps and the tooling experience that you have there.
Before coming to SmartLogic, I'd worked in PHP and worked in Laravel and had seen some great tools. I was like, oh, that'd be nice to have, like, some debugging tools would be cool. I think there have been some work on that over the past few years in Phoenix. But, because I've focused so much on Elixir and Phoenix, I've picked up on fewer cool things happening in other languages, and I saw that even Chris McCord was kind of writing a love letter to React, even though like LiveView is kind of a...
Dan: A way to avoid that.
Owen: It's like an anti-React kind of thing, almost, but it exists because, you know, React showed how to do some really cool things.
Dan: Yeah. The dom diffing stuff, right? Like, that was industry-changing.
Owen: And then LiveView, I think, you know, if it picks up, you know, enough adoption, it could be industry changing as well. We've already seen a lot of frameworks try to like build something like LiveView even if they don't have all the nice things that Elixir gives us.
Dan: Mm-hmm.
Owen: And Erlang and everything. But, I think kind of keeping an ear to the ground on other frameworks and languages and any kind of conveniences that you get that maybe we're missing.
Dan: Yeah, I think that was kind of my letdown on our polyglot season. That we didn't see a whole lot of that. I think a lot of large companies, they kind of create these silos of technology and so you don't get a lot of that cross pollination.
Or they've just moved wholesale. And something I've always kind of searched for in my career and part of why I like agency work here is the variety, and I think a lot about C, C++, Java, Python code I wrote years ago, even though it's been over a decade since I've written most of that. But, it influences how I think about problems and, and how I use the tools that are in front of me now. And, the variety, even if you can't replicate it, understanding how it's done in other places can be very helpful and informative to your own architecture.
Sundi: Yeah. I definitely appreciate the experiences of having looked at some other languages recently and then just like turned around in the next week, made a new Phoenix project, which I will say, I just have to say it one more time, and this will be the last you ever hear from me. I cannot believe we made a new Phoenix project. On the release candidate 1.7, and then an hour later it was out, fully out one hour later!
Owen: Yeah. We walked through, we spent like what? Half an hour, or an hour or so? It wasn't a lot of time.
Sundi: It wasn't even a lot of time. Yeah I just, the coincidence was hilarious to me.
Owen: But yeah, we kind of walked through like cloning, like forking Phoenix, cloning it, running the local installer to build the archive, generating a new Phoenix app from that, and then literally one hour later, that tweet goes out, it's fine. Uh, I'm fine. Phoenix 1.7 has been released.
Sundi: But yeah, so I mean, that, that was an interesting turnaround time. I do have like, the, the way that I kind of approach things is I do have like a little bit of a oof moment where I'm just like, oh, I was working on something else last week and I'm working in another thing this week. So I do take like a little bit of a settling time. But I'm finding myself thinking about it more now, having just recently switched. I'm just like so curious now to see what could come next to Elixir that are maybe some patterns I saw in Flutter, which is not a perspective I had before I was working in Flutter for a few months, so I think that was cool. I know Owen, you were also kind of curious about the future of deployment. Do you wanna talk about that a little bit?
Owen: Yeah. So, I think we have a, maybe a conversation or two lined up already for the season about some companies who are working on deployment with Elixir. So that's gonna be a fun conversation. I've interacted more with Kubernetes this year than ever in the past. I think because I did work on understanding Docker a few years ago, that's been helpful. Definitely love spinning up Docker dev containers. But even like deploying on say, AWS versus something like Fly where everything's a little bit more managed for you, versus DigitalOcean or just buying a machine and plugging it in, you know, running your own data center.
Sundi: Dan's making a great face.
Owen: What could go wrong?
Dan: Don't do that.
Owen: Or like just, you know, running on what we call bare metal, which could still be a cloud machine, but, just a Linux machine, you know, that you're kind of running. So, yeah, I think, there's every organization probably, you know, if you have five engineers, you're gonna have 10 different opinions on how to do something. So I'm kind of looking forward to see. is there also like my kind of hobby thing is like even a kind of an offline non-internet kind of application. So, thinking about kind of local Wi-Fi kind of deployment stuff would be fun too.
Dan: Yeah, I'm super interested in that as well, you know, and I think that's something where looking at the last 10 years, that has changed a lot, and I expect it to continue to change. Maybe not necessarily because of internal forces, right? There was a big internal push in the previous 10 years to make Elixir more deployable, Phoenix more deployable, because it wasn't a first party release type situation for a while, given kind of he pedigree of the language. But this is something where external forces are always gonna be pushing on, any framework, any language. As far as what the kind of deployment story is with, like you said, things like Fly versus what's the latest from AWS or what's the future of Kubernetes? And you know, it's, this is, these are the kinds of things when you start to get down these paths, you realize, no one can know it all. So, you really start to look for community best practices and kind of the pros and cons to try to make an informed decision. Especially if you are operating at a size where you don't have a dedicated, you know, SRE team or something like that.
Owen: Yeah, and I'm looking at our guest list, which is shaping up nicely. We're gonna hear from some returning guests who have been with us over the past few years. So that's gonna be great to kind of catch up and see where they've been. And kind of we're kind of thinking of these episodes in terms of different conversations about the future of Elixir, so kind of different aspects within that area. So it's gonna be great to talk to some... not old... but like returning voices as well as some new voices and thought leaders and maybe even some newcomers to the space. So, it's gonna be a really fun season.
Sundi: Yeah. We're in addition to our returning guests, we'll have Bilal hosting a few episodes as well. Continuing that. Just wanted to shout out Bilal! Hope you're having fun in Greece.
Owen: Oh yeah.
Sundi: Not here with us today, but I'm sure you're not bothered by it.
Owen: Don't blow up his spot!
Sundi: Yeah, this should be a really interesting season. Dan, did you have any other thoughts or notes on the future Elixir things that you're looking forward to before we kind of wrap up here?
Dan: Yeah, I wrote a big paragraph here, preparing, cuz I thought about it for a few days and I was trying to think like, what's the right way to word this? I'm gonna take a run at it right now, I wrote, you know, How Elixir's gonna keep making the complex, hard, expensive, and I mean that in terms of, you know, staffing, size, computer resources, architecture, how to make those things more accessible? And I think we've seen that with, you know, LiveView, letting Elixir-focused teams do very dynamic front ends without a dedicated front end team, or without learning react or without learning, insert JavaScript framework of the day here. Distributed computing things like Phoenix Presence and WebSockets and Pub/Sub stuff. Asynchronous background work with, you know, managing processes in the language as opposed to processes at the operating system level. Opening up the world of embedded via Nerves. What we're seeing with Bumblebee, Nx, Axon, Hugging Face models, you know, ML stuff. These are things that took, either, you know, extensive research, dedicated teams, and they're now, you know, maybe you're not gonna solve all the problems with your small, handful of people team, but what it lets you prototype to prove there's a path forward, what it lets you embrace so that you can determine whether it's a good fit, and then before you invest additional resources of, generally speaking, that's people over, you know, everything else. I think it's really exciting and, there will be problems that come up in the next 10 years that Elixir may have a good story to solve that we can't even speculate on now. But I think it's just really interesting to see Elixir's track record in 10 years of making things that were a little out of reach more accessible to smaller teams, and I'd like to dig into how that can continue.
Owen: Yeah, and we can, we can put Elixir on phones now, so maybe there's even like peer-to-peer stuff that's gonna be really cool.
Dan: Put it everywhere.
Owen: Right. Elixir everything. Right?
Sundi: I think the only other thing I'd, I'd curious about seeing Elixir do is, maybe, learn, take a, take a note or take a, take a leaf out of the books of other BEAM languages. I don't know a lot about the other BEAM languages. I was in our BEAM season, excited and bamboozled to hear there were 30 something BEAM languages. I figured there was more than Elixir, but I just did not think we were in the upper 30s. and I'm sure some of those languages are doing some interesting things. So, I'm curious kind of what could Elixir learn from the other languages? Are there any features, any patterns to emulate? And I'm curious if we can talk to some folks about that this season as well.
Owen: Right on.
Sundi: Cool. Well, I'm super looking forward to the season. I hope everyone listening is also looking forward to the season. So just make sure you get to tune in to next week for more on the next 10 years of Elixir.
Owen: Elixir Wizards is a production of SmartLogic.
Sundi: You can find us online at SmartLogic.io and weÕre @SmartLogic on Twitter
Bilal: DonÕt forget to like, subscribe, and leave a review!
Owen: This episode was produced and edited by Paloma Pechenik for SmartLogic
Sundi: WeÕll see you next week for more on the next ten years of Elixir