Changing Languages

About this Episode

In this episode of the Acima Development Podcast, the panel delves into the topic of changing programming languages in applications. They reflect on their experiences transitioning between languages like COBOL, Perl, PHP, and Ruby, highlighting the complexities and costs associated with such endeavors. They stress the difficulty of converting large, established applications to new languages due to the potential for high costs and disruptions, as exemplified by legacy applications still running on COBOL.

A significant part of the discussion revolves around the value and challenges of rewriting applications in new languages. Will presents a strong argument against rewriting code, citing examples where organizations have suffered due to poorly executed language transitions. The group agrees that the decision to switch should be driven by practical needs, such as performance improvements, scalability, or security, rather than the whims of new leadership or a desire for modernization. They also emphasize the importance of mentoring junior developers and avoiding language specialization that can lead to organizational inflexibility.

The podcast concludes with reflections on the current trends and the future of programming languages, referencing the Stack Overflow Developer Survey. They note the rise of languages like Python and the enduring niche of Ruby. The hosts acknowledge that while modernizing or changing languages can sometimes be necessary, it should be approached with caution and clear rationale to avoid disrupting productive teams and established workflows. They suggest using opportunities like refactoring to evaluate and implement new languages gradually without jeopardizing existing systems.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting today. I have with me Matt, Justin, and Will. We're happy to have Justin with us. So, Justin and Will are not Acima employees. They have been in the past. And it's great to have both of them with us to provide their insight in their current endeavors. Great having you back here, Justin.

JUSTIN: No problem. And I do have to say that I went from one Utah startup that is an A startup with five letters to another Utah startup that was an A startup with five letters.

MIKE: [laughs]

JUSTIN: Both of which were acquired by big corporations and both of which have interesting relationships with the parent corporation.

[laughter]

MIKE: Does it --

WILL: I know, like, one guy at a startup number two. I'm very curious. I'm very curious. Like, you know what I mean, I'm always curious about like, you know, the hot goss which we won't get into.

MIKE: Exactly.

WILL: I went from a Utah retailer to a big box electronics retailer, that one [laughter]. And, you know, it's a different environment.

MIKE: Well, and this is perfect. But today we're going to...I'm just going to jump straight to the topic today. We're going to talk about changing languages in your apps. Now, this applies in, you know, languages that you're doing, but we all have applications that have been around for a while on some languages, and, eventually, that doesn't work very well anymore.

Now, there are still applications out there in COBOL. I don't think that anybody says, you know, "I want to create an application in COBOL," [laughter] because it's a language that hasn't been actually [laughs] developed for, like, what, 50 years or something [laughs]? I don't know. I have to go look at exactly how long it's been since COBOL was, you know, like, a popular language.

But you know what? There's still COBOL developers out there [laughs], and there's still COBOL applications out there. Because it is so hard to take a big working application and so expensive to convert that into a new language, which will itself eventually fall into disuse, and then you have to do it again. And, you know, the bigger the application, the more that costs.

MATT: ...Started my career.

MIKE: Did you? COBOL?

JUSTIN: COBOL?

MATT: Converting COBOL and FORTRAN applications to Perl and PHP web applications.

MIKE: Wow.

JUSTIN: Wow.

MIKE: To Perl. So, I wonder if that's happening. So, I was thinking about leading out...I thought, you know, I'm going to lead out with COBOL. But I thought about talking about my [laughs] first year as a professional developer, where I wrote in Perl, [laughs] right, you know, as well as other languages and, you know, comparing that. I'll say, I worked in Perl and then went away from it. I came back to Perl, and it was, like, starting from scratch [laughter]. It was a challenge.

MATT: I do still have some love for Perl, though.

MIKE: It's a cool language.

JUSTIN: [inaudible 03:24] as well on my first programming job, also.

MIKE: Oh.

JUSTIN: It was great.

MATT: PHP, not so much love, but...

JUSTIN: No, [inaudible 03:32] PHP.

WILL: I don't know, I like...like, Perl's, like, the Vi of, like, programming languages. I mean, like, in that, like, I could do it, but I never really got right with it. But I saw people who were, like, old, grizzled, wizard beards, sys admins just cooking on some, like, Perl scripts. And I was just like, okay, okay, like, this is, like...like, I'm seeing what's happening here, and I could recognize that, like, this is a power tool for, like, serious people to do serious work. This has utility.

MATT: You can accomplish a whole lot in Perl with very little code. It's the king of obfuscated code.

[laughter]

WILL: Ah, it is, yeah, yeah.

MIKE: Perl was the inspiration for the name of the Ruby programming language because they have a lot...

JUSTIN: Ooh.

MIKE: Yeah. Ruby would not be called Ruby if there had not been a Perl beforehand. But I got to say, when I started Ruby, it made sense, and that never went away [laughs]. Like, Ruby is like Perl, and it has still some weird Perlisms in it, if you go looking for them. It's like Perl intended to be easier to read.

WILL: Yeah, with an emphasis on sort of, like, readability, and, like, actually object orientation and stuff like that, yeah, completely. I got a hot take for this one, but I don't know whether anybody wants to get in here.

JUSTIN: So, I've got a hot take. I mean, I'm sure we all have hot takes for this one [laughs]. Why don't you go first? I have a good, lukewarm, and a bad experience, so three different experiences.

WILL: My hot take on, like, when should you rewrite your program in a new programming language is don't. Don't. I have seen...I don't even want to say 10 bad examples to 1 good example, you know what I mean? But I think it's actually even higher than that. And I have seen entire organizations, entire companies ruined with just this sort of thing. It's almost like an organizational anti-pattern, where you'll get some new hotshot CTO. He comes in. He has a tech stack that he favors. I say he; it could be a she, but it never is. It's always a dude with an ego and a tech stack, an area of expertise, a team of, like, people that he trusts.

JUSTIN: Yeah, and he brings --

WILL: And then, they come in like a bull in a China shop. They rewrite everything in their tech stack, bungle the job, screw up the product roadmap, and, like, take the entire organization down, you know what I mean? And then, he sails off in his golden parachute to do the exact same thing again. I recognize that, like, there are no such things as absolutes in engineering, but I am an overwhelming no. Absolutely no. Like, there's almost always ego, programmer laziness, and sloth.

I can't think of a language, a modern production language, that can't be reformed instead of replaced with 10 times less cost and a better outcome. Even PHP, which is a dog, gutter terrible language, has been remediated. It's fine. You can do PHP well now. You can do it, so do it. And, like, if you're a programmer that just doesn't want to learn another language, [inaudible 07:12]. Sorry. Like, I mean, it's laziness, sloth, and arrogance. Like, there's no...you know what I mean? Yeah, that's it. That's my hot take. Don't. If you want to do this, you're wrong. Don't do it.

MATT: So, you said a couple of things there. One, you used the word modern.

WILL: Yes. Important [inaudible 07:34].

MATT: I am wholeheartedly against the idea of modernization for the sake of modernization. If it's not broke, don't fix it. You know, we all face this. Everywhere we go, we face this, right? Some hot, new language comes into town these days. It's Node.

JUSTIN: Java.

MATT: And JavaScript backend.

MIKE: It's some new language that'll be transpiled into JavaScript. That's what it'll be [laughter].

MATT: Yes. Yes. And --

WILL: And has transpilers all the way down [laughs].

MATT: And everyone wants to jump on that bandwagon when they have a stable, expandable, scalable system.

JUSTIN: Okay, I've got one example where it worked, and that was in mobile, in the Android world. It was originally written in Java, and it still is in Java. About 2017, 2018, Kotlin came on the scene, and Google and JetBrains, no, IntelliJ, whatever, IntelliJ.

MIKE: JetBrains.

JUSTIN: They did it right. They were able to convert Java programmers over to Kotlin programmers. And they were able to convert codebases from Java to Kotlin with minimal issues. And it helped. I mean, there was a lot of things there about why it worked, but a couple of the main things that I could think of were that Kotlin, at the time, was just plain better than Java.

And then, two, Kotlin was compiled down into the JVM. And then, three, to convert a Java file to Kotlin, IntelliJ had a button that said, "Convert this Java file to Kotlin," and it converted it into working Kotlin. It may have been a little wordy, but it worked. And you can do that class by class. And it would work alongside the Java files and the Kotlin files. They would just work alongside. They were in the same codebase. And when you hit compile, it all worked.

MIKE: I've also seen a success story that's even different than that. It was a Java application. And this kind of goes back to Will's [laughs] saying before...the incoming people...it was an acquisition. The new people said, "You know what, we're not going to use Java anymore. We need to use a scripting language." And their preference was PHP. And this was a long time ago, but still [laughs].

WILL: Oh, man. Oh, oh.

MIKE: And I had been to a Java users' group where they had talked about Ruby on Rails and showed how, hey, you know, this is a, you know, a structured framework that is responsible and uses scripting language. You got to think about it. And so, I thought, you know what? This is old PHP, right? This is before all of those problems that you talked [laughs] about, Will, had been fixed. They were all still very much there. But I was like, you know, I like my life. I don't want it to go [laughter] in all sorts of bad directions.

So, I went, like, in a weekend, I learned Ruby, wrote a prototype for the new version of this, and said, "How about we try this? It's already starting to work," and got them on board with trying this other, you know, language: Ruby. And we converted over. We ended up with one-tenth of the lines of code and more features.

MATT: I've had similar success. And when I said that, I didn't mean you should never do this, right? Because there is a time and a place. And one of our successes was a big PHP monolith into Ruby, so much better, so much cleaner. But there was reasoning behind why it happened, you know, new lines of business. It was in healthcare. So, we now needed to support claims and imports from health plans, EDI imports, and, you know, all sorts of things that the old system didn't do. And it justified, hey, it's time to version this and roll out a new system.

WILL: But I want to...hang on, I want to get in here because I do take your point, Justin, and I agree. And I have experienced the same thing with sort of, like, legacy JavaScript stuff moving over to TypeScript. However, I don't think those are rewrites. Those aren't rewrites. And I don't actually think they're new languages. I think Kotlin is just JavaScript 2.0, you know what I mean?

JUSTIN: Java 2.0.

WILL: Yeah, Java 2.0. Similarly, like, TypeScript is JavaScript, like, 1.1, right? Where, like, you have...no, well, you have strong interop. You had the same project. You had the same codebase. And you're just sort of like, I know that they're different languages for, I think, mostly legal reasons, you know what I mean? Like, there's two big organizations butting heads, and like, so, like, the Kotlin people just forked it, you know? TypeScript is the de facto standard. Like, TypeScript took over JavaScript. Like, I don't even think they should call it TypeScript anymore because if you're writing JavaScript-JavaScript, like, you should stop [laughs].

But that's it. That's my point. Like, I agree, but I actually think it's more of a...that's more of an upgrade, you know what I mean? Like a major version upgrade of your programming language rather than, like, redoing it, you know what I mean? Subtle point, but yeah.

MATT: Now, there's ways also to approach this, right? You have a monolith. You decide you want to start extracting microservices. Perfect time. You know, maybe there's technologies that will support the job you're trying to accomplish better than what that monolith was written in for this particular task. And I think those things are super important, as well as how hard is it to find engineers for the languages you're supporting. That's a big one, right?

WILL: I think that's a mistake mostly in hiring, if I'm being direct. Being that, like...how do I put it? Like, I think if you're hiring engineers with language expertise, you're probably doing it wrong because I find, like, language expertise to be...for a good engineer, it's not that big of a deal. You're going to spend...it's a 10 to 1 ratio around learning the codebase, and the company, and the systems, and all that stuff, versus it's this much figuring out how things are done in Acima, and, like, this much learning Ruby. And Ruby is probably one of the hardest languages just because there's so much magic, you know what I mean, associated [crosstalk 14:30]

MATT: Yeah, I agree, when we're talking about senior engineers, right? I've always considered myself language agnostic because I don't care. I mean, I do care a little bit, right? I'm not going back to PHP. I'm just not. But when we're trying to mentor junior engineers, you're moving people over from other departments, that becomes a little more difficult, right? Because the learning curve is already pretty steep. When they start to get used to one language, to throw them into a new one, I think, provides more challenges.

WILL: Yeah, but they get more support.

MATT: Once you have some experience, absolutely, I agree, right?

WILL: I think it's more impactful on a junior engineer because it's like learning a different, like, human language, in that, like, you learn a different language, and you think in a different way, you know? You learn Ruby, and you think in a Ruby way. You learn JavaScript; you think in a JavaScript way. You learn nasty, old C, and you think, in, like, a different way, and you have a different perspective. I think for junior engineers, actually moving around in ecosystems is actually even more important because they'll learn better habits and they'll have more informed opinions.

I think when you have a junior engineer, God help them, right, that makes it through all the way through to senior without ever having sampled, you know, from a combo platter, that's when you get this sort of, like, senior people that are not language agnostic. And those are the people that come in because they don't know any better, and they're like, "This is all I'm good at. All I'm good at is .NET." So, you're a .NET shop now. And those people are dangerous.

MATT: Yeah, well, I agree with that. Point being, it becomes more difficult at that point, right? Because, as a company, we still have to focus on delivery, and it makes it harder to deliver. I agree. And we're all ADD, right? Every single engineer is ADD. We love to learn new things.

WILL: That's because engineering is boring [laughs].

MATT: We love to make things easier on us because we're lazy, and we're very inquisitive. So, we like to solve problems. I love learning new languages. It's one of my favorite things to do, just, you know, that exploration and experience of something new is awesome. But there are some challenges behind it.

JUSTIN: So, Will, you mentioned earlier about the refactoring. And, you know, Martin Fowler wrote the book on "Refactoring." One of the things I vaguely recall him talking about, when you are going in to refactor something, and that's basically what you're doing, is, when you're rewriting something in another language, you are deciding that you are going to refactor it, even if it is two totally different languages or as you say, Matt, like, you're changing...you got a monolith or something, and you have to break it apart. You have to identify the parts that you're going to move over to the new language and do that in an organized manner. And you have to be very cognizant and purposeful about what you are doing.

And those types of things mean that, I mean, help you, if you have to do this anyway, help you on your road to success. So, I don't know, big hot shot coming in and mandating stuff, sometimes you just have to go in and do what they say. And so, if you're going to do it, you might as well do it right. And that involves, you know, being an expert at refactoring and being very purposeful about it, so...

MIKE: You suggested something really interesting because if you extract out portions of an application by one, eventually, you know, you may end up with nothing of the original application because all the pieces have been extracted. So, you've refactored by breaking up into different services. And there was replacement, rather than rework, by extracting services. That's a way you can do this without actually rewriting the application, per se, so much as, hey, you know, this needs to be refactored enough. I'm going to rebuild this component. Once you've built enough components, eventually, the old codebase is gone. There's a kind of a strangulation technique, like a strangler fig. Eventually, the old --

JUSTIN: Yeah, yeah, exactly. And that's the example, the classic example, right? So...

WILL: Well, I mean, and I would also say, like, as I was thinking about it, like, I'm in JavaScript land now, right? And, like, one real serious problem with JavaScript land is framework fever. Man, like, that tribe of developers, they love a framework, God help them. And one thing that I encourage people who are, like, sort of, like, thinking about picking up a new framework to do is, if you want to grab a new framework, grab it as a refactor. Don't grab it for, like, the greenfield stuff. Grab it from, like, this old way, right, where, like, oh, I have this old thing. I'm going to refactor it using this new framework, this new idea, right?

Because what people will so frequently try and do is they'll so frequently try and do, like, okay, well, we're going to do a new thing. And I want to play with my new toys. And we'll do both of them together, which I think is an exponential increase in complexity. And it makes it very difficult to discern whether it was a good idea in the first place, right?

MATT: Yep. You understand what the problem is if you're doing an extraction, right?

WILL: Yeah.

MIKE: And you can A/B comparison.

WILL: Yeah. Like, is this better, or is it worse? And you can also, like, how do I put it? Like, a lot of times, especially with new frameworks, like, you'll have, like, you won't have a lot of the grime that real-world long-term requirements sets entail. You know, like, you'll do it, and you'll do the simple version, right? Versus, like, the actual reality of like, okay, this is a complex line of business app, and a lot of stakeholders have a lot of asks for it.

And you'll sort of, like, you'll skip over all that stuff, you know, and you'll do the tutorial, like, the demo version of something, where it's just like, it's not going to be that simple, and especially for, you know, new, fancy frameworks that haven't been, you know, road tested for a long period of time. Like, a lot of that stuff, like, start getting into the details of like, oh no, I need this. I need this. The security team needs this thing.

And like, well, no, I mean, like, the security team, like, often, they will have asks, like, specific asks about like, "Oh no, I need...anytime you read this thing, I need a log. I need a log of who, you know, even read this document," crazy stuff like that, which, like, well, no, for financial stuff, like, that's for real. Like, I need that. I need, you know, I need to encrypt all this stuff on the server, you know, for whatever thing. You know, all kinds of requirements where it's just like, oh, this is the new, hot JavaScript library. But, like, grimy old Java, or, you know, crusty Ruby on Rails, like, they had to fight these battles already.

MATT: Yeah, I don't like change for the sake of change. I always want to know why. Why do you want to switch everything to Node and TypeScript, right? Is it for performance? Is it for concurrency? I don't think so. But you know what I'm saying? I would like to know the reason for these changes because, oftentimes, people are misled by hype. And you're making change simply for the sake of change. And I don't think that's healthy for anyone, especially not a company whose financials are at risk, you know?

WILL: Okay, so let me ask the counter, right? When is it a good idea to change? Let's say I had, you know, like, kind of a core piece of the company that was written in a programming language that was, you know, like, modern. It was current, but it was, like, say it was something like Haskell, right, where it's difficult to write. It's difficult to hire for. It doesn't offer, like, meaningful performance enhancements, and, like, the team is sort of, like, notably unproductive, right? You know what I mean? Like, when is it worth investing in, like, moving away from the thing, right? It's like, oh, I have COBOL written in the 1950s. Okay, that's an easy layout. That's fine.

MATT: Sure.

WILL: But, like, when does it start to make sense? When is it okay?

MATT: I think you just gave the wise with your question, right? Engineers are really hard to find. Team is unproductive in that language. It's hard to support. You can't move engineers from other teams to go support it, those types of things, right?

JUSTIN: Also, it's like, if it's an older language, all of a sudden, the community is not updating it. You know, I'm putting my security hat on here. They're not updating it for security fixes that are on there and, you know, especially, I've seen that with older libraries that are included in whatever language, right? You're depended upon this library, and, all of a sudden, there's a security hole there, and the community has gone on from that library or that language.

MATT: Absolutely. We run into that all the time with gem support, right?

JUSTIN: Yeah.

MATT: You start using these gems, and, all of a sudden, there's no longer support. Nobody's doing security patches. They're not being updated. And now you're stuck. Either you have to take over support of that gem, write your own, build it into your codebase, or find something different.

MIKE: What if you have, like, a super performant Haskell team that's knocking it out of the park? They've got a good connection to the university. You've got, like, a pipeline of people coming in where you don't have a problem. That would change the parameters of the equation, right?

JUSTIN: Yeah, totally.

MATT: Absolutely. Absolutely.

WILL: If I walked into a high-performing team in, I mean, nearly any language, if they were writing COBOL but it was working, everything was clicking, you know what I mean, like, it wasn't just maintenance mode, it's like we are writing modern COBOL and everything is kicking butt, like, I wouldn't change a thing. [crosstalk 24:57] I mean, I don't have a problem with Haskell, you know what I mean? I actually like Haskell. I've never seen it productive in practice, you know?

MATT: Well, you could throw any language, right?

WILL: Like, one of my favorite languages, one of my favorite languages in the world is, I programmed in, like, five years, is OCaml, right? It's object-oriented ML. It's a very...It was like Haskell or like ML if they were, you know, it was designed by people who were trying to get things done. It's [inaudible 25:29] native. It's really fast. It's like, you know what I mean? And it's practical. Like, you can just sort of like...you can downshift and just do some imperative programming and just get it done if you need to. There's one and only one company in the world that uses OCaml.

MIKE: Jane Street Capital [laughs]?

WILL: Jane Street Capital. [inaudible 25:48]. OCaml wouldn't even exist outside of academia if it wasn't for Jane Street. But, like, it works. It works. Should anybody else use OCaml? Probably no. Like, I love it, but I would not advocate anybody to pick it up for anything, ever, you know.

MATT: You said something that I think is really important and that is, you wouldn't disrupt any team that is productive, just meshes, clicks, and gets things done, and meets business needs. However, we see it far too often. Back to your first example, some new hotshot comes in says, "Hey, we're going to start using this language. We're going to change everything. Turn your world upside down."

WILL: I'm a consultant. I will come in, and I will write this platform for you, but I'll only do it if you let me do it in Haskell.

[laughter]

JUSTIN: Well, going back to the situation I'm in right now –-

WILL: I might get emails for this. I know I am.

[laughter]

JUSTIN: So, the company I'm working for right now was acquired by a big bank, which is a Java shop, and they were acquired in 2023. They came in and dictated the Ruby application, which made the company, the startup company, the money, and made it all attractive; they dictated that, hey, this needs to be rewritten in Java.

MIKE: Oh wow.

JUSTIN: And they spent six months trying to do that. You know, there were zero Java engineers. And the big company did not want to give the resources or, you know, provide the expertise and the guidance and everything. Six months later, they said, "We're not doing it. You guys –- "

WILL: Who said it?

JUSTIN: The company, the smaller company that got acquired they, said, "If you want us to keep on making new features and everything and, you know, improving this product, we can't convert this to Java like you want us to. We got to stick on our platform that we want, I mean, that we're on, that we have the expertise on, that we have the, you know, the domain knowledge and everything." And, you know, so, basically, six months of development time went down the drain. Luckily, all that happened before I got there.

MIKE: [laughs].

WILL: That, like, I mean, so I guess the big question is, like, you know, what is the big bank going to do? I mean, because, like, you know what I mean? And so, the dangerous part about it is like, that's such a transparently bad idea, right?

JUSTIN: Yeah.

WILL: You've got technical requirements that, like, a Ruby on Rails application cannot achieve, right? Then, okay. But if you're just sort of, like, saying it just to say it, like, you are already making bad engineering decisions, right? And, like, are these guys going to be able to turn the corner and say, like, "Oh, I'm sorry. We were wrong"? You know what I mean? Like I said, risky thing to do. And if the big bank had the flexibility to say, like, "Okay, okay, okay, just do your thing then," I mean, [inaudible 28:56]. We all make mistakes. It takes a lot to learn from them. I'd say that's bleeding edge, big bank agility, and flexibility.

JUSTIN: It was, and they accepted it. And they said, "Okay, you guys can come in as you are." They have to come into the environment, right? And then, they were like, "Okay, if you come in, though, you do have to use our compliance framework and everything like that." And we have to add support for Ruby, which wasn't there before. And so, all of that is a pain, but it's all doable. And it's all fitting within the, you know, within the existing architecture, so...

WILL: And I'd say, well, I'd say, like, it's interesting to me, right? So, okay. So, let's get you in trouble at work, right? So, here's the question that I've got, right? So, all right. You've got Ruby on Rails app, you know what I mean? It is functioning. However, right, it's the odd man out. It's through an acquisition, and you're doing stuff differently from the rest of the bank, you know what I mean? Like, you know, it's an acquisition. It wasn't a merger. Like, Daddy is using Java, and you're using Ruby. And that means you are wrong, not them, right? Because you're swimming against the current, against this entire big bank, and it puts you on an island, right?

JUSTIN: It does.

WILL: And you're in Salt Lake City. You're not in New York. You're in Ruby. You're not in Java, right? Like, I think it is incumbent on sort of like, you know what I mean, like...and, like, there are advantages to it as well, you know what I mean? Because you want to be able to have this interoperability, this interactivity with the rest of the organization. Like, how do you, as the smaller party, how do you integrate into the larger thing?

JUSTIN: So, I'm glad you mentioned that because there is an initiative, and they have hired a few Java engineers to do microarchitecture, the microservice architecture. And so, they are moving over...I'm a little unclear if it's, like, net new or existing functionality, but they are going to be moving piece by piece things over to Java. But it is down low on the priority queue.

Our number one thing on the priority queue is, you know, continued growth, which is one of the reasons why the bank bought us. And the continued growth, and the new features, and everything there, all that, where we can serve our customers, is all still in Ruby. And so, it's a separate small team that are doing very clearly defined success story, you know, microarchitecture success goalposts that they could focus on. And then, they'll move piece by piece over to that. And, all of a sudden, our timeline actually went from, "Hey, you have to do this in the next six months," to, "Hey, you've got a couple of years."

WILL: Well, I mean, not for nothing. I actually, like, sort of, like, I don't know whether you guys are doing this at all, but, like, there is JRuby. There's JVM-compatible Ruby. Like, you can run in the JVM. The JVM can sort of, like, swallow you whole, like, with sort of, like, Java interop. And you can start, like, shading off routines, shading off business logic, you know what I mean? Like, I have moved away from JRuby because, like, it was kind of a lot of work to make it go.

I had an application that ran on JRuby in olden times because, like, the JVM had, like, kind of...I don't want to say the bad, old days of Ruby but, like, bad-er days of Ruby when, like, there were kind of memory stuff and scalability issues. Ruby's been working on it for a while, but, like, it was a hobbyist thing that kind of blew up. And there were funkiness. There was, you know what I mean, like, memory management, especially Ruby had some real issues, you know what I mean. And so, I was restarting a lot of servers a lot of the time.

MATT: It's funny [laughs] --

WILL: And so, JRuby is in there, you know, and you can have that call an in interop. You're not going to be able to just push a button and [laughs] convert the file. But, like, you can call...if you can get over to it, you can call Java, you know, from Ruby, you know, pretty sleek.

JUSTIN: I'll have to take a look at that.

MATT: It's funny --

WILL: Anyway [inaudible 33:19], sorry.

MATT: It's funny you say memory issues while talking about Ruby and Java is in the same sentence [laughs].

WILL: Well, I'm sorry, but, like, Java's [crosstalk 33:29] in ways that Ruby wasn't for a long time.

JUSTIN: Java has gotten a lot better over the last couple of years. And Java has almost, I mean, the last three years, Java looked at Kotlin and stole the best parts of Kotlin. And so, all of a sudden, Java's, you know, picked up a lot of the nice things that Kotlin had, especially, like, the functional programming idiom. A lot of the null pointer exceptions have gone away, things like that.

WILL: Did it get the coroutines? Did they pull the coroutines in?

JUSTIN: I'd have to take a look, so...But, in any case, it'll be interesting to see how it goes forward, but, you know, they are recognizing, like, even if they were to stay in Ruby, I mean, we're currently on a monolith, and so going in that direction anyway we're breaking apart the microservices because we're growing the teams. We're growing the engineering teams. It just makes a lot more sense. And so, it's a natural breaking point anyway that we can move forward to the parent org desired architecture, desired language.

MATT: Yeah, bottom line is we have to roll with the times, right? Unless we're the ones --

JUSTIN: That's very true. I'm glad you brought that up. It's like –-

MATT: And unless we're the ones making these decisions, then we have to adapt, and that's just the bottom line.

MIKE: If anybody is making the decision, though, don't go and destroy your teams and your precious goose that lays the golden egg. Don't do that [laughs].

WILL: Well, I mean, like, you know, it's the classic, like, you know, the classic, like, joke, right? I mean, the difference between a heart surgeon and a car mechanic is the heart surgeon works on a car while it's running, you know. And similarly, like, you know, if you want to be an engineer working on this enterprise stuff, making them enterprise bucks, you don't get to do it the easy way. You have to do it the hard way, where you can maintain the uptime and you maintain, like, continuity. And you're working on the engine as it's turning. I mean, sorry, you know, like you wanted the big check; go and earn it, you know? Like [laughs], stuff's hard.

And also, I'll say like, you know, I'll throw another bomb because, you know, I like stirring the pot. One of the more disastrous clinging to languages that I have seen has been in the Ruby community, where, like, people are trying to force Ruby onto, like, mobile apps, right? It's just not going to go. And some of that is not a technical thing, right? Like, it isn't that I don't think Ruby could make a perfectly, pleasant mobile application. It just won't be tolerated by the powers that be.

And sort of people are just like, well, we're a Ruby shop. We might be the developers and maintainers of Rails. And we're committed to Ruby in a way that, like, is maybe slightly personal. And so, we're going to try and force our way onto the iPhone. And it ain't going to go like that, you know? Write some Swift; write some Kotlin; write some JavaScript, you know. It's going to be all right, guys. Sorry [laughs], you know.

MIKE: Well, and [inaudible 36:46] example, you can back yourself into a corner. The recurring theme here is that, yeah, you got something new, build it in the language you want to do, the one that fits. Just don't destroy what you already have. But if you don't already have it, well, it's a really good time to reevaluate because those choices change over time [chuckles]. And, well, we're talking Ruby, so, you know, Ruby on Rails was really huge 20 years ago. Almost, not quite, but almost.

WILL: God, yeah, almost. No, no, you're right. No, that math is correct. You really bum me out, Mike. [laughter]

MATT: That really hurts.

MIKE: And it's still got a solid community. Like, I'm not saying that Rails is going away anytime soon, but Python has taken over a lot of that space as a very similar language. And --

WILL: You really don't need both, you know?

MIKE: Exactly. And so, you know, you've got to do some serious soul-searching. Maybe you've got some brilliant developers who are really good at what they're doing and, you know, stick with the language that works. But you better ask that question and think about how that question is going to be answered 5 years from now and ten years from now because you don't get that opportunity very often. Because once it's built, that's when you don't get to change it.

WILL: Yep. Yeah, absolutely.

JUSTIN: So, Stack Overflow, of course, does the Developer Survey every year. And so, there you can see the directionality of language usage. So, not necessarily that should make your decision for you, but it should be a consideration. And I'm looking here at Ruby. Let's see here. I'm trying to figure out.

WILL: Share your screen I want to see.

MIKE: Sorry, listeners, you don't get to see the screen.

WILL: I can Google this. I have the Google. Like, I got the whole internet. Stack Overflow. What was the search? Like, language survey, is that right?

JUSTIN: Developer Survey, yep.

WILL: Yeah, Developer Survey. All right, 2023, let's see it. Oh man, here I go. Oof, yep, I see it.

MATT: Python's, like, 30% right now.

WILL: Yeah, Python's, wow. Oof, goes bigger.

JUSTIN: So, here you have desired and admired. And I'm trying to think of...Rust is the most admired language, with more than 80% of developers want to use it and they want to use it again next year. Compare this to the least admired language, MATLAB [laughs]. I don't even know if MATLAB counts as a language.

WILL: It sadly does.

MIKE: It totally does. I've used...there's an open-source equivalent called Octave. I've used it before. It's actually very similar to the R language. Have you ever used R?

JUSTIN: Yeah, I have. But the thing is, I've only ever used that in college, so...

WILL: There's a lot of work that gets done, like, in MATLAB, like, big E engineering, like, type stuff, where you, like, do sort of, like, you know, anyway, yeah, it's a thing. It's a thing that does real work. It's for real.

JUSTIN: Yeah. So, the way I read this is admired versus desired. So, a good example here is Rust. 85% admire Rust, and they want to continue to use it, versus 30% of people who aren't using Rust want to use it. So, it's like, once you start using Rust, you love it. But if you aren't a Rust person, you don't even know what's going on here, 30%. This one here, JavaScript, this one's a really short bar, you know, 40% desire it, but of those who are using it, only 60% want to continue to use it, so...

WILL: I like the TypeScript one. That's the one I like. I'm looking at the same thing, right, where, like, people are just like, no, we really want to...Wait. So, desired versus admired, I'm curious. So, explain the difference between desire and admiration to me one more time because I think I missed something. I think I misinterpreted.

JUSTIN: Okay, so the question itself was, "Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?" So, you can answer twice, I guess.

WILL: Okay. So...

JUSTIN: So, which one are you using right now, and which one do you want to use next year? And then, they could be the same answer.

WILL: Okay, so what do you want...something that you want to try and people who want to keep using it. Is that admirable? Like, I tried it, and I liked it is admired. And I want to try it is desired. Is that right?

JUSTIN: So, desired is the second one. And admired means that you answered the same for both languages, I believe.

WILL: Wait, no, because, like, have used it and want to continue. Admired is have used it and want to continue. And then, desired is, want to use. So, like, I want to try it versus I've tried it, and I want to keep going. So, that makes sense to me for Rust because, like, I came up programming nasty, old C. And, like –-

JUSTIN: [laughs]

WILL: Yeah, you could do better. You could do better, and later they did. And, like, a lot of C developers, you know, really want to keep the good parts of it.

MATT: Look at that gap with Erlang.

WILL: Erlang. I'm looking --

JUSTIN: Erlang. Is it even on here?

MATT: Just scroll down, yeah. [crosstalk 42:14]

WILL: I see Elixir.

JUSTIN: So, the people who use it generally admire it, but the people who have never used it don't list it as something that they want to use.

MATT: And Elixir matches.

WILL: I'm looking at C++ and C, and I just don't understand...those don't make sense to me [laughs]. What? Like, I don't get it. Is it people who are like, I'd like to learn how to program in C, and, like, people who want to keep going? I'm unclear what this is because --

MATT: Those are your game programmers.

WILL: Okay.

JUSTIN: Is Unity in C, C#?

MATT: Unity is C#. C#. That is where I learned to write code in C# is because of Unity because I wanted to start building some games.

WILL: Interesting.

JUSTIN: Nice

WILL: I have never done any game programming. I feel like I'm the...well, not since I was in, like, high school, you know?

MATT: It's a lot of fun.

JUSTIN: So, unfortunately, I need to drop. But I suggest people take a look at this. I love this survey because it does help understand, like, here for web frameworks is, you know, the number one thing is React and then Node.js, Next.js, Vue.js. So, you mentioned earlier the JavaScript frameworks.

MATT: Think about those top three as you use them all three together.

JUSTIN: Yeah, you do use them all three together. And then, there's the folks who use Angular [laughs].

MATT: I felt really burned when I built out a huge application in Angular 1, and then [inaudible 43:56]

JUSTIN: Oh yeah, and then Angular 2 is like a whole new language [laughs].

MATT: Yep. Didn't even work.

JUSTIN: Didn't even work.

MIKE: Well, I think that we've reached a good kind of set of conclusions here, which is don't break it if you don't have to. But every time you refactor, which you should be doing, and you should be extracting things, it's a great opportunity to rethink what you're using today. And that's your opportunity. Use it while you have it. You know, it's don't miss the opportunity of a lifetime because you've missed the lifetime of the opportunity [laughs].

MATT: Yep. [inaudible 44:33]

JUSTIN: That's the first time I've heard that. I really like that.

WILL: I still feel like Ruby has enough of a critical mass to make it viable. I think the people who love Ruby really, really love Ruby. They're really good programmers. Like, almost all really good programmers I know that have tried Ruby are like, "Oh, I love Ruby. And, like, in the end, you know, I mean, like, and this is, like, purely personal bias, so I'm contradicting myself, like, rather severely, I know how to turn products around in Ruby really quickly, and if you can do it real fast, real well, you should not screw with it.

But, at the same time, like, I mean, like, everybody can see the direction the wind is blowing, and I wonder whether there's, like, an analogous, like, you know what I mean? I mean, like, what's the analogous, like, legacy language, you know what I mean, where it's like, it was good, and it had a hardcore community, but, like, we shouldn't have...like, what was it? Flash, you know what I mean? Like, can you compare it to Flash?

MIKE: I think Ruby is more like Perl, where it's really good at its niche, and, you know, 20 years from now, people will still be using it, but it's just going to get smaller and smaller and smaller, and you're just going to have...well, I actually saw, like, a comparison once for cars, comparing programming languages to cars. And they said Perl was like an old Volkswagen bus. And I think it was Ruby or Python, it doesn't matter, is like a minivan [laughs], you know? It's the same basic thing, right? It solves the same purpose, and it fits in the same niche. It's going to be the same thing. I think that there's a lot of equivalence there.

WILL: Yeah, I don't know, maybe I should learn Python, you know. Let's just switch over. I mean, it doesn't really matter. I mean, I don't know, I could [inaudible 46:34] really. I'm like, what's the difference between Python? Like, you've got, like, the significant white space, and, like, it's got...it's a little more typier. Is that right or wrong?

MIKE: It's not really even all that typier, no. It's just...so; Ruby leans heavy into, you know, its block. So, anonymous functions are, like, central to the way the language works. So, you don't have loops in Ruby, you know, people don't do loops. It's all built in the language. So, it's very functional in that respect. But Python has much less of a language. It's just much less language. Python just tries to be pseudocode written down as code. So, it doesn't have all of these cool features that you get in Ruby, but it gets the job done.

WILL: I don't know, maybe I should just do Kotlin, you know, just stinky, old Kotlin. Kotlin is fine. I've never done a web app in Kotlin. I just do, like, mobile apps. Anyway, sorry, a little bit of a tangent. We should wrap it up. You were trying to play us out, and I ruined it.

MIKE: I was, but there we are. And I'm with you. I love Ruby. And if it's working for you, keep using it by all means. I'm not pushing back against that. Think about your environment that you're in. Make your choice when you can.

WILL: But I've already abandoned them for, like, front-end stuff. Like, the way Rails is going with the frontend, I don't agree with it, and I don't have to use it, and I don't [laughs].

MATT: No, I'm not a fan of Rails frontend, personally, either. I love Ruby and Rails for APIs. You can work so quickly. It's nice. But is it the future? I guess we'll see.

WILL: No, it's, I mean --

MATT: I mean, that's not the future, is it?

WILL: But that's the reason I'm so frustrated with it because, like, they're just sort of like, they're sort of like, they're digging in their heels. And they're just saying like, the thing that we were doing in 2005 when we came out...anyway, sorry, tangent. We can fight about this next week, maaaybe.

MIKE: [laughs]

WILL: But nothing needs to be said. Like, everybody knows the score with Rails, you know?

MIKE: [inaudible 48:44] Thank you all, until next time on the Acima Development –

WILL: See you guys.

MATT: Thanks, guys.