MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be hosting again this week. We have with us: Matt, Eddy, Kyle, and Ramses. And I hope to hear lots from them today.


Our topic is going to be about the Ruby programming language and, specifically, why or why you might not want to use Ruby. This is maybe an interesting time to be talking about that. To give a little bit of history of the Ruby programming language, it's been around since 1995 or so. The creator goes by Matz. He's from Japan. And Ruby was very popular originally in Japan. It was one of the few languages that was documented well in Japanese and became extremely popular in Japan. It wasn't so very popular outside of Japan. I'll get to the moment that changed in a moment. 


Ruby is an interesting language. It was inspired by a couple of languages, in particular, maybe most pointedly Perl and Smalltalk. Perl being a scripting language primarily used in shell scripts but also used a lot in the early web, and that is wildly flexible. If anybody has ever used Perl, reading Perl code is not for the faint of heart, but it's exceptionally powerful. And the people who use it tend to love it. And that was a lot of the inspiration for Ruby. So Ruby is very good at text parsing and doing the kinds of things you'd want to run scripts in the shell for. 


Ruby was also heavily inspired by object-oriented languages, not necessarily the ones you might think of like Java, but Smalltalk, which is deeply, deeply object-oriented. Ruby is more object-oriented [laughs] than most object-oriented things in that it doesn't even have what you typically think of as primitives. You can call methods on integers. You can call methods on strings, their objects, just like anything else is an object. Really, anything is an object you can call. You can call methods on methods. [chuckles] It's deeply object-oriented. 


But, on the flip side, it's also a deeply functional language in that every line is an expression. And it borrows a lot from functional languages as well. You don't ever see for loops in Ruby because idiomatic Ruby doesn't use that kind of approach, that kind of procedural approach. We use iteration and pass anonymous functions. It's got a special syntax for anonymous functions. So it's both deeply functional and deeply object-oriented and very good at text parsing. It's kind of an interesting language that allows you to do a lot of different things rather than necessarily having one way to do everything. 


So that was around 1995, Ruby was created. About ten years later, in 2005, there was a big change in web development. There was a new framework that came out called Ruby on Rails. And, at the time, in web development (I was out there at the time. [chuckles]), web development was pretty clunky. There was a lot of boilerplate you had to set up. There was vast amounts of configuration files. 


In the Java world, you'd set up a lot of configuration in, like, XML files before you could do anything. In the other interpreted languages like PHP, there was...really kind of fast and loose. People would do a lot of things without much protection, and there were a lot of security problems. By default, there were a lot of problems with unsanitized database access. And as a result, there were a lot of security breaches. So over on the scripting side, a lot of mess, over on the kind of big enterprise side, very difficult to use. 


And Ruby on Rails came out, kind of bridging the world between those two. And it was written in a scripting language, giving you the ease of use of a scripting language and the quickness. Using an interpreted language, you tend to go faster with some of the structure that you'd get in the big enterprisey sort of frameworks. And it followed a lot of best practices, such as convention over configuration, so a lot of that boilerplate just went away. And it had a huge impact. Most of the web frameworks today are heavily inspired by Rails, even if they don't exactly follow what Rails did at the time. 


Now, we are getting close to 20 years after that, and, you know, the world has moved on. Ruby on Rails is still around, but it's no longer the, you know, the top dog. I did a little research this morning, and JavaScript frameworks have absolutely taken over both on the client side and on the server side. We've got a world where there are client-side frameworks like React that dominate. And on the server side, JavaScript has largely stepped up as well. The most popular server-side frameworks are also written in JavaScript, well, with Node.js. 


Python, which is a similar kind of language to Ruby, is also quite popular on the server side, and PHP is still kicking around too. You got frameworks like Laravel. The world has changed. Ruby on Rails inspired a lot of other frameworks, but itself has continued to evolve or maybe hasn't evolved as much as some of the others, which brings us to today. Our question is, why might you or might you not use Ruby today? 


I want to share one anecdote of when I started using Rails myself. I started using Rails in 2005, the year it came out in beta. I was a Java developer at the time. And I first saw a presentation at a Java users group about Ruby on Rails. And I thought, ah-ah, I could do any of that in Java. [laughs] I honestly wasn't very impressed when I first heard about it. 


And then, I got pressured by the company I was working at at the time to switch over to a scripting language. They were pushing for PHP. And I'd seen the kind of lack of structure at the time, and I was very resistant to kind of going into that Wild West that was out there at the time. But I thought, you know what? I'm going to try this new framework I heard about, Ruby on Rails. I learned the language and wrote a prototype over a weekend. I kind of devoted my weekend to it, which says something. 


I was able to learn the framework and write a prototype of the app we were in over the weekend. We built out that app. And within a few months, we had rewritten our primary app in 1/10th the lines of code. There was literally 1/10th of the lines of code, even as we'd continued to add features. So the application could do more with a tenth lines of code as we had in Java because it's so much terser, and so much boilerplate was removed. I was impressed and kind of in love, [laughs] to be honest. It was so nice. 


And I've been doing mostly Rails in the years since, and I've seen some good and bad. I can speak a lot to that. As to whether I'd start a new project in Rails today, I very well might. It'd depend on what I would do. If I wanted to do a very traditional web application, maybe with fast prototyping, I'd almost certainly go with Rails. If I wanted to do something new that had a heavy front end, I might use Rails on the back end because it's still a fantastic back end. But it's a good chance I'd use a JavaScript front end and not use what Rails provides for the front end. 


So if I were to share my opinion at a really high level of some things I might do, that's what I'd share. For anybody who's considering using Ruby, it's nice to know some of the history. I'm interested in what other people think about where Ruby and Rails are today (Rails has really dominated Ruby development since it came out) and whether or not you'd use it in a new project. Any thoughts, anyone?


EDDY: I went ahead and looked up at the top languages or stack of 2022. This one's particularly the most popular programming, scripting, and markup languages found from Stack Overflow. And to kind of reinforce what you were saying, JavaScript came in at 65%.


MIKE: Wow.


EDDY: Which is a huge chunk, right? And then dwindling down from that, you have HTML, CSS, SQL, Python, TypeScript, and all the way in the bottom 6% of those were Ruby. So it kind of just gives me the impression, you know, that the hype train for Ruby has dwindled quite a bit over the years. And this is just judging off of the 2022 statistics. It begs the question, I guess, the context being why or why not Ruby? Well, I guess you could debate, based off this chart, that for job security potential or stuff like that, maybe Ruby was not a bad choice. But, again, I guess it just depends on what you're really aiming for.


MIKE: Yeah, popularity is an interesting metric because if it's highly popular, there's probably a lot of jobs available. That doesn't necessarily mean those are the best-paying jobs. [laughs] Ruby developers have generally been relatively well paid, I think because they tend to be able to do more with less. You get a lot done; it makes you more valuable. But if you can't find any developers, well, then the company is not going to hire Ruby developers, and the market collapses, and then your value as a Ruby developer just disappears anyway. 


And there's a balance there, you know, 6% is still some. There's still a decent Ruby market out there. I mean, there's millions of websites out there. There are still large enterprise-y applications out there on Ruby on Rails, such as Shopify or GitHub. So, you know, there's still a vibrant Ruby ecosystem out there. But, to your point, 6% is not 60%. It's ten times smaller than the JavaScript world out there.


EDDY: I'm hoping you can kind of elaborate on that a little bit on why it's gone down. Is it just because it's an old language and, you know, loud voices get more attention? You know, so, like, JavaScript will get more popularity since you have different frameworks. Python and TypeScript is the new thing. So I'm just curious on, like, what has attributed to the popularity? 


MATT: Like Mike, you and I have a very similar past in our career path and the languages that we've written in. Engineers, in general, have a tendency to jump on the hype trains, and we see things that are new and shiny. And because of the way our minds work, we're very curious, so we like to try new things. That's one of the reasons I think that JavaScript has taken so much traction because, you know, we spent all of these years only using it on the front end. And now that we can use it on the back end, it's like, oh my gosh, I can use everything in my application in one language.


But, you know, you'll find that front end and back end are very different, especially if you're using TypeScript and things like that. I personally am not ready for the JavaScript back-end world. I don't feel like there's enough structure yet. There are a few frameworks, things like NestJs, that help with that. But just coming from someone who was strictly JavaScript, it makes codebases extremely hard to work in when people don't establish consistent patterns. And that's something that I really love about Rails.


You know, there are definitely different ways of doing things with Rails. However, I think, for the most part, you're going to find a handful of patterns that get followed. I don't mean structurally as far as your code organization and things like that, but I mean the way your code is written. Ruby and Rails are very, very easy to follow and, like Mike said, very fast, and you can get a lot done with very little. And for that reason, I absolutely would use Rails for a back-end system today. 


And again, like Mike said, I would use a JavaScript framework for the front end because you can definitely get more done that way. But that's kind of my opinion, you know, coming from, historically, I started out writing conversion code, converting COBOL scripts to Perl and PHP. Talk about a nightmare. And you really quickly see how loose and fast PHP could be as well. But, again, it was loose, and back then, everything was procedural. I think we yearn for some structure and some organization in our code.


MIKE: You know, you asked, Eddy, why people might be jumping on the new thing. I think that there is, you know, that hype that draws people. I think that's part of why people got on the Rails bandwagon in the first place as well, you know because you get some hype. People want to kind of be with the popular thing. And that's something hard to escape in human nature. But I think it's a bit more than that as well. 


But somewhat related, if you're going to be writing a big JavaScript front end, you're spending day in day out in JavaScript, and then you have to write a different language on the back end. That's a little challenging that you have to think in two different ways. If you can write in the same language on the front and the back end, you avoid some of that. 


Now, I agree with Matt that they're pretty different between the front and the back end. And the back-end frameworks are not the same as the front-end frameworks. My experience thus far has been, yeah, they don't provide as much structure as I would like to have. And they tend to degrade into a mess without a lot of diligence and care from the developers, which sometimes is hard to maintain over a large group of developers in the company. There's some risk there. 


But not having to change languages is a real bonus. And a lot of people have gone with that since JavaScript is the only option on the front end, and you're having to do JavaScript. People think, well, why not just also do JavaScript on the back end? You know, that's kind of a compelling argument, especially for a smaller application, a smaller back end. It's convincing to a lot of people.


There's also been the rise of Python, which is a similar language to Ruby. I'm not going to say they're identical. They have somewhat different takes on things, but they kind of fall into the same space. And Python has gotten very popular in the machine learning community, and where machine learning has been under such a big boom in the last few years. Now you have another language that a lot of people are using, and they don't necessarily want to learn something else to go into web development. 


So, if you're already doing a lot of machine learning, you're likely going to be using Python and using a Python framework, again, just so you don't have to have two different things that you're doing. And I think that there's a lot of that as well; people just want to use the same tool that they've been using. So, if you're doing a lot of heavy JavaScript front end, it's likely you're going to do some on the back end. If you're going to be doing a lot of heavy machine learning-type work, you're probably going to use Python because that's what you're already familiar with. 


Kyle, I'm interested from your perspective because you're over on the DevOps side, and you use a lot of different kinds of tools. And you've probably seen some of this, like, oh, I've gotten used to this tool, so I'm going to use more of it for this, or [chuckles] maybe you use so many tools that you're just, like, whatever fits in the moment.


KYLE: We're kind of a bit of a mix. We kind of started out as the team was growing. And I came with more of a Python background. My manager came with a Ruby background. And then my team lead; he had more of a Bash background for all the scripting that, you know, that we're doing. And that has kind of mixed as we've done things. And so when I've written monitoring tools, that's been in Python just because it's been familiar to me. And when backup jobs and stuff like that have been written, those have been in Bash because that's what was familiar to my team lead. 


However, a lot of the other stuff was by our manager, and he was familiar with Ruby. So him and I go back and forth on that because there is a little bit of a competition between Python and Ruby, just at least in our team and, you know, which one's the better language. It's mostly a joke than anything anymore because, well, I do like Python. And I could do the same things that I do in Ruby in Python. 


I've actually adopted and started writing a lot of our Terraform generators, is what we call them, using ERB just because the ERB option with Ruby is just so friendly to me, at least, to where I can just put a little bit of Ruby code into the ERB to help with the generation. And when I'm saying generation, we're creating little Ruby apps to generate our HCL code for our Terraform. We have quite a bit of that just to get our automation done. And that's just been easier to do than deviating to Python or something, as well as when we have been working with services in the teams because we do have Ruby developers here.


It's really nice in our environment because we do work cross-services; not all the services are on the same version. And it's RVM, I believe, just feels so fleshed out to me. It's just really easy to set up those virtual environments. And maybe it's just the way I use it, but I haven't had that ease of a virtual environment. With Python, I tend to have issues here and there. Whereas RVM, I've hardly ever had any issues. So that's been really nice on the Ruby perspective.


It's also been good...we have a tool called [inaudible 16:45], which is an internal tool which does wrap a lot of the more common CLIs like the AWS CLI and stuff. A proof of concept for that just to see how it'd work out that was written in Ruby, just because it was easier and faster to get it done. To solidify it to where it was, you know, cross-platform that ended up being written in Golang. But to get a proof of concept going Ruby is just really easy to kind of get those things done. It's really easy to get scripting, really easy to get templates going.


MIKE: And there are quite a few systems, DevOps tools that are written in Ruby. Are there not? You mentioned the ability to do ERB scripts with Terraform. And I haven't been much on the DevOps side for a long time. But I know that I will occasionally see this tool, like, oh, that's written in Ruby.


KYLE: You know, you say that, and nothing's coming to mind right now. I'm only thinking of the Python ones, but yeah, there are definitely some Ruby ones. I just have to think a bit harder.


MIKE: Yeah, I know that there are a few of them. And maybe they fall out of, again, with the hype cycle. Puppet is written in Chef or written in Ruby; it looks like. And it may have been slipping somewhat out of popularity. I'd have to go dig because I don't have a lot of expertise in there.


KYLE: Yeah. Puppet they have competition from other ones like Ansible, and Ansible is what we use.


MIKE: So that, yeah, that's interesting. So you end up using a lot of tools. You like Ruby, but there's other tools that can also get the job done. [laughs] And the best tool for the job, it sounds like.


MATT: I firmly believe that teams should use the best tool for the job. One of the things I forgot to mention, though, with Ruby and Rails is you can really ramp up new engineers very quickly with Ruby, and I found probably more quickly than with most other languages. If they have any experience in other languages and understand basic programming principles, Ruby is really easy to pick up.


MIKE: I think there's a lot of truth to that. I might ask Ramses. You've been doing software development for a few years now. [laughs] What are your thoughts about learning Ruby as a primary language? 


RAMSES: Yeah, I've been doing it full-time for almost a year. But then, outside of it, I guess, for almost two years now. Yeah, Ruby was mostly my first language. I've delved into some others, like JavaScript, of course, and Lua, and a few others. But, yeah, Ruby was...it's just easy to ramp up pretty quickly and cling on to, I think. It's easy to read, you know, which really helps in learning the language if you can understand it quickly, and you don't have to think about it too hard. 


MIKE: You say Ruby is easy to read. I think it's shockingly easy to read if you've been maybe working with another language for a while [chuckles]. Ruby lends itself to very friendly, almost human language-looking code, not in, like, a forced way. But it just...the idioms naturally flow such that it reads similar to human languages. And that means that your code ends up looking almost like documentation. And I think that has tremendous value.


MATT: It's the old joke that good code documents itself, right?


MIKE: Right. [laughs] And you say it's a joke, and it is a joke. Like, I don't need any comments. I don't need documentation. My code is great. Those are separate concerns. But the truth is, if you have code that is really easy to read, that has a huge influence on the ability of new developers to get up to speed. If you have very obscure code, you may end up having developers scrap it and start over again, even if the code was perfectly good, just because they can't understand it. 


And if you can't understand something, you can't adequately maintain it, or you're taking so much time understanding it that you might as well have rewritten it, to begin with, and no amount of documentation can really fix that. So using a language and even just paradigms—this applies beyond Ruby—writing in a style that lends itself to ease of reading is a big deal, in my opinion.


MATT: I 100% agree with that statement.


EDDY: The toughest part about being a new developer or your aspirations is, like, shifting your brain to think in a certain way. And if you pick up a language that has a daunting syntax, it's just really hard to wrap your head around everything else. So, if you pick up Ruby as an introduction to the language or to programming, I feel like it starts cultivating your brain in such a way that it gets easier to pivot to other languages once you get your thought process and your brain thinking that way, or at least it was for me anyways.


MIKE: I've actually read, not for programming languages but for natural languages, that there's been some research that says that learning a language that's easy for you it sometimes...and there's even, like, artificial language like Esperanto, which is sort of this made up language that's the generalized European language that's meant to be easy to pick up, easy to speak, and follow some loosely Latin roots to make it familiar to people with some European background. 


People who learn that language can then much more easily pick up their next natural language. So, if you are somebody who comes from a European language background, or Western language background, say English, and you want to learn something like Chinese, it can actually be faster to learn another European language like, say, Esperanto or Spanish, or French, you name it, first, and then learn Chinese. And you will actually learn, you know, you can go study Mandarin. 


You'll actually learn that second language faster than if you started with the second language to begin with. [laughs] That stepping stone actually does train your mind. And there's research behind it. You can look it up. I don't have the reference right in front of me, but I've absolutely seen that. I think that that's strongly backed up. That's a really interesting point.


EDDY: So, yes, so I would argue, yes, Ruby, for new developers. So for people who are aspiring but have no prior experience.


MIKE: And it's also interesting because Ruby will encourage you to kind of go functional light, [laughs] to start thinking about things in some at least moderately functional way, as well as learning object-oriented, kind of an object-oriented paradigm at the same time. So if you're going to move on and go into functional languages, or if you're going to go on and do object-oriented programming, you've already had a taste of it and will be well prepared and have your mind thinking about how to think about problems in that way. I don't know that I thought about that as an advantage of Ruby before. I'm glad you brought that up, Eddy. 


So we've talked a lot about kind of the utility of Ruby and where it's been good for us. Where are some places that you might not want to use Ruby? If you're going to take on a project, where would you say, no, I'm not going to use Ruby?


MATT: Personally, anything with machine learning, I would definitely go with Python, anything with a heavy CPU and, you know, file processing, things like that. And, historically, you know, I came from the healthcare world, and we used to have to process these enormous EDI files. And I did a test because, initially, we wrote these converters in Ruby. One of the files may take an hour to process in Ruby. I converted one of them to Python, and it took, I think, three minutes. So definitely anything that has to do a lot of heavy lifting and file parsing I would not use Ruby for.


MIKE: That's interesting. Were you using raw Ruby, or were you using some libraries? In particular, were you touching ActiveRecord at all?


MATT: No ActiveRecord. We did use some libraries that were a clone of some C libraries, but it just couldn't do the lifting like Python could. And, I mean, ultimately, C is probably the best answer. But there were very few people in the company who knew C. So we ended up converting to Python because some of us knew Python.


MIKE: Well, the interesting thing is that Python has a reputation as a slow language. And in some cases, Ruby is faster than Python. But, and here's the big caveat there, is there are libraries written in Ruby and in Python that are written in C. And so if you can exploit one of those libraries, you're just using a thin front end and a convenient language to use that really fast one. And it sounds to me like you were probably using some C code under the hood that was given to you by Python and --


MATT: Yes, yes. 


MIKE: So you really were using C, right? [laughs]


MATT: Yeah, but we just didn't have to write it in C.


MIKE: Yeah, exactly. [laughs] I used a library quite a few years ago, in Ruby, that was a clone of the searching library from Java, Lucene, that underlies, like, whatever everybody uses for search. I say everybody, but that's not quite true, but it's largely true. Lucene is used by Elasticsearch and Solr. And pretty much every search solution I've seen uses Lucene under the hood. Somebody cloned it in C and made it into a plugin that you could use in Ruby. 


And I used that in a tool that was called Ferret, I think. I used it a number of years ago. And it was so fast. It was so blindingly fast. It was wonderful and buggy. [laughs] And when we got some scale, it would just crash. So we had multiple parallel instances of it running, and the company I was working for was using it heavily. And we were growing really fast. 


And over the course of a couple of months, it went from failing, like, once a day to failing, like, once a minute, [laughs] and that was clearly unacceptable. So there are some downsides to having that C behind the scenes if you don't have very well-written C that is heavily exercised by a lot of people and well-tested.


EDDY: So I read a while back, and I don't know how true this is because I haven't had time to back-check. But, at one point, I believe Ruby on Rails was accused of being difficult to upscale. And I think that's part of the reason why Twitter moved away from that to Scala, I believe. And I think that's what the initial conversation that sparked the debate around Ruby on Rails scalability issues. So I'm just curious if anyone has any experience.


MIKE: I have been in multiple startups that have grown tremendously, you know, that same company I was telling about that grew. We were serving about half a billion requests per month for a while. There's certainly bigger, but we had a lot of traffic. I read some articles about this. But I don't think that that was really what Twitter's problem was. 


The problem was that they were using MySQL as a router, [laughs] and that aspect of the architecture was the key problem. And the language was largely irrelevant. And it was some fundamental architectural shifts, I think, that made the difference for them. I don't think that Scala is a bad choice. And I think that it probably made them somewhat faster in some regard. But I don't think that that was fundamental to their scalability issues. I think that it was something more fundamental architecturally.


Because, in modern web development, the way that you scale is you go out horizontally. And if you're using a somewhat slower tool, you can usually just scale out a little bit more and balance development costs versus server costs. And, oftentimes, the development costs are higher. So if you can make the development costs lower, you scale better, which is why people don't write all of their web code in C even though, technically, they could make it faster. 


You know, most of it's done in interpreted languages [laughs] because the developer cost is higher, and it works. It works just fine. They can scale out. I really think that that is a false argument, from my perspective, because it suggests that it's crashing to use an interpreted language. And if that was so, then why is 65% of the web development being done in JavaScript? It doesn't seem like it holds water to me. That's my opinion.


MATT: I think you hit the nail on the head. 


MIKE: To take that a little bit further, if the top languages are JavaScript, and Python, and PHP, [laughs] and that's what the modern web runs on, yeah, it blows that argument completely out of the water. Because, you know, Rails is a similar language, you know, it's an interpreted language. And they're all going to be, you know, approximately similar in performance. And you might get one that's twice as fast, maybe. But, in the end, that's just not going to make that much difference. 


Again, the development costs are going to dominate over your server costs unless you're, you know, Facebook or Google, in which case, yeah, you should be using some really powerful low-level tools. And that's really not...well, maybe that's another place you wouldn't want to start with, Ruby. But the truth is, yes, you would because if you're going to be starting your startup, you're not Google. You're not Twitter. You're not a huge company X. You're some much smaller company. 


And you want to be able to prototype and get to market quickly and be able to keep your development costs low. So you're not going to want to build all of the heavy web infrastructure to launch your tiny little site that supports one client to begin with. That would be a foolhardy way to approach your company.


MATT: I think that's a great point because when you are prototyping and trying to get to market quickly, you add a lot of tech debt, generally, right? Most initial applications are full of tech debt. And I think one of the nice things about Ruby and Rails is that refactors can go a lot more quickly than other languages. Extractions are pretty straightforward, for the most part. I think you're creating something that's going to be easier to manage and maintain until the necessity for something more powerful arises.


MIKE: Yeah. I think that's really well said. You're not going to scale to the size of the internet giants on your first platform. To your point about tech debt, what you build your first platform to do is not what your final platform is going to need to do. It's going to evolve over time. And I think you need to go in recognizing that that's the case. And maybe you'll be able to scale enough. And a tool like Rails or some of the other tools we've mentioned will scale enough. 


Facebook has managed to do with PHP, and it's pretty much worked for them. Certainly, it's not going to be PHP all the way down, but you can make those work for quite a long ways. And then, for the time when you get big enough, we'll then use the right tool for the job.


KYLE: From a performance perspective, having supported different languages, different applications written in different languages in a production environment, moreso thinking about in a Kubernetes environment, because that's what we use here, I would say that there was a bias, at least in my mind, around some of these languages, Ruby included, where it was one of those one to two ratios, meaning one CPU to two gigs of RAM to run any of these things in a stable manner. 


I wouldn't necessarily say that Ruby is the most lightweight. However, in the options that we've used here at this company, it does perform quite well. And scaling a Ruby application out with Kubernetes, meaning scaling it out with multiple pods, has been quite successful for us. So, like Mike was saying, maybe in a larger corporation where there is massive amount of traffic, Ruby wouldn't be the solution. However, from what I've seen with the traffic that we get, the Ruby apps do scale quite well, in my opinion.


MIKE: Spoken from a DevOps engineer there. [laughs] That's really interesting. Thanks, Kyle.


EDDY: Assuming that you do, in fact, decide, hey, I do want to build my website in the Ruby language, I was just curious to get the perspective of the group here on, like, why Rails is the top dollar when it comes to the framework. Because I know there's alternatives like Hanami, and Django, and stuff. But, like, what has set apart Rails that makes it that more important to use Ruby?


MIKE: There's always some advantage in numbers. So if you go with the more popular one, you're going to get all of the libraries available to use. You search on Stack Overflow, you're going to get your answers more easily than if you go out in another direction. On the flip side, if you have some strong architectural opinion, if you really disagree with some things that Rails is doing, then there are some alternative platforms out there.


And, a lot of times, you can even use some of the Rails stack. You can use ActiveRecord today, which is a powerful part of Rails, maybe the reason that they got adopted. And then you can still use that useful tool and put another stack on top of it. It may be more power to you, you know if that's something you really care about. It's going to be harder to find developers. It's going to be harder to find answers. You're kind of venturing off on your own. You're going off-road there, right? [laughs] But if that's something that you're comfortable with, then you can kind of become the vanguard, maybe even develop a following. It's a little riskier way to go. 


I might also say that Rails has some opinions that differ from the majority, particularly some of the decisions they've made recently around JavaScript. If you disagree with those opinions, then you might want to use something else so you have a tool that better aligns with the way you see the world.


MATT: I think that's a fair statement. We need to use the right tools for the job, and there are, I mean, there are so many options out there.


MIKE: There are. Rails still is the heavyweight in the Ruby community. If you want to stay in a language that's similar, you can always go with one of the Python frameworks. And they range from heavier like Django to some lighter-weight frameworks, Flask. Ruby has the same things as well. There's a popular lightweight framework called Sinatra, as well as some others. 


And I've written a Sinatra app before. And it was extremely successful. It was also an extremely small application, something that would work out well, probably in a lot of frameworks, something that might actually be a good fit for the JavaScript server-side, if that's the way you'd want to go.


MATT: Yeah. And there's been...Padrino is another option. And I think we've been talking a lot about Python. But things like Elixir, I think, are an easy transition as well if you want to go the functional route.


MIKE: Right. A lot of people get sold on the functional route. [laughs] 


MATT: It's true. 


MIKE: So, we've talked a bit about some good things about Ruby, some of the history, some reasons you might want to use it, as well as some places you might not want to use it. You might not want to use it [laughs] for doing any real heavy lifting on, you know, with file system or heavy CPU. You might not want to use it if that's not what the other people in your company are using. 


But if you want to get up a quick prototype, I think it's really hard to beat Ruby as a language and Rails as a stack or one of its competitors because it's just so easy to get started. And I'm happy to still be using it, although I do use other tools as well.


KYLE: One thing that I got thinking about was the community around Ruby, or maybe just the atmosphere. And I'm speaking to this from having worked with different languages different developers as well. And both points of view, I have to say that I don't know if it's just a mentality in the community or what it happens to be. But some of the more friendly, easy-going folks that I've ever worked with have been Ruby devs, as well having to dabble in and troubleshoot Ruby issues.


The extended community, be it on Stack Overflow or other forums and stuff like that...not that other languages don't have this too, but whenever there's assistance needed in the Ruby community, it seems to be very respectful and very helpful, which I don't always see in other languages.


MATT: That's a really great point. I didn't even think about that, but I agree. The culture is a bit different for Ruby shops than, you know, some of the others, say, here's the extreme, say, like, a .NET shop, right? It just feels like Ruby shops have a tendency to keep that startup mentality, even as they scale. And Acima is a great example of that. We have such a great culture at this company, and you just don't find that so much in some of the more structured Microsoft-type companies. So that was a very, very good point.


MIKE: There's an acronym that's used in the Ruby community we were talking about a little bit before we started our recording (MINASWAN); Matz is nice, so we are nice. Matz is the creator of Ruby. I don't know if it's a mantra, but it certainly is saying in a community that we should be nice like Ruby's creator. And I've definitely found that to be a case, in general, and found a very welcoming, caring community among Rubyists, which is great. And that's maybe a great place to close our session. Hopefully, this is useful to you if you're considering [laughs] whether to use Ruby for your next project. 


Thank you everybody who's been participating today: Matt, Eddy, Kyle, and Ramses. And thank you for listening to our session of the Acima Development Podcast. I'll catch you next time.