S11E08 Frameworks Phoenix vs. Rails
Intro: Welcome to another episode of Elixir Wizards, a podcast brought to you by SmartLogic, a custom web and mobile development shop. This is Season 11, where we're branching out from Elixir to compare notes with experts from other communities.
Owen: Hey everyone, I'm Owen Bickford, senior developer at SmartLogic.
Dan: And I'm Dan Ivovich, director of engineering at SmartLogic, we'll be your hosts and guests for today's episode. For episode eight, we're comparing notes on using Phoenix with Elixir and Ruby on Rails, uh, really diving into the history of SmartLogic here.
Owen: Yes. And just for the record, this is the cool kids table. So that's why it's so limited. This is a small 
Dan: Right, right, right. Something, something like that. That's why we spend our free time coding. Uh, anyway, Owen, we've done the personal background questions before, but hopefully we have some new listeners. So why don't you take a couple minutes here? Tell me about yourself, where you're from, what are you up to? How your Thanksgiving was
Owen: I'll do the fast forward version. So,, so yeah, I've been, I've been with SmartLogic for two years, just over two years now. And, most of my background professionally is customer service, retail, tech support, that kind of thing. And just to fast forward a little bit. I went from customer service, started like learning code and stuff on the side after hours, did some work, I was also kind of like juggling customer service.
And then finally in 2019 started coding professionally, getting paid to write code. So, did, a couple of years with PHP. And, advocating for Elixir at the place I was at, and then finally I was able to graduate to Elixir through SmartLogic. 
Dan: fantastic.
Owen: How about you? a little bit about your background.
You've also kind of come from a bunch of different places. So, what's your history?
Dan: Sure. I've been at SmartLogic, 12 and a half years. my journey into programming is probably more traditional. you know, started as a interest and hobby. Before college, did it in college, had the very, like, expected enterprise y Java job. Out of college, learned Python, and then got exposed to Ruby, and said, that sounds better.
 Went hardcore on that, ended up at SmartLogic, doing Ruby on Rails, and then was kind of part of the decision making and move to Elixir, , for us, some number of years ago.
 That's where I'm at.
Owen: Nice. So, we're going to get, a little bit more into the weeds here in a minute, but we are recording just a week after Thanksgiving. So I think I'm finally recovering a little bit from the amount of food that I ate. And I saw some pictures, some really appetizing pictures that you posted from your Thanksgiving.
So any highlights or low lights from your Thanksgiving?
Dan: no lowlights, maybe. highlights, you know, I really do like to cook. So I had made some good loaves of bread, some good pies, and, I think the best turkey I've done so far, , , in my life. So, I'll, I'll take that as a win and move on from there. How about you?
 
Owen: Wow. Best Turkey ever. That's a, it's a big claim. That's a big accomplishment. 
Dan: personal maxima. I'm not claiming to be better than anybody else that's turkey.
Owen: What did you do differently this year? 
Dan: So I smoked it this year instead of like, in the inside oven. that was the big difference. 
Owen: Okay. So I was more cleanup crew this year for thanksgiving than prep and cook crew. Which is nice because I don't like to wake up early and putting the turkey in the oven at. Six o'clock was not an option for me, so, 
Dan: There you go. 
Owen: I can grade the turkey that I had was really nice. It was moist. I helped a little bit with prep, so.
What they did, I had like two Thanksgivings. I won't tell you who gets credit for the best
Thanksgiving. I don't want to be diplomatic here. 
Dan: That's fair.
Protect all involved. 
Owen: but the turkey, one of the turkeys went into a cooking bag. So it got, you know, pumped full of all the seasoning and everything. And then it went into a cooking bag.
It's the first time I've ever seen these used. So, turkey goes into a cooking bag On a pan, and then it gets cooked, for eight hours or so. And it actually did come out really juicy. It was not a dry turkey
Dan: Nice. 
Owen: did a little bit of taco Thanksgiving for So that was fun.
Dan: There you go. Gotta mix it up a little bit. 
Owen: Look, it's always taco Tuesday at my place. So 
Dan: Excellent. 
Owen: rarely the day that I'm not eating tacos. Cool. So speaking of birds,
Dan: Nice.
Owen: let's talk about Phoenix. I don't know. Ruby's joke. I don't know. so, okay. So you came in, when you started with SmartLogic, you were working mostly in Ruby on rails or was there something before that? 
Dan: SmartLogic had done some things before Ruby on Rails, but when I came in, we were all in on, Rails and I came in specifically to work with Rails. For me, there was something about Rails is kind of like, assume reasonable defaults, low configuration. I Had been doing Java, Spring, and Struts stuff that was just like crazy amounts of configuration.
 That very polar opposite thing really spoke to me. Ruby as an interpreted and very kind of readable language spoke to me. , and so I grabbed a couple books. I don't even know if they're still in print, but like this used to be these like Sam's, I think it was Sam's Sightpoint.
I know Sightpoint was one of them. And then these like learn something in some number of hours or days or months or whatever it is type books. And so I found that I was able to. Build the prototype in Rails real fast. And, you know, the build a blog in 10 minutes was, a big video back then.
, and that was, for the time period. early, early knots. stood out compared to what I was used to. And so that really pulled me in, , for sure. and I'd been doing some work in some other kind of ORMs and so active records just look at the table and figure out what's there and kind of give you everything you need was, pretty appealing as well.
aNd so I, jumped in as, as best I could, did some side projects, was able to get some projects at my former employer to also be in, in Rails and show what was great about that. Also did some work in Django at the time. So I had a little bit of comparison there. And, I think the evolution of Rails from 1.
0 to 2. 0 to 3. 0 days, when I was, most hands on with it, it was great to see it evolve and, formalize some things around like plugins and gems and, you know, seeing Bundler come in really matured the platform, , and made it, Just more and more of a joy to work on, it got easier to deploy and, really became something that I think was an easy default choice.
iT was a , great journey and I still, probably for anything lightweight, especially scripting, find myself just reaching for Ruby more than anything else.
Owen: Yeah. So you, you'd use it for web apps, background processing, what other types of tasks would you pick up Ruby for?
Dan: aNy kind of like little DevOps y, like I need to move a bunch of files or process or reformat some CSVs or JSON or things like that. I tend to do that in, in Ruby. Professionally, we were doing web apps with background workers. We did rescue kind of back in the day and then, we're big fans of Sidekiq.
everything that we still do in, in Rails is still using Sidekiq. , I know there's been some evolution and I think we're going to talk a little bit more, maybe in a bit about, kind of where the frameworks are going. But Rails has really brought more and more 
Tentpole functionality under the Rails umbrella, , or at least created common interfaces to, to things, which has, been interesting, but hasn't been something we've embraced a whole lot, , because most of our things were written before those, those interfaces existed.
Owen: Nice. We're kind of approaching this conversation from two angles, right? Like I'm primarily an Elixir Phoenix developer. You are writing a lot of Elixir and Phoenix nowadays, but, come from more of a Ruby and Rails background. So prior to rocking Elixir and working with Phoenix, the other frameworks I'd used were JavaScript.
So I dabbled a little bit in React. Definitely wrote some jQuery back in the day. 
Dan: Who hasn't?
Owen: Uh, right. Uh, you know, 
uh, back in the early, early 
Dan: Yeah. 
Owen: early 2010s and stuff, 
so. 
Dan: you said you were doing PHP, 
right? 
Owen: yeah, whenever I started getting paid, that was writing PHP. I'd written a little bit of PHP before that to, to deal with WordPress, really before I knew what I was doing.
You know, like just open up some files and just start changing stuff and see what happens.
Dan: So were there any frameworks involved when you were doing professional PHP?
Owen: Uh, no,
Dan: Okay. 
Owen: that's the fun part. So that was Wild West PHP.
Dan: So something that must have really drawn you to Phoenix then was, like, a framework, some amount of structure?
Owen: Yeah. So, so this is kind of the funny thing is like my first paid job was kind of like a zigzag thing . I'd really , , built my fundamental skills using JavaScript and the framework that I really loved when I was writing JavaScript was Vue. I hadn't really written a lot of Vue since I started working professionally, but, , I liked that I was able to build projects just by importing it from a CDN.
And didn't need to run a server even I could just write a file that would do some things and, that worked well enough. So it was kind of like gradually learning how to build things and then deploy and then, building up other skills as well. But,, through the entire two years I was writing PHP full time.
I was going home and like writing Elixir and Phoenix. On side projects and stuff. , even read a couple of like prototype things that I demoed to the team that I was working with, using Broadway for data processing and stuff. Cause there was some Kafka pipelines that we could have hooked into.
Dan: Nice.
Owen: buT yeah, Phoenix is definitely , the framework that haunts my dreams that, uh. Yeah, if I'm thinking about how I'm going to do something, it's usually with Elixir and Phoenix is my first thought. So,
Dan: So as, as you've worked in Phoenix and have seen it evolve, what, what things have really stood out to you?
Owen: Let's bury the lead with LiveView. I think code organization has been something that, , it seems like at least within the framework itself, the preferences are kind of established.
, in the community, there's definitely a lot of, , debate and everywhere you're going to go, you're going to see a different approach to organizing your code.
Whether it's, you know, using a web module or like how things are named and structured and which, how many folders are going to have kind of depends on the team and how the team likes to organize and if, if they organize it all right. sO I think that's the first one is like just having a framework helps you, think of how to organize your code.
Like when you're writing. Raw code without a framework, , if you're experienced, you probably do have some preferences, but the PHP frameworkless PHP that I was writing, just kind of anything goes every repo had its own idea of where things should go. And then, you would basically have to be the expert for that project to know where to start 
and like how to update things. 
Dan: when you came to Phoenix, were we already on like contexts and everything in the lib folder?
Owen: Yes. So I think at the time I was learning Phoenix and Elixir and really starting to grok it was somewhere around 1. 3 or 1. 4.
Dan: Yeah. 
Owen: And I definitely was watching talks all throughout that time, before I was even writing stuff. So,
Dan: Yeah. , even today, my muscle memory of things being in the app folder from rails and early Phoenix days, it's just like so strong that I still, I was trying to go to a context and I'm on the command line. I'm just like vim space app. Nope. That's wrong. Go back. 
Owen: right. 
Dan: so.
Owen: not in there. Yeah. , what are some other features? I think Plug is great, 
Dan: Mm hmm. 
Owen: there's some really great abstractions in Elixir and Phoenix. There are all these kind of building blocks that are used within the framework, but you can also kind of extend and customize in your own ways. So even though like you run phoenix. new and you get a bunch of code, you can alter that code quite a bit to make it do what you want. You can remove things or add things in it. It's pretty lightweight. So like one thing I did whenever I was at my previous gig was we were debating programming languages, frameworks and stuff.
And I wanted to do a kind of apples to apples comparison for like just a brand new empty project. I compared, was it Django? Is that PHP? 
Dan: that's Python 
Owen: Python 
right? 
Dan: code. 
igniter is a 
popular PHP one. 
Owen: right. We were looking at, uh, PHP was what we were already using. Another team was using Python.
And of course I threw in Elixir to the mix as well. But so for PHP, we compared,
I think Laravel and then maybe a different framework. I don't think it was CodeIgniter. But I know Laravel was a pretty big, hefty project just out the gate.
This is the kind of the fun thing to compare with frameworks. And some of them like batteries included can mean different things.
So. That was like all the different sized batteries were included with, with Laravel. , Django is kind of a similar approach. And then Flask was the other one I compared in Python.
I liked the idea of Flask of just, I'll figure out what I need kind of whenever I need it. And then of course threw in, Phoenix just for comparison. So I think Phoenix, Flask were a similar kind of size out of the gate. 
oF course you're not getting authorization built in, or at least at the time I was doing the comparison,
Dan: Yeah. It's less true today, right? 
Owen: right?
in terms of size on the disc and number of files you have to dig through, those two are like pretty minimal compared to the and, , Laravel
projects that you could spin up.
Dan: Yeah. Well, and I know you've got a lot of passion for the, , generate and then customize kind of approach. At least I've, I've observed that from your approach to things. And I think that what I've observed to your mindset really does align with Phoenix's kind of approach of we'll give you a starting point.
But then it's pretty easy to modify and you generally don't have to mess with the framework to change the defaults in various ways. And I kind of like that default component set and, then we can kind of take it and make it what it needs to be for that application. Whereas I think on the Rails side, you know, I think we've, we've seen, I guess, you know, I've generally avoided things that bring a lot of UI with them because then it becomes kind of hard to, to tweak.
And, you know, where do you put things, how do you organize things? That's always been a, I think an evolving journey in both, frameworks, both platforms for sure., and now we're seeing, the LiveView approach show up in other places as well. , so clearly 
that's, , gaining some traction.
Owen: Yes. LiveView is a big one. So. kind of like a sub framework really, cause it, of course it's, it's rolled into Phoenix proper now whenever you generate a project it's gonna have LiveView by default. You can still run a new Phoenix project without including LiveView, but , I love LiveView, I use it pretty extensively, I do need to update to the newest version of Phoenix and like kind of get, familiarized again with the async stuff, like the async assigns and some of the really nice improvements that have been rolling in.
We've done a little bit with streams, on a project or two,, works really well. There are some, a couple of pain points more around like knowing when a stream is empty, for example. but, overall pretty great. 
Dan: And I struggled with, replacing a stream the other day. Like you kind of can't, right. You can only add or remove from it. 
Owen: There's an option.
Dan: Is there an option to start over? 
Owen: Um, yeah, whenever you do, so you pipe your socket to like a stream and you would say a stream, you give it the stream name and then the value you can add like a replace colon true option. And that should replace the stream.
Dan: Okay. 
Owen: , all right, that's our, quick huddle slash pairing time for this episode. 
Dan: there you go. Yep. 
Owen: So in rails world, uh, I know, was it turbo links were kind of like, uh, an early version of kind of keeping some portions of the UI running while other portions of the page would be, swapped out in the browser, 
Dan: Yeah. I was never a big proponen ht? or user of TurboLynx, it seemed like there were just some edge cases that weren't particularly well handled. And I think for apps that we had that already had a lot of JavaScript, it seemed like it was potentially more trouble than it was worth to kind of pull it, pull it in and make it handle kind of this different way of determining whether or not the page is ready.
But, the idea of, you know, there's some amount of the page that you can just replace, think in its early incarnation it wasn't doing any kind of diffing like you see with React or LiveView, but it was more like anything between, these tags could just get wholesale replaced from the server, and you at least then weren't sending the whole page load again, you weren't causing the browser to have to refetch all the things in the head tags, , you kind of just have a lot more state just persisted as the page was replacing big elements. And that was kind of rails is like general JavaScript approach server side JavaScript to just send little snippets of replace this HTML with this HTML without doing very much JavaScript writing. And so it was almost kind of an evolution of rails is approach around, not having to write JavaScript, but still be able to make a dynamic page that didn't have to fully refresh. And I think all of that has really evolved since then, but, our rails projects are more in keep them running mode as opposed to embracing huge new features.
Owen: What we were talking about there is Turbolinks allows you to, I think the go to example in my mind is like a audio player. Like you can have, a music player, podcast player or something running on your site and have it pinned somewhere and then you can reload other parts of the page.
let's say you've got a site where a user can listen to a podcast episode. Maybe Elixir Wizards, but they also want to be able to bounce around different blog articles while they're listening. TurboLynx has been around for a while. It's one way of allowing you to do that. We can do the same thing with LiveView.
And we'll talk a little bit about protocols and how all this works under the hood a little bit. But you can kind of do the same thing. You can render some content that stays statically rendered on the page or has its own state. Um, in LiveView, which could be multiple LiveViews on the same page, or you could have components that are live and manage their state.
There's a bunch of different ways to kind of solve these problems. And then you can kind of do the same thing. Like play a podcast episode , that stays on the page while the user is navigating the page or doing whatever until they sign out. So the protocol, the way this works is if I remember correctly, turbo links was mostly doing Ajax II stuff.
right?
Dan: Yeah, that's my kind of understanding. , and it had, , it was big on giving you kind of events and hooks so that your existing JavaScript could know when turbo links had finished or updated the content of the page or, pieces like that 
Owen: Hmm. And with LiveView, at least by default. And I think. I can't think of any exceptions where people are not using WebSockets, but WebSockets is the protocol, the underlying web technology that underpins the whole LiveView approach. And then it also uses a Javascript library called Morph DOM that actually is responsible for receiving messages on the web socket and parsing them into DOM elements it could be like a whole component, like a card component, or it could be changing just a number or a piece of text somewhere.
So it can be kind of as granular or as broad as you want it to be. depending on how you program things.
Dan: Yeah. 
Owen: , so ? I love WebSockets. There are limits to WebSockets, but they work very well. Especially for like kind of UI state management. And I know that using WebSockets and writing WebSocket code in PHP was basically just not going to happen.
Dan: hmm. 
Owen: It's really just not made for, for long running connections. You can interact with WebSockets with JavaScript at least in the client, it's fairly straightforward on rails. What's the story with WebSockets? Is it something you can kind of do, using standard library, or is it something where you kind of need to reach out to an external service for help? 
Dan: 
I believe that it's now a core piece of it. This is actually starting to get a little newer into Rails than my day to day knowledge. , so my understanding is that it has become more of a core piece. That's really all I know about it.
Um, I know the thing that makes me nervous as an old school Ruby on Rails developer is the idea of like having to have persistent processes and connections and managing that memory load and everything else. But, you know, I know that's an evolution kind of across the board of dealing with that and you know I think having learned Elixir before getting into the kind of idea of like a LiveView with WebSockets, it's a pattern that so clearly fits what Erlang's doing for Elixir, that, yeah, it just, it makes sense there.
Owen: We have not even talked about. the most fundamental part of both of these languages is their programming paradigm, right?
Dan: Sure. 
Owen: So, right, Rails, we're talking about object oriented programming. So you're building objects, classes, you're writing interfaces. I don't know if you do traits or if that's just something I saw in PHP.
And with Elixir, we're in a almost purely functional programming language, with some escape hatches., Rails, other, object oriented languages, typically, if they allow concurrency , it's usually through threads. With Elixir, , it's functional programming, so data's mutable, but we also interact with processes, which are kind of a core piece of the underlying virtual machine that we built on top of from Erlang. So, , when we think about comparing the frameworks, that's kind of like an underlying piece, is like how you think about problems and how you solve the problems is actually just a little bit different in some fundamental ways because of the approach to programming, , the whole paradigm.
So, 
Dan: Yep. 
Owen: So you've worked in both. I've worked very little at all in rails. 
Dan: hmm. 
Owen: What are some differences you see in terms of the comparison between functional and object oriented with these two languages? 
Dan: You know, there's a real approachability and niceness to object oriented, you know, and when you're thinking about the nouns of your app Rails did a really good job of giving you the ability to generate some things where you would be able to, define whatever model you need, right?
And then invoke, invoke things to modify it, to change its data, to query what it's about, to find things that are, it's related to you know, there's active record does a very good job of modeling real world things against the database. And then, the real world is complicated, and side effects of things get to be really complicated.
And, , I think that's where, , people get into, into really tough, and it takes a lot of discipline to, well manage your callbacks and, chain of, changes. When all you're doing is invoking a method on an object and you don't really know what the data store underneath is going to do.
 Or it's possible that you don't know if you're too far abstracted from it. for me, of seeing what Ecto is doing with the repo pattern and the data pipelining in Elixir was just like a clear, especially for the types of web applications, data intensive, CRUD display type web applications that we do. The immutability 
and kind of pipelining, , in Elixir was just like a clear win for a lot of what we were doing .
 but I still do find myself every so often where I'm like, Oh, I have a user. And I just want to like modify this thing. And I want to do like user dot thing. And it's like, Oh no, I have to like pass the user to the right function that will do the thing. And then maybe committed to the database, depending on where we've drawn our abstractions, But I think, you know, certainly for the app that you and I have been working on the most recently, , I think we've done a really nice job of creating some really clean context and, the refactors that we're able to do and the way we're able to just kind of manage.
Data in data out, and even as we've gotten, , the first few months of the project, things aren't particularly related to each other. Right. And then all of a sudden you start having all the things that join things together. And, you know, it's, it's a tough call, I think on, on both rails and Phoenix, you know, where do we put these methods?
But also, the beauty of Elixir 2 is it kind of doesn't matter, you can put them somewhere and then you say, Oh well now, now I have all these things that are related, so like I'm working on a refactor now, of taking a bunch of functions that are about status updates on some things, and I'm just gonna like pull them into their own like service module, so that they're all gathered together.
And all that related code is together. But it doesn't really matter to anything else. , whereas, unless you take a service oriented approach on Ruby, where those methods are matter. Because they have to be where the data is.
Owen: Right. so both languages, any programming language really can interact with the database. There will be some kind of tooling and in Elixir land. We tend to use ecto and rails. You're talking about active record is the kind of the database interface. Once you're storing all your data, it needs to Stay somewhere like it doesn't, we don't, I hopefully keep all of our data and our code.
That's, that's a
Dan: Yeah. 
Owen: in memory, right? That's why I'm going to do it now. All right. Quick side, tangent here. One of the first real applications that I worked on was a PHP app. There was so much state and the code of like, if account ID equals this render some other stuff, if account ID equals that.
Render some, this like, it was like each customer has their own like demands. So we're going to just put that all in the code. 
Dan: It's a template driven development.
Owen: template driven. Yes, it was, it was something I like that broke my brain. I was like, we gotta, we gotta not do this, but, uh, yeah, I'm glad that we, we keep. all of our decision making, like our decisions happen in the code, but the state tends to live either in the database or, you know, wherever it makes sense. Sometimes it's in memory, sometimes it's in a module attribute or whatever,
Dan: hmm.
Owen: Wherever it makes sense. Depending on, I think that the way I think about where to put data is how often does it change
and who needs to change it. If it basically never changes while the app is running and It only needs to be changed by developers that lives in the code., That way it can be accessed quickly by the application. It can optimize itself. And then if we've got any kind of data that needs to be modified by a user, which could be an admin or even a developer or someone on our team, then that probably goes in the database in one form or another.
But, yeah, I do like the way that Ecto, like Ecto's abstractions, you can even just break out into raw SQL if you really can't figure out how to get the Ecto functions to compose and give you the results you need. But we've done some fairly tricky stuff, even in this project, and I haven't really felt the need to write raw SQL.
Dan: Yeah, I mean, I think I did some stuff with like three or four joins and some aggregation and you know, it took a couple, a little bit of trial and error, but you where it needed to go. And really talked at all about testing, but I do find, unit testing in both is very good. We were big RSpec users . For Rails and Ruby instead of the test unit kind of default. and that's just more really about syntax. I think both languages really do give you primitives and a great approach to, to making a testable, well tested application.
 and Rails was certainly my first kind of real big push into testing. You know, we talked to, you know, academically had talked a little bit about, unit testing in Java. , but it wasn't something that seemed like it was such a big force in like the Spring and Struts world when I was doing that type of work.
 But was clearly just like a big priority on the Rails side, and I think, to everybody's benefit. You could argue that was because you don't have types, so you need another way to enforce that your thing behaves the way it needs to behave. But one thing I do think that I hadn't really thought about, you know, especially with LiveView, , is like how testable that has made.
The web, kind of web interface of the app we're building without the need to bring in like a browser or, or really anything. Right. And like browser testing, uh, whether that's like Cucumber or capybara or, Wallaby, 
I mean, those are all great products.
And testing your product in a real browser, automating the browser. Super valuable, but I have very much enjoyed in LiveView, the ability to just say like, find that button, interact with that button, give me back the HTML that changes, does that contain what I think it does? Okay, great.
Like, assert the things, refute the things, all within the same process tree and not having to think about else And then it test suites fast when, when you, when you can do it that way. Um, and that's, that's been a big benefit. 
Mm 
Owen: So what we're talking about here is in the LiveView framework, there's a module called LiveView test and it gives you, I would say covers 80 to 90 percent of what we need for, for this project is covers about a hundred percent, , as far as like, UI testing integration tests.
so mY side project does rely a lot on some browser APIs, which are just not testable through LiveView. If I was going to be testing, you know, WebAuthn or, copy and paste or that kind of thing, then I would need to really spin up maybe Wallaby or write some JavaScript, Cypress or Jest test or something, which means learning another testing framework.
Dan: Mm hmm. 
Owen: so Not super thrilled about that, but, in LiveView land, as long as you're talking about elements that are on a page, or event handlers and making sure they respond correctly. Yeah, we've got everything we need just baked into the, the LiveView framework now. So, yeah, you mentioned types.
 I know types is a hot topic. Maybe if we put types in the title of this episode, it'll get 50, 000 downloads. So we know that, types and the evolution of types in Elixir is an ongoing conversation. There's a bunch of research happening and maybe in the next year or two, we'll start to see static typing baked into the language.
Is that something that's evolving in Rails as well? Cause Elixir, Rails so far are almost entirely dynamically typed languages. If I understand correctly, 
Dan: Yeah, I haven't seen anything on the Ruby side, really, in this regard. And we didn't have kind of the Dialyzer spec typing that Erlang brought to Elixir. which, , speaking of, progressions to these languages, Dialyzer was not something I tackled early on. And, now we have I think a decent amount of spec around some of the stuff we're working on and you know, it catches, it catches me every so often.
I think, , probably in the last, I don't know, some number of days it's caught more of. The spec is wrong, , but still, , worth fixing. Cause then you know you've got that assertion going forward. And it is really handy to look at a function and say, Okay, what are the different tuples this could return?
So that you can handle them all in your case statements or conditionals or whatever. , and so I'm glad that we have, we've put them in there. And it's nice to have something. 
Owen: Right. And Dialyzer is, it's never wrong is what they say. But your, your code can definitely be 
Dan: Your code can be wrong, yes. And your dialyzer can tell you something's incomplete. it is never wrong, that is true. , and it's not always the best at telling you what you're missing. But you are the one who's missing something. 
Owen: oNce you've, it was an invalid return or no return, uh, there's, there's like one particular dialyzer error that the first 50 times you see it, you're going to be like, what? where do I even start? But then once you, understand why that error is happening, it's just because something is wrong in your function.
You're doing something that's just going to break. It is a very vague error. No local return. That's the one. Sometimes you'll see that and you'll think dialyzer, how could you? But then, you know, you dig a little bit further and you're like, Oh, well, okay. You were right.
Dan: Problem exists between keyboard and chair.
Owen: right. Yeah. And a lot of times the issue is just not being like, you'll catch more errors.
The more specific you are with your specs.
Not ironically, but Logically, this is a thing I struggle with sometimes like, how many structs do I want to create to represent all the different permutations of events and things that are happening in my system? lot of times we'll use just plain maps to represent different data structures, especially variable data structures.
But, , there are definitely a lot of cases where having structs help Dialyzer kind of. And even without dializers, having, being able to pattern match on structs helps you avoid some, some really easy errors. 
Dan: It's a spectrum, right? And I think we went to like the extreme, 
but in like a good way, , On our like authorization code, you know, recently, right. And that's like, and that's an area where you want to assert that the structs have the keys that they need to have, that these are the IDs that we're going to compare to make sure that access is what it's supposed to be.
And, and then you get all the benefit of kind of those types, throughout, which is, uh, which is is good. 
Owen: Right. And we're not even using passkeys yet. Just wait. Uh, yes. Passkeys. Coming soon. To a custom software project near you. So, another big topic and a way to measure, should this be a Ruby or a Phoenix project? There's distribution, like how many nodes do I need to deploy to and do these nodes need to talk to each other?
The other is dependencies. I do find that like I can build a lot of stuff and not necessarily need a lot of dependencies with Phoenix and Elixir. I need the big ones, you know, database connections, data processing and like there are particular needs that I can fulfill just by pulling in a dependency, but more often than not, I can also just write some code and get things done. Is that, is that kind of the MO with Ruby? Are you more likely to pull in dependencies things? 
Dan: yeah, I would say our Rails stuff has longer lists of dependencies, generally than our Phoenix things. And, I don't know, is that, is that age? Because there's certainly a difference there. Or is it the language, or is it the framework, or what have you? , and I think the other side of that, too, is how many dependencies do your dependencies have ?
, and I would say, especially on that side, the Elixir stuff tends to be tighter. You know, and that could be that some of the primitives, especially for multiprocess and, , just a lot in there. , and so you don't need to reach for things necessarily. , You know, and I think the kind of community around it is also a little bit more along the just use what you have, don't pull in something else if you don't need to the mentality.
Owen: Yeah, I think we have a luxurious standard library, so it doesn't do everything under the sun, but it, it's like very general purpose. So it works in a lot of different contexts. Is that true with Ruby as well?
Dan: Yeah, I mean, the center library in Ruby is great, you know, and I think, there's always the, there's a, uh, I don't know, meme, , or, it used to be an online quiz that we would take back in the day to see how we were doing, where a lot of people came to Ruby because of Rails, and so it was always like, well, is this, is this function, is this method, because Rails or is it because Ruby,
where do those standard libraries, end and where does the other ones start? Because Rails added a lot of, things to make the code look pretty, and they're all doable some other way, but sometimes the, the, the version you're used to is actually there because of like active support that added it, and Ruby's ability to let you modify Ruby with Ruby when you launch your Ruby, makes it more difficult to see where those pieces are coming from.
Owen: We're talking about monkey patching.
Dan: patching. 
Yes. 
Owen: That's a term I've heard 
Dan: That's the term. Yeah, cause you know, why not at boot, why don't you open up the integer class and change how integers work? Go for 
it. could go 
Owen: What could go 
wrong?
Dammit, why don't we have monkey patching in Elixir?
Dan: Uh, because we made a good choice.
Owen: Yeah, yeah, yeah. I don't want to be, having a different experience of integers between projects. That would be, I can't imagine.
Dan: you only do to yourself what you do to yourself in that scenario, unless you have some bad actor, but yeah, 
Owen: Well, we're all bad actors on occasion, right?
Dan: Yeah, I 
mean, 
Owen: Right? 
Dan: of the worst 
code ever seen is mine. Some I have 
Owen: Are there any other we're an agency, right? So we, we solve problems for clients that come along. Some of them are technical. Some of them are not. If we have a client who maybe has heard of Elixir and Rails, is there a quick and easy way to say we think this project should be one or the other, or is it more about the team
Dan: I think our stance is it should be Elixir these days. For a lot of what we've talked about around testability, live interaction, data processing, pipelining of data, functional, you know, for data heavy applications, functional approach has some significant advantages. The list kind of goes on and on and on.
The reality is they're both great frameworks. They're both great languages. with the right team, you could do well by either. And so generally I think when we're talking to potential clients or anyone else, , you use what your team wants to use because that's really the biggest productivity boost.
You're not going to unlock some magic potential by picking some specific language. But using what the team is passionate about, is familiar with, is excited about those things, make real measurable impact. I do think with Elixir and Erlang, as we've talked about in, ten and some seasons worth of this show, the distributed nature, the networking, what we get out of LiveView now, Phoenix presence, you get a lot of stuff out of the box with Phoenix and Elixir.
that, , can have some real advantages. And if your application has requirements that align with those, then you're giving yourself a little bit of a leg up by picking Phoenix.
Owen: concur, strong concur.
Dan: Yeah, I didn't 
Owen: Yeah. I. 
Dan: on that one.
Owen: Right now I think we should be using jQuery all the way. I can't even say it with a straight face. All right. Well, I think we've kind of covered the bases we're not saying Elixir is better than Ruby. Phoenix is better than Rails. I definitely enjoy using Phoenix and I feel like we can get even new team members up to speed pretty quickly whenever they come from outside of Elixir.
I've witnessed that with a couple of team members. So I'm excited that, it's not like there's, a learning curve, right? you do have to context switch from, object oriented to functional programming. That's probably the biggest one, but, Elixir did come from Ruby people.
So you can kind of almost see the similar, it's like a cousin, right? It's like they 
both have like similar features. 
Dan: and even in the last 14 months, we had an employee come in with a little extra experience and then learn Ruby and was able to be productive quickly. There's a lot to love in both directions. There's a real advantage to knowing more than one thing.
That's kind of always been my, approach and, I'm happy to know both. I'm happy to keep learning about both. , although the focus of most of my knowledge and skill set growth is, is in the Elixir world at this point.
Owen: Right on, well, I know we have some, some more fun conversations coming up this season. we've got some great guests lined up, so keep your eyes on the podcast feed. Make sure you're subscribed if you're not already. And, before we wrap up any final plugs, I don't know about you.
I'm on LinkedIn and that's my last social network.
Dan: yOu could find me on LinkedIn, smartlogic. io, learn more about us and what we're 
doing here. I'm Dan Ivovich on LinkedIn and, always happy to chat, , whether you have a project in mind or don't and just want to like talk shop, we're super receptive to that and, would love to hear more about what you're doing and what your needs are.
as, we've said many a time before, we're SmartLogic. We do custom web and mobile software in Elixir, Phoenix, Ruby, Rails, and Flutter. yeah, reach on out.
Owen: Awesome. Well, thank you so much for listening to this week's Elixir Wizards, and we will catch you next time.
Outro: Elixir Wizards is a production of SmartLogic. You can find us online at smartlogic. io, and we're at SmartLogic on Twitter. Don't forget to like, subscribe, and leave a review. This episode was produced and edited by Paloma Pechenik for SmartLogic. We'll see you next week for more as we branch out from Elixir.
Yair: Hey, this is Yair Flicker, president of SmartLogic, the company that brings you this podcast. SmartLogic is a consulting company that helps our clients accelerate the pace of their product development. We build custom software applications for our clients, typically using Phoenix and Elixir, Rails, React, and Flutter for mobile app development.
We're always happy to get acquainted even if there isn't an immediate need or opportunity. And, of course, referrals are always greatly appreciated. Please email contact@smartlogic.io to chat. Thanks, and have a great day!