Runtime Arguments
Conversations about technology between two friends who disagree on plenty, and agree on plenty more.
Runtime Arguments
28: Don't let the language be the problem — let the problem be the problem
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
- Don't let the language be the problem — let the problem be the problem.
- You're not picking a language; you're picking an ecosystem.
- Boring is a feature.
- Resume-driven development is real, it's expensive, and everyone has done it at least once.
- Python is slow. But is your service slow? And is it slow because of Python?
- If your team is debating the language, you may not be debating the right thing.
- The language is not the product. The language is the tool.
- A model change costs 2–3× what a syntax change costs. Budget accordingly.
- COBOL processes $3 trillion a day. Nobody's talking about COBOL.
Hosts:
Jim McQuillan can be reached at jam@RuntimeArguments.fm
Wolf can be reached at wolf@RuntimeArguments.fm
Follow us on Mastodon: @RuntimeArguments@hachyderm.io
If you have feedback for us, please send it to feedback@RuntimeArguments.fm
Checkout our webpage at http://RuntimeArguments.fm
Theme music:
Dawn by nuer self, from the album Digital Sky
Alright, welcome to another episode of Runtime Arguments. Uh, this is episode 28, our 29th episode, and today we're going to be talking about, uh, choosing the right language. Uh, and I'm not talking about English or Spanish or… Hungarian, I'm talking about computer languages, because that's what we talk about here. So, how you doing, Wolf?
Wolf:I am doing great.
Jim McQuillan:Ah, that's nice to hear. I'm doing pretty well myself. Nice busy week.
Wolf:I'm glad to hear that.
Jim McQuillan:Um, uh, got a lot of work done. Uh, last week I, uh, went out to New York and visited a customer, and that was, uh, a great trip. Uh, really had a good time talking with them, keeping them happy, and uh, fortunately, they seem to be happy. Um, but then today, or this week, it was, you know, back to the… back to my desk, and getting some real work done. Um, what kind of things did you do this week, Wolf?
Wolf:Uh, well, first, oh my god, I had so many problems. We just had a new water system installed, like, we have well water, and it's the reverse osmosis thing.
Jim McQuillan:Ah.
Wolf:And it turns out they were just here. It turns out they forgot to flip a valve. So our water softener was bypassed completely. So what was coming out of our dishwashers looked like things you would find in a cave. And our electric kettle for the coffee started making horrible noises and, you know, it was awful. So that was bad. And I have internet at home. I work at home two days out of the week. My internet wasn't working, and of course, the first thing you blame when your eras have been rock solid for 5 years, or however long, the first thing you blame is your fiber that you've only had for 4 months. But no, it was not the fiber. It was, for the first time ever, it was my wireless mesh network. And when I called in to the guy. Um… He was a little snappy with me.
Jim McQuillan:The… the fiber guy, or the Eros guy?
Wolf:Um… I talked to the fiber guys for a long time, and they finally said, it seems like you probably need to talk to the Eero people.
Jim McQuillan:Okay.
Wolf:And the Aero thing was all messed up, because Amazon bought them, and that changed my account. But I talked to the…
Jim McQuillan:Oh.
Wolf:Eero guy.
Jim McQuillan:Yep.
Wolf:And first. um, we were talking for a little bit, or maybe I should say I was talking, I mean, you know me, and he said, well, I want to say some things, but I don't really have an opportunity to speak yet. Are you going to let me? And then at the very end of the conversation, once he had fixed my problems and everything was working. he admonished me. He said, so, that reset button on the bottom of your, uh, gateway, of your eero box? Don't press that. Wait until you talk to us and we tell you. Okay, you're now at the very last possibility. Push the button. Um… Uh, and coincidentally, my gateway has a brand new name that is unrelated to anything I ever picked.
Jim McQuillan:Wow. Well, that button should be labeled something like never push.
Wolf:Yeah, it should be.
Jim McQuillan:Of course, then you would just want nothing more than to push the button.
Wolf:Right, so that was the bad stuff and there was good stuff. We talked previously about competition for me, firearms, and I had some successes this week and I felt really good about that. I shot a really good time on something and it made me feel good. Ah, I think that's it. Until we get to feedback anyway.
Jim McQuillan:Cool. Cool. Cool. Well, yeah. Yeah. Okay. Uh, yeah, let's move on to feedback. Um, let's see. Our last episode was on SSH, right?
Wolf:It was.
Jim McQuillan:I think that was the last one, a couple of weeks ago, and we got some feedback from several people, and I'll just talk about two of them here. Marlon, our genius friend at Meta, he's the one that turned me on to SSH certificates, so I did talk about that during the episode. And, uh… We, I made a mention during that episode that, uh, that you are not Google, so maybe you don't need certificates. And, and he, uh, kindly pointed out that, uh, you know, you don't need to be Google to take advantage of some of those features like certificates. He said, any organization… you take an organization of 50 people, and you have an SSH key problem that you need to solve. Uh, where maybe installing keys on machines and the public keys on various machines in your network is not a great solution. And that's where SSH certificates really shine. So yeah, I don't want to turn people away from using those, because they are a very useful thing. In my little tiny world, I'm not using certificates because I've got a handful of boxes that I manage and only a couple of people that need access. So it's not something I really feel like going through the trouble of setting up. But for any organization of any size, certificates is probably a great solution for you. Um, the other piece of feedback I want to mention is, um, uh, during the episode, I talked about how easy it is to copy your public keys up to, uh, hosts, and I mentioned this command called, um, ssh-copy-id-gh. And that will go fetch your public keys from GitHub. And I use it, and I love it. Well, it turns out that's really only available on Ubuntu, and I think it's also available on Debian, but it's not in the Fedora Red Hat. world. There there is a package you can install, I encourage you to Google it. That command came from another command from canonical called SSH dash copy dash ID dash LP. And that last LP stands for Launchpad. Uh, you remember that was, uh, Canonical's, um, project hosting site. Uh, so anyway, I, I think that's it for the feedback. Uh, any, any other feedback I'm missing?
Wolf:For you. Umm.
Jim McQuillan:Yeah.
Wolf:Did that, um, uh, question about the key installer thing come from, uh, DaveMQ? He's been giving some feedback, um…
Jim McQuillan:There was two people that sent us several different things, and it might have been Dave.
Wolf:Uh, yeah, I've been pleased that we've been getting, uh, people interested in talking about stuff, so that was interesting. I have, um… one really important piece of feedback, and that is this. I'm a pretty, uh… Well, you know, no matter what age you are, you never think of yourself as old. Old people are the ones who are driving slower than you. Um… Uh, but I've been alive for a long time, and as you grow in time, your collection of friends change. And I just wanted to point out that, um… When I was a very, very young man, and I mean in my teens, uh, things were kind of hard for me, and I had a very, very close friend, my very best friend. Uh, whose name is Tony Stearns, Anthony Stearns. Uh, he is now a PhD, Dr. Tone, I think is what his license plate says. But he, um… He. is more than a best friend to me. He's a brother. And his parents, uh, who are both still alive. are, um. more parents to me than any other people have ever been. Um, I love them with all my heart, and um… Tony actually called me up and gave me some feedback. Because normally we start off an episode and I'll say blah, blah, blah and my best friend Jim. And I'm absolutely not taking that back. You are my best friend. That's how it works. Uh, but that does not lessen Tony's position in the world, nor that of his parents. He is a brother to me, uh, he, uh, counted… I would have counted him as my best friend for decades, um, and I would not be the person I am. uh, without him, so I wanted to make sure he got credit and didn't feel like I was somehow slighting him. That is the weird, non-on-topic, uh, feedback that I have for today's show.
Jim McQuillan:Well, that's good. That's good. You've mentioned Tony a couple of times, and I'd like to meet him sometime. Where is he, down in Ohio?
Wolf:Yeah, he lives… well, I actually don't know if he lives directly in Akron, but, um, that's where we grew up together, in Akron, Ohio, where they just had a plane crash, by the way, into a house.
Jim McQuillan:Okay. Yah.
Wolf:Yeah?
Jim McQuillan:Oh! Is that the one that ended up in some guy's bathroom?
Wolf:I, I don't remember. The, the guy and his two kids got out, uh, but the pilot and passenger of the small plane, I'm very, very sorry to say, uh, did not survive. So…
Jim McQuillan:Haha, yeah. Ah, that's too bad.
Wolf:It was a very unfortunate situation.
Jim McQuillan:Well, you know, I think now is the time to get into this conversation we're going to have on choosing the right language. So, Wolf, I know you have lots to say about languages, and I've always enjoyed our talks at lunch. Uh, where we get into languages. And, uh, and that's one of the topics where you… you get animated.
Wolf:Is there a topic where I don't?
Jim McQuillan:Well, yeah, you're right. But but some topics you you just come alive. And this is maybe the most of that. And so I've been looking forward to this conversation for a while. because it's, uh, it's interesting to me, and I know it's very interesting to you, and I hope, I hope at least one listener out there, uh, finds it interesting. Uh, but yeah, let's get going.
Wolf:Uh, okay. The first thing I want to say before I say anything else is that, you know, like your editor, like your car, like a table saw, like a pencil. Languages are a tool. Um, maybe you're one of those people who loves fountain pens, and to you, a fountain pen is more than a tool. Maybe languages are that way for you, too. If that's the way it is. probably you're not gonna enjoy the rest of this conversation, because this is about choosing, and if you have a favorite fountain pen, you've already chosen. Um… I… I'm gonna say one thing up front, and then I'm gonna ask you a question, Jim. Here's the thing I'm gonna say up front. Do not. Let the language… be the problem. Let the problem be the problem. Pick the boring answer. The language… Uh, the team knows, with the ecosystem that fits your problem domain, uh, that lets you write working, correct, efficient, enough. software without the language itself becoming a source of friction. That's… that's the why. That's the main thing. Do that. Uh, if you don't get anything else out of this, get that. Uh, you want the boring answer. Um, so… Forget theory. Here's my question for you, before we do anything. Have you ever been in a conversation.
Jim McQuillan:Yep.
Wolf:where someone was arguing for a specific language. And you instantly knew that the reason they were giving wasn't their real reason.
Jim McQuillan:You know, thinking back, I don't know, I don't get into a lot of those kinds of conversations, because for almost my entire career, I've been the one that's choosing the language. So… So, people don't come up to me, especially at work, and say, you know, Jim, I'm thinking about using this other language. Um, it just doesn't happen. I pretty much… I'm a dictator.
Wolf:I hear ya. Well, I work in a much, much bigger team. At my current job, there's not really a question about languages. I mean, occasionally there is. Like, we have a language that we use. At my job, we're basically a Python shop. Uh, because we're doing a bunch of information theory stuff. And, um, the tools that we have have great, uh, Python interfaces. occasionally, there'll be a place where you didn't have the library that did the work really, really fast. Uh, like, for instance, if you're using Python, and it's appropriate, maybe you'll use NumPy, or Pandas, or something like that, and it turns out that inside those things. The real work is being done in C. They're fast. Everything's great. So it's rare that you're using Python, and in the place where you're using Python, it's too slow. Because all the places where it could have been too slow are already in C.
Jim McQuillan:Sure.
Wolf:Because you're using the right libraries. But every once in a while, and I'll admit, it's me, somebody will say, well, here's a part that we could speed up. But we better measure it first. And a way to speed it up is, we could write this tiny part of it in Rust. Is Rust the best language to write it in? I don't know. Um, and so far, it hasn't been the case that any measurements have proven that would be a good use of time. So we didn't do it. Um, but that's a thing. And… If I were arguing for rust there. Would I be? arguing that Rust was the right language? Or would I be arguing that Rust is a thing I want on my resume? But telling you it's the right language.
Jim McQuillan:Ulterior motive.
Wolf:Oh. Yeah, so I'm using myself as an example. I think I'm arguing for the right reason. Um, I don't think anybody even reads resumes, so I can't imagine having something on my resume and caring what it was, but uh… The point is, yes. I believe that in a world where there's enough people that there might be possible other choices for languages, people will not argue in good faith. They will argue for their favorite, and then a justification. They will argue for the thing they want on their resume, and then pick a justification.
Jim McQuillan:Sure.
Wolf:Um, so, what we're gonna do today is we're gonna talk about when you don't get to pick. When you DO get to pick. How to think about the costs, and we're gonna talk about specific problem domains, uh, math, finance, web, games, uh, maybe a couple others. Um, so… Let's do the easy cases, because, uh, we can just get them out of the way. I kinda like to do the easy cases first. Sometimes, you don't get to pick. Ah. you don't get to pick if the platform forces you. If you're writing an iOS app. it's pretty much gonna be Swift. I mean, you know, you could use Objective-C. But not really, right? Um, if you're going to write an Android app. It's going to be Kotlin. You could do it in Java, but not really. Um, if you're going to write a web front-end. Sure, there's stuff you can do, but if you do the boring, safe, easy, low-friction thing, it's gonna be JavaScript. Maybe TypeScript. If you are going to do some shader programming because you're doing interesting graphics or games or whatever, it's going to be GLSL, HLSL, Metal. You're definitely not going to use Python in your GPU. If you're writing a WordPress plugin. Alright. It's gonna be PHP!
Jim McQuillan:Right, right.
Wolf:You don't really get a choice in any of those cases. So that's about the platform. Now, there's the situation you just described to me. organizational forcing factors. Um, we're a Java shop, we're a Perl shop, we're a blah blah blah. Um, if you already have, um, 15 years of Java libraries, and a team of 20 Java engineers.
Jim McQuillan:U-huh.
Wolf:your choice is made. I don't care if you think your choice isn't made, your choice is made.
Jim McQuillan:Sure.
Wolf:Um… Another one. Legal requires our India office to be able to review all code, and they only know C-sharp. Well. I mean… That's your lawyers and a shop you have zero control over. So you got to do it. So it's going to be C sharp. Or the CTO makes a decision. and I'm not gonna say whether CTOs are right or wrong or smart or anything like that, but if your CTO says, we're a go shop. You're going to write stuff in Go. I don't care how much you like Haskell. I don't care how much you like Python. I don't care how much you like Ruby. I don't care what. Um, if your CTO says go… It's Go. It's Go, or you're gonna write in some other language. at some other company.
Jim McQuillan:Umm.
Wolf:That's my feeling. So… The key rule is that these forcing factors are decisive only when the preselected language can actually solve the problem. If you're a Java shop, and you need to build an ML training pipeline, because machine learning is important to you solving the job. Well, now we're going to have a conversation. Um… So, in infrastructure and operations, this is my question to you, Jim. Are there forcing factor equivalents? Your job is a lot about the specific kind of application you work, which is mostly medical records. But you are the guy who is doing, um… uh, infrastructure and operations. Uh, you're the one making the Docker containers and running the, uh, uh, cloud hosts and. and whatnot. And, you know, if there's Lambda functions, who knows? What? are the places where the thing you're using decides the language for you.
Jim McQuillan:I'm… I'm not really sure how to answer that. I mean, obviously, we use a lot of… a lot of Bash, uh, some Pearl, um… You know, when you're, when you're deploying systems, um, and using Docker and stuff, it's not a lot of language programming stuff. It's like YAML files, you know, configuration things, um, a, a Docker. config file. Um… I don't know if that's answering your question, though.
Wolf:Yeah, it's like when people do those interviews, and the person they're interviewing answers their question with. Yes. That's a very hard interview. You are making this a very hard conversation. I will say this though, I'll bet you it is unreasonable to write an AWS Lambda function in Perl.
Jim McQuillan:Yeah. Yeah. Yeah, yeah. Uh, you know, Lambda function is probably gonna be Python. Uh, I think they support… I'm not writing those kinds of functions, but I have looked at it. But, you know, it's gonna be JavaScript or Python or something like that. Um, I don't even think it's going to be bash, would it? I don't know. But.
Wolf:All right.
Jim McQuillan:I don't know.
Wolf:Let's talk about the hidden agenda. Um… This is the part that nobody wants to say out loud, and that is, um… The real reasons people will fight for specific languages? that either they're… they don't know this is why they're doing it, they just think it's better, uh, and they come up with reasons, or else they're ashamed of their reasons. I don't think it's that very often. I think, uh… engineers are way more ignorant about some things than they want to be and don't even realize the things they don't know. But I'm going to talk about a couple of things. Like we already mentioned resume driven development. Sometimes when somebody says let's use Rust. That means I've been watching Rust for six months now and I want it on my resume. Let's rewrite it in Go. Sometimes means I'm bored and I want to learn something. The technical justifications get constructed in Rust. after they decide what they like. And, uh, you can usually tell, because the justification is unusually, um… airtight and the person's eyes light up when they talk about it.
Jim McQuillan:Okay.
Wolf:Like I kind of get excited about tools. But it's not like, well, go ahead.
Jim McQuillan:Okay, when you talk about Python… Your eyes light up.
Wolf:But I have talked about other languages when I'm solving other kinds of problems.
Jim McQuillan:Yeah, yeah.
Wolf:I do, and I will say right now, the thing that I say when I tell people about Python.
Jim McQuillan:Yep.
Wolf:And that is this. It is un… it's unrelated to the problem you're solving, uh, because Python is either good for that, or bad for that, or whatever. But I have told people, and I will say it again, and I will say it in the future. Coming into work. to work on Python. is like arriving and getting to pet a puppy.
Jim McQuillan:See, your eyes are lit up right now.
Wolf:It just… It just gives you endorphins. Okay, so then there's the opposite of resume-driven development, and that is people who say, well, let's just.
Jim McQuillan:Yeah.
Wolf:Sometimes genuine conservative conservatism and sometimes it's just laziness. You know, if you're a Java shop, maybe Java just isn't the right tool anymore? But you know Java, and you invested so much time in learning Java, and you have answers for Java. It could be right, and maybe you're on the right side, but maybe, maybe you're just being lazy.
Jim McQuillan:You know, substitute the word Java for COBOL.
Wolf:Then there's…
Jim McQuillan:you know, basically go back 20 years, right? And COBOL programmers are like that. I programmed in COBOL for years and years. I probably wrote a million lines of COBOL. Only I always looked at COBOL as something I don't want to keep doing. I was always looking for something better.
Wolf:Uh-huh.
Jim McQuillan:But an awful lot of people in the COBOL world. That's what they know, and they are not interested in… anything else. And, and, you know, the…
Wolf:And their investment finally paid off!
Jim McQuillan:And you know, the kinds of problems you can solve with COBOL…
Wolf:Beef.
Jim McQuillan:are quite limited to business applications, uh, working with fixed-length records, and that's kind of it. And that's… I knew I had to get out of that, because, uh, because that was… that was a dead end.
Wolf:Yes. Yeah, I hear you. Um… Then there is the ideological camp. Uh, which is, uh, some engineers have strong feelings about. Object oriented versus functional dynamic versus static compiled versus interpreted sometimes they have real good reasons, this is like everything every every single thing I talk about in this in this episode is. In the gray area, like. It could be reasonable, true, and right, or it could be somebody's opinion. So there are people who believe these things, and sometimes for good reasons, and sometimes they're just. part of a tribe. They're part of the object-oriented tribe, and they want all answers to be object-oriented. And if it's gonna be object-oriented, well, goddammit, let's use Ruby, because Ruby's the only actual object-oriented language that there is. Right? Because 1 is an object, and you can say 1.times, and then give it a block, and it will do that block 1 times. Or 10 times, or whatever number you say. Is that good? Maybe. I don't know. It depends on your problem. But you want to find out the real reasons that people are putting behind their arguments. If you skip it. Umm. It's not going to be an honest conversation. Um, yeah. Remember what I said first. The only thing I wanted you to remember is don't let the language be the problem. Let the problem be the problem.
Jim McQuillan:Right.
Wolf:That's the thing. Um, so… And you're just going to answer to this, no, or yes, because that's how this conversation is going. But what is the tell for you? I guess you do see this at lunch. When people are talking about languages they want to use and why, what is the tell for you? How do you recognize when someone's arguing from desire for a language? Rather than from the problem.
Jim McQuillan:Wow. I don't know. I see, you know, when their eyes light up, I know they're passionate about it, but is it the right language? I don't know. You know, I… we sit at lunch, and one of the guys uses Go a lot, and that seems like a great language for what he's doing. You certainly are into Python.
Wolf:And he's super smart, like you would expect that guy to make super smart decisions.
Jim McQuillan:He is! So… so… Yeah, right. So when I hear him talk, I'm not making a judgment about whether Go is the right language for him or not. To me, it sounds like the perfect language for him. It's what his company is using, it's what he's good at, so… so, you know, he's not even arguing that it's a good language or not. It's the language they use, and it's… And it's great. You know, I see you advocate for Python quite a bit. More now, you're talking about Rust. Um… But, um…
Wolf:And I was a C++ language lawyer. I used that for 10 years. I used to write in Pascal and…
Jim McQuillan:Oh yeah, yeah, yeah. I mean, I've known you, yeah, I've known you since you were doing C++. And one thing I'll say about you, you get into a language, you don't go halfway.
Wolf:I… I was just saying to my boss, um, that I have discovered about myself that, um, I like to be, um… I think I used maybe the wrong word, I said superlative. Um. I don't just want to learn something. I want to be, I'm going to use your words. I want to be the guy.
Jim McQuillan:Yeah. Right. I'm probably going off on a tangent here, but among my friends, it seems like all of my friends are like that. You know, the way you are, you want to know everything you can know about Python and be the best you can at it. And I've seen you learning Rust. and taking the same attitude. And, you know, my friend Scotty, he's more of a sysadmin, but he can program and stuff, and the comment I've said about him is he never half-asses anything. He whole asses it when he gets into something. Right? But that's you with Python. That's how my friends are. I surround myself with people like that. So I don't know that I see people arguing for a language that maybe isn't the right one. Umm… It's the right one for them. You know, among the people I hang around with.
Wolf:I'm gonna say something really weird, and I don't know if I can connect it, but, um… I interviewed at a company, gosh, I don't know, a decade or two ago, I can't remember. And they gave me a take-home test? Or something? Like, write a piece of code that does this thing.
Jim McQuillan:Oh.
Wolf:And there was a long pause. You know, I assumed they were done. But they weren't done. They said, and write it in racket. And I'm like, okay, well, I never heard of Racket. I later learned a bunch of stuff about Racket, and that was a totally different way of thinking about programming. And it was very interesting for me. I was not offered that position because I did not write enough tests. Um, I wrote tests, they never said the word tests in the interview, but I still wrote tests, because I believe in tests, even back then.
Jim McQuillan:Sure.
Wolf:But I didn't write enough, according to them, so it didn't work out.
Jim McQuillan:Sure. Sure, but you know what's… you know what's neat about that? You said… I've never seen the language. I've certainly heard of it. Um, but what you said, it's a totally different way of thinking. You do a language like that, and it allows you to think differently, doesn't it?
Wolf:It does. And it's not like it replaces what you know, it expands what you know. It gives you a bigger vocabulary to think about problems. And once you understand how some other language.
Jim McQuillan:Yeah.
Wolf:thinks about, represents, models these other problems. Now, when you're faced with some problem, and it doesn't even have to be that problem, when you're faced with some problem, you can think to yourself. Gosh, you know what? Um… This would be a really good place to use a functional language, because the way functional languages think about X. really applies to this situation, or this seems like a place where I want to use an object-oriented language, or anything like that. The bigger your vocabulary. the more precisely you can identify what the problem is. And here's my interesting little, um… Ahhhh… I forget the word when you encounter something that is the opposite of what you expect it to be. But…
Jim McQuillan:Counterintuitive.
Wolf:Poetry and sketches and sculpture and paintings. Every one of those things is not about making a photograph, or uh… anything like that. They're about expressing the essence of something. with significantly less information. A great artist can write in a short poem something that brings out deep emotions in you that took a lifetime. For you to build. It's only because you met this particular significant other, and you spent decades together, and you have feelings for that person that give you the power to understand what that poet wrote in four lines. But it only took 4 lines. And why did it only take 4 lines? Because that person, the poet, the person who wrote it. has, um… And not just the vocabulary of words, but the vocabulary of experiences and thinking. To understand deeply enough the thing they're trying to describe. The better you know the world. The better you know your problem, the better you know the languages. The more easily. the more succinctly and the more clearly you can express it. I just think that's. Very interesting to me. Anyway, uh… So… we're getting to the really important parts. Uh, and one of the really important parts is that the language is actually. The tail of the dog. and you can't let the tail wag the dog. The big part, the dog. is the ecosystem for the language. It's…
Jim McQuillan:You know, it's… I don't mean to interrupt here, but you're talking about dogs, and I can hear your dog right now.
Wolf:I love my dogs so much.
Jim McQuillan:Yeah, your dog is barking.
Wolf:Yes. I have three. For those of you who are listening and don't know me, I have one really barky dog, one dog who will bark because she just wants to go along with it, and one dog who is interested in whatever they're barking at but doesn't make a sound. Uh, that's kind of a good combination.
Jim McQuillan:Yeah, now he… now the dog knows we're talking about him.
Wolf:Kind of nuts. Um, so, um… You need to know, when you are about to work on a problem, not just the language. But it's dominant libraries for your domain. Um… Is your problem a problem that's gonna be solved locally, on the machine in front of the customer, or you, or whoever's gonna use it? Or is it gonna be on a server? Or is it gonna be both? Um, does it need a database? What kind of database? A relational database? A document database? Key value? Graph? Vector? Is it a stateful application? Stateless? Um, are you gonna work on one… thing at a time, whatever that thing is, or lots. What's the concurrency model? Are you gonna be doing a billion things at once? Um, how? You need to know all of those things, and uh… once you understand. what those things are, what the constraints of your problem are, they're going to lead you down particular paths. They're going to focus the probability on specific items. For instance, when somebody says. Python for machine learning. They're not just talking about Python. They're talking about Python, and NumPy, and SciPy, and Pandas, and Jupyter, and PyTorch, and TensorFlow. Um, the ecosystem of libraries around it. And what they're going to do, and the kind of math that you're going to need. is inseparable from the language choice. You care about all of those things. And then you care about if you're building a model, because you're doing machine learning, how are you going to do the training? Where are you? Like, it's a big problem. You need to think about the whole problem. Um, the framework, uh, for your web app. Are you gonna use Node.js? Are you gonna, uh, use Express, or Fastify, or Nest, or… So. Back to you, Jim. Here's another question for you to give me a yes or no answer to. When you look at a piece of infrastructure tooling, or something you're actually going to use. maybe the web, maybe something that you're gonna build into an iOS app, who knows?
Jim McQuillan:Umm.
Wolf:Umm. is the language. Ever. The primary thing you're looking at or is it always the ecosystem?
Jim McQuillan:Well, it's the system. Uh, certainly the language has to be a part of the decision, but, you know, I do back-end server stuff, I do front-end stuff, I do Xcode, iOS stuff. Um. And. You know, you choose the language that's appropriate to that. I don't know. Is that. My answers are not great for your questions.
Wolf:It's better than yes.
Jim McQuillan:Yeah.
Wolf:Umm.
Jim McQuillan:Yeah.
Wolf:I think my point is, and I think your answer backs it up, that, sure, the language is a part of the solution, a part of the choice, but it's not the biggest part. It's fundamental. It's important. But there's… there's more.
Jim McQuillan:Yeah, it's, you know, first and foremost is what is the problem you're trying to solve? You know, uh, uh, we, we talked about this before. People come to you with a, with, with what they think is the solution and, and nowhere do they ever explain why. What is it they're trying to solve? You just made a post on Mastodon today about that.
Wolf:You know. I did, I did.
Jim McQuillan:And, uh… you know, it's… I'm not thinking about the language. Maybe, you know, maybe because the languages are pretty well ingrained in me. I'm thinking about the problem. I'm trying to boil down what they're talking about into what is the problem. And… That's all.
Wolf:And not just what is the problem, what is the real problem? Because they told you the how probably and and just like I said in my post.
Jim McQuillan:Yeah. Oh, yeah, they always tell me the how. Yeah, they start with how.
Wolf:And the how is wrong.
Jim McQuillan:Yeah, and I always have to turn it around and say, what problem are you trying to solve?
Wolf:Right. Because if it was the right how, they wouldn't need you. They'd just do it themselves.
Jim McQuillan:And then we'd get to it. Yeah! Yeah. Right. And, and, you know.
Wolf:And the invention of AI makes them think it is the right how, and also makes them think they can do it themselves, and both of those are wrong.
Jim McQuillan:Yeah, because even with AI, you're much further ahead to describe the problem you're trying to solve than how you want to solve it. Right? Let AI help you figure out how to solve it. Just explain to it what problem you're trying to solve.
Wolf:I'm gonna skip over that one, but yes. Like, I have to do everything when I talk to AI. First, I have to talk about what is the problem, and then it starts telling me how, and I'm like, yeah, you know what, that how is not correct. You actually needed a KD tree here, because that would have been the right thing.
Jim McQuillan:Why are you… Yeah, sure, you're… yeah, you're coaxing along, but… but don't start with how you think you should solve it.
Wolf:Yeah yeah. Right, because that skips everything and the AI has nothing to grab onto. All it knows is how to make you do a better whatever it was you were gonna do, not how to pick the right thing to do the thing that you needed at the end.
Jim McQuillan:Yeah. Right. Umm. Mmhm.
Wolf:Um, so if you're out there on the web, go read my post. Um, it's short, and I think it is true. Um, alright. So. I want to talk about how you know you're getting the right thing. Um, how do you know you chose correctly? And what things should dominate your choice? And I make this decision the same way I make all decisions, and I talk about constantly. And, uh, Jim, do you know what my main factor is for making these decisions?
Jim McQuillan:You measure.
Wolf:I measure. It's going to be about cost. Um, so there's a lot of things. There's execution speed cost. Uh, for instance, Python is 10 to 100 times slower than, um, compiled languages.
Jim McQuillan:Yep.
Wolf:in CPU-bound work. Go is 2 to 5 times slower than C. Rust approaches C. But doesn't quite get there. So the key question always is. Is your service CPU bound? Most web services are I/O bound. It's very rare that you're writing a CPU-bound solution. It could be that you are doing one, maybe video transforms, maybe the kinds of things that happen in graphics. Uh, financial trading stuff does have a very strong CPU-bound component, but a lot of it is network latency. These guys are building their servers. right in the data centers that have the same machines that are doing the actual trades, because those machines are where the truth is, so the closer they can get their transactions to them, that's a tiny little advantage. Um, so… the question is, um, you know, for Python, Python is slow, but is your service slow? And is it slow… because of Python. Now I'm using Python, but whatever it is that you're using, you fit into there.
Jim McQuillan:Umm.
Wolf:You cost something, and you can measure it. Where does the the cost come from? Does it come from? some property of the language that you could make a trade on. A great thing about Python is it's easier to write code in. That's a trade. Do you want something that's faster to run, faster to execute, but a lot harder to write? For instance, Python, Ruby, and JavaScript are really great to get started with because you can get stuff running. soon. The development speed is high. But static languages, uh, where you're using type checkers, um, like C++ or, uh, uh, Java or, uh, Rust. catch more bugs at compile time. Python's getting better at this because you can run, uh, static type checkers, uh, so I like that.
Jim McQuillan:Right, but that comes at a cost of compile time. Yeah, so where do you want to spend your time?
Wolf:Where do you want to spend your time? Exactly. And then there's the learning curve. If you want to do Python, and you don't know Python. In a couple days, you can be writing Python. JavaScript, it's days, but there's a lot of foot guns. Go, still simple, but it's not days, it's a few weeks, probably under a month. Rust? Oh. I really like Rust, but I am absolutely not gonna tell you Rust is a… I learned Rust one weekend. That's not how it works. Rust takes months. The BorrowChecker is a genuine conceptual. hurdle for most people. It is as hard for most people as learning about pointers was the first time they learned about that.
Jim McQuillan:You know, about Rust, I've heard, I just read this today, that Rust, it's easier for. new programmers to learn Rust. Maybe because we're so entrenched in all the things we know about programming, but new programmers that don't have experience with other languages pick up Rust faster.
Wolf:I buy that.
Jim McQuillan:Yeah.
Wolf:I absolutely buy that. Um, I am gonna name one more language, and that is Haskell. Um, Haskell's harder than Rust. Not because the syntax is harder, Haskell is harder because you have to rethink.
Jim McQuillan:Yep.
Wolf:How programs fundamentally work. How the pieces connect. Um, how you can change values and have an impact on the world. Uh, the thing that we used to use, um, side effects for, um, Haskell frowns on them in a very significant way.
Jim McQuillan:Is that is that because Haskell is a functional programming language?
Wolf:It is, yes.
Jim McQuillan:Like, entirely? Yeah.
Wolf:Uh, another cost is your team. Now, for you, Jim, uh, you and your team, uh, I just said two words, and that is the size of your team. It is two people. So… like, team familiarity is a thing, but training your whole team is maybe cheaper than training a team of 20. So…
Jim McQuillan:Sure.
Wolf:Um, if your Python team is switching to Go, and it's a big team. That could be 6 months. Um… There's a question about the talent pool if you are in a world where you might be hiring. Uh, if you work with Python. There's Python programmers everywhere! You can't throw a rock and not hit a Python programmer. Hell, they're on Reddit. You'll see them. If you want another Perl programmer. Ouch! If you want a COBOL programmer.
Jim McQuillan:Oh yeah.
Wolf:Oh, my God.
Jim McQuillan:Yep.
Wolf:Uh, you almost have to teach somebody that. Reputation. Um… PHP has shed a lot of its stigma, but the… the point about reputation is… A programmer wants to go somewhere where they feel like they're doing something serious. And if your program is in PHP, or BASIC, or, you know, who knows what, and somebody else is writing stuff in C++ or Java.
Jim McQuillan:Sure.
Wolf:there's going to be a bias. They're gonna be like, well, these guys are serious, and those guys aren't. Um… So. For you. Which of these costs. do you think engineers most consistently underestimate? And I'll tell you my answer after you say yes or no.
Jim McQuillan:Well, if the engineer is interested in, let's say they want to use Rust or some other new language, they're going to underestimate how long it's going to take them to do that. the learning curve, I think, is probably what they're gonna underestimate the most.
Wolf:I think I mostly agree with that. I don't like the question, um, or your take or my take on it, because to me, it's a tool, um, and. I don't care if somebody is interested or not interested in using a table saw to cut two boards apart. When you're gonna cut two boards apart, and it's a long board, and you want it to be straight, a table saw is the right tool, just goddamn use it!
Jim McQuillan:Yep.
Wolf:I don't care if you're interested! Just use it! So, um…
Jim McQuillan:Right.
Wolf:Interest sort of plays a role in what language, in that programmers think that matters. But, uh, you know, there are whole cultures in this world where people have arranged marriages, and they come to love each other, um, at the end, and they have children, and they're happy, and they miss each other when they're gone, so… Use the table saw. My feeling is that it's a team familiarity. The cost of your whole team knowing Java? is a secret, hidden thing that nobody thinks about. That the idea of moving your whole team to something else, um, is gonna cost more than you think. That's what I think.
Jim McQuillan:Yeah, some people just aren't gonna make the move. They're just gonna be incapable of making that move. There might be… there might be awesome Python programmers, but ask them all to move to Rust?
Wolf:Yeah.
Jim McQuillan:Some of them aren't going to make it.
Wolf:Yeah. Um… And luckily, my personal feeling about Teams is… You cannot expect. a team to be at one level. A team is, you know, spread out like a scatterplot. There is somebody who's an expert, even in the one language your team uses. There's somebody who knows every dark corner. You should do this, you shouldn't do that, I'm gonna make that. And then there's people who get along. They can write stuff, but they couldn't… in C++, uh, when I was at Netscape, and then it was called Mozilla for the place that… the things that I did. There were experts in C++, and those were the people that you wanted to build the APIs and write the templates? Uh, templates is a way of doing generic, um, kinds of implementations of things. A normal person doesn't want to write a template. To write a good template is 3 times as hard, 5 times as hard as writing an ordinary function.
Jim McQuillan:Mmhm.
Wolf:Um, because you're trying to write it in a way where it applies to everything, and returns the right kind of type, and.
Jim McQuillan:It's more abstract and yeah.
Wolf:Yeah, exactly. If you have, on a team of 12, a guy who can do that? And then five guys who will take that and just use it? That's great! That's a good distribution of how your team works. I think that if you decide your problem is best solved by multiple languages. That's also true. Maybe in a world where mostly you write in Python. But your team has… A guy who's really great at math? Um, and knows how to use NumPy. Uh, even though NumPy isn't a language, it's, it's, it's doing the same job here, semantically. If that guy knows how to use NumPy, and other people just know how to call his functions that use NumPy underneath. Same thing. Great use of your team. Um, and if a guy knows how to do performance measurement and figures out this needs to be written in Rust. And you have one guy or two guys who know Rust? Great. I think that's good. So, um… Yeah, I don't think you can have a team that's all at the same level. That's not how the world works.
Jim McQuillan:No.
Wolf:Uh, one thing that we looked at, that we noticed, that we called out, is that there are multiple. Paradigms. Some of them are not that far apart, and some of them are very far apart. Prolog is a totally different way of solving problems than C is. Prolog isn't about you finding the answer to the problem, it's about you specifying a bunch of, uh, categorized, hierarchical. rules so that the underlying rule engine inside Prolog can come to the right solution given the input parameters to a problem. That's completely different than how C works. And that's completely different than how Haskell works, where you don't have global variables, and side effects are the wrong thing, and um… A paradigm shift. is a problem. If you want to move from C to C++. The move is not all that big, or from sea to go. Uh, the language and the libraries are different, yes. But they're roughly the same paradigm. Um, if you want to move…
Jim McQuillan:Yeah, you can, you can do procedural programming in, in all of those.
Wolf:That's right. So, Python to Ruby. It's just syntax. Um… it happens that I like the way Python works, but if somebody said, write in Ruby, I could be doing it in not too long, a few days. But moving from Python to Haskell? Uh, that's a paradigm change, and it's at least 2 weeks for an experienced programmer, maybe longer, uh, and as always, never ever just rewrite stuff. Always plan what you're gonna change in a way where you can take individual steps. Where each step is valuable on its own, and you can stop anytime. The difference between any language that has a garbage collector. And rushed? That's a paradigm shift. Rust doesn't have a garbage collector. Instead, it has strict ownership models. That's a big deal. If you're used to garbage doesn't matter, it goes away, and suddenly you get into a world where not only does garbage matter, and there isn't any, there isn't any because you said the types right, and by the way, they're hard. Uh, that's a huge, huge change. Concurrency. Python, uh, at least up until recently, um, with the free-threaded model, um.
Jim McQuillan:Hmm-hmm.
Wolf:has a GIL, the Global Interpreter Lock. Threading and concurrency don't work in Python to the same extent that they do in other languages. Go has Go routines and channels. That's like it's a headline feature is that it's all about concurrency and Erlang and Elixir with actor models and message passing and letting individual hunks of it crash. Uh, and then be replaced, or just go on without it. Every one of those things is a whole different world, and it's a big jump. So, um… When you are looking at a shift in languages, because you've already decided, oh, this problem is better solved by this language. The cost to move to that language, you better account for if it's a paradigm shift.
Jim McQuillan:Mmhm.
Wolf:Um, because that's a big thing. So, the Rust ownership… here's another question for you. The Rust ownership model gets talked about a lot. Have you spent any time with any language that has an ownership model?
Jim McQuillan:I have not, but I have listened to you. talking, and Marlin also programs in Rust, and when I come across articles on Rust, I read them and see if I can follow along, but in my own coding, I'm not doing it.
Wolf:So the people who love Rust. are kind of pushing the ownership model as, like, this is gold. This is a thing that makes your programs better.
Jim McQuillan:Mmhm.
Wolf:the fact that this is explicit. Uh, I've kind of been saying that for decades. That's, like, the thing I wrote. that made Firefox function is that I wrote these smart pointers that enforce ownership in a really important way. Um, they don't do it the same way that Rust does it, uh, because, uh, in C++, uh, the way that they had to be handled because of how COM works is that they had to be reference counted. But, uh, Rust doesn't do it with reference counting. Rust does it with, the compiler understands the lifetime. But that also means you need to say things about the lifetime. Now, you've heard me and Marlon talk about it. What do you think? Are we overselling it? Do you have enough information to know?
Jim McQuillan:Oh, I think it's a great idea. I've… you know, I've seen all kinds of problems spring up because… because of, uh… you know, memory contention, you know, uh… uh, uh, I can't think of it, conflicts, uh, you know, with two threads trying to access the same, same piece of memory.
Wolf:deadlock.
Jim McQuillan:uh, deadlock. Um, I think… I think what Rust is doing is really, really interesting. So, no, you haven't oversold it. If I had the time, I would sit down and learn Rust.
Wolf:There's so much to learn and learning is so pleasurable.
Jim McQuillan:Yeah, there is. So I'm gonna, I'm just, I'm gonna listen. To you guys, right?
Wolf:Uh, so let me talk, uh, real quickly, because I promised, um, that certain problem domains, um. have been solved by certain categories of languages. For instance, math and scientific computing. Python basically wins in those areas.
Jim McQuillan:Mmhm.
Wolf:but by the ecosystem, absolutely not by the speed. NumPy started it, uh, gosh, in around, what, 2005? C-vect array operations, fast enough for most scientific work. then SciPy, and Matplotlib, and there's some other languages that make a difference here. R, Julia, and still, to this day, Fortran. But Fortran is hard to apply to bigger and bigger problems. It's really good at the how, um, the low-level part of it. Like, do the math for me. Fortran is fast, and we've written some really good Fortran, uh, compilers.
Jim McQuillan:Yep.
Wolf:But the most widely used language in production is probably not Python or JavaScript. It's probably SQL, um, or possibly COBOL. COBOL processes something like what?$3 trillion in transactions per day?
Jim McQuillan:Yeah. Yeah, I think it… it's been dying for a long time. I'm not sure it's, uh, in production code, I'm not sure COBOL is anywhere near the top anymore. But, I mean, yes, it's…
Wolf:Boy, they still pay a lot for a COBOL programmer.
Jim McQuillan:Well, now they have to, because, uh, you know, supply and demand. They're…
Wolf:Yeah, but my feeling is, um, you know, there are some jobs where they pay you because of your skill or experience.
Jim McQuillan:Mmhm.
Wolf:And there's some jobs where they pay you because of the shame you are willing to bear.
Jim McQuillan:Well, that would be combat pay, right?
Wolf:Hazard pay.
Jim McQuillan:Isn't that what they call it? Yeah.
Wolf:Yeah. Alright, finance. Um, there is a lot more diversity in the finance world than you would think. Um. For quant research, risk modeling, the machine language-based stuff. Um, it's Python. Uh, execution speed can be traded for development speed because you're exploring. Um, Java or Scala for actual production trading systems. Large-scale data pipelines. Apache Spark is JVM native. And Java is boring, reliable, runs forever, blah, blah, blah. C++, high-frequency trading. If microseconds are the product. uh, the language is C++, and you're co-located, uh, with the exchange, uh, using kernel bypass networking, probably with… FPGA-based order routing, just like if you were doing, um, crypto, uh, mining or something. Uh, this is a place where C++ isn't a choice, it's the floor.
Jim McQuillan:Sure, sure. Umm.
Wolf:Um… But there's a dirty secret for finance. Do you want to know what it is?
Jim McQuillan:Yes.
Wolf:It is Excel and Visual Basic. There are enormous amounts of financial modeling live in spreadsheets, trillions of dollars of risk.
Jim McQuillan:Oh, yeah. Sure.
Wolf:VBA is the language of choice for a lot of finance professionals, not because it's good. And, you know, spoiler, it's not good. Uh… but because the spreadsheet is where the business logic lives, and the business analysts know it. So, uh, does the…
Jim McQuillan:Yeah, now, now, uh, I mean, uh, uh, you know, like, Excel, uh, it's becoming quite popular to use things like Copilot. Uh, you know, to analyze your spreadsheet and make sense out of the numbers in your spreadsheet. So now you're not even doing VBA or anything like that, it's just asking Copilot to make sense out of it for you.
Wolf:And then believing it.
Jim McQuillan:Yah.
Wolf:Boy, I have so many problems with this part of our discussion. All right, the web. Um, the front end?
Jim McQuillan:Yep.
Wolf:Pretty much… You don't pick the language. It's JavaScript. The framework is the real choice. Are you going to use React or Vue or Angular or Svelte or HTMX or TypeScript?
Jim McQuillan:Sure.
Wolf:Um… Whatever. WebAssembly.
Jim McQuillan:Well, sure, it's not a… it's not a choice… yeah, but it's not a choice between TypeScript and React. I mean, it's… it's.
Wolf:If you're using React, you are using TypeScript, because React is TypeScript.
Jim McQuillan:Uh, yeah. Yeah, yeah, yeah.
Wolf:Yeah. WebAssembly is starting to come into play. And interestingly enough, it is more of a door than a library or anything. Lots of things that couldn't happen in the client before.
Jim McQuillan:Yeah.
Wolf:now can, because they can compile down to WebAssembly, and all these browser makers have promised us that WebAssembly will execute. You and I did a performance thing where you compiled some stuff down to WebAssembly.
Jim McQuillan:Yes. And it's getting… Yeah, I think so. it's… it's getting… it's getting… it's getting easier and easier. You know, a little plug for our, uh, Michigan Unix Users Group meeting. Uh, we… we just had a meeting last week, and the talk was on…
Wolf:And we ran it in the browser.
Jim McQuillan:Gosh, I forgot the, Bray was, is a gaming platform written in Rust. And Justin gave that talk and, and with a switch, he was generating Wasm code. You know, it was, it was Rust compiled down to WebAssembly and it's like, it's just there now.
Wolf:I think the name of the gaming engine you're thinking of is Bevy.
Jim McQuillan:Bevy, that's it. That's it. And, uh, it just amazed me. He wrote this thing, uh, this silly little game, uh, in Rust, and displayed it on the screen, and everything was great, and he spit out. WebAssembly and ran it in the browser, like flipping a switch. It was.
Wolf:You know, we often talk about our brilliant friend Marlon. Uh, we should point out that, um, he's not our only brilliant friend, and Justin is among those.
Jim McQuillan:Yes. Oh. Yes. Yes, yes, you know.
Wolf:Umm. So, games! People always want to write games until they find out how awful the games industry is and how badly they treat you.
Jim McQuillan:Iya.
Wolf:Um, but, uh, games, uh, C++ using Unreal, that's for AAA games. C Sharp is the Unity thing. Godot is a, uh, gaming engine slash thing, and it has GDScript. It's mostly about C Sharp.
Jim McQuillan:Yah.
Wolf:our good friend Robbie, um, writes stuff, uh, in Godot, he's playing with that, so that's very interesting. Lua is not exactly an engine language. But it is a modding layer. I'm not a huge Lua fan, uh… And that's kind of a bias. My bias is because Lua starts array numbering at 1. And then, like, I sort of stopped reading. Like, I can actually write Lewis stuff if I want to, but it doesn't make me happy.
Jim McQuillan:And. Come on, everybody knows it's supposed to start at zero. Take our take our podcast, for instance.
Wolf:Yeah, in fact, do take our podcast. But, um, you know, it's World of Warcraft, it's Roblox, it's… Everything. Anyway, uh, the forcing factor kinda runs backwards here. you don't pick C++ independently of Unreal. You picked Unreal because that's the one you wanted, and that meant you used C++.
Jim McQuillan:Sure, sure.
Wolf:Um… Do you feel like that's the same as the Xcode situation?
Jim McQuillan:Yeah, yeah, that's what came to mind when you just mentioned that. There's really no choice.
Wolf:We're getting closer to the end. The reality, and I sort of mentioned this, is… I'm going to use the $10 word. polyglot, that a real system is lots of languages. It could be that there's an API in Python or Go, the front end's in JavaScript.
Jim McQuillan:Yeah.
Wolf:The data pipeline uses SQL and some more Python and Spark. The infrastructure has Bash in it. And, like, we already talked about SQL. Netflix uses Java for its microservices, Python for its data, ML, and tooling, JavaScript and Node for some APIs. Go for some performance-sensitive stuff, bash for automation. No real problem is solved by just one language. Your tiny thing, where you're, you know, solving day 4 of, um… Uh… no.
Jim McQuillan:Yeah, yeah, the, uh, the, uh, advent of code.
Wolf:Advent of code? Sure. That's just C, or just… just… SQL or whatever. you decided to answer it in. But the real thing is that it's two languages or five languages, and the important part is getting your ROI, getting your return on investment. Figure out what are the layers, where does each. language belong. Python is easy to write code in, so if you've got a lot of code to write, you're gonna save money. If you… Spend less time writing it. But there is going to be some hotspots in there, where the real time is in executing that hotspot. That part, you don't want in Python. You're going to need to measure so that you find that part. If you are connecting two services. You could do it in Python, but that means launching a sub-shell and importing the sub-process module, and that's all hard. You could just say one line in Bash and do what you want, so Bash is the easy thing to use there.
Jim McQuillan:True.
Wolf:Um… But frankly, if you're writing something that's 15 lines in bash. Maybe that should have been a higher-level language. So, good ROI is when you do the thing I just said. You write the parts in the languages they belong in. Bad ROI is when the 20-line utility script. that would be 15 lines in Go, the rewrite wasn't worth it. The API would be 40% faster in Rust. It doesn't matter if the bottleneck was actually in Postgres. I don't care how much you saved.
Jim McQuillan:Yep.
Wolf:You didn't save enough!
Jim McQuillan:Right.
Wolf:Umm. So. There is a marker. If you will, a sign. that a particular engineer or your team are sufficiently mature, and that is an engineering team. that defaults to one main language so that everybody knows it. But consciously decides when to deviate, and does decide, hey, here's the part that needs to be bashed. Umm. is more mature than a team that debates the primary language constantly. Remember the thesis of my entire discussion today is. Do not let the language be the problem. Let the problem be the problem. Nobody's paying you to write Python. They're paying you to deliver some solution. And nobody cares if that solution is written in whatever language you care about there. It's a discussion you and I have had many, many times, Jim, and you use the same words every time. You say… I'm too busy delivering things to the customer.
Jim McQuillan:Well… Is that the wrong thing to say?
Wolf:That is NOT the wrong thing to say.
Jim McQuillan:Okay.
Wolf:It happened that you were saying it for the wrong reason, but it is absolutely the right thing to say. Um, so I just want to say one more thing. This is kind of a bonus thing. Everything I've talked about so far is about. picking the right language to solve your problem. And that is a very problem-specific decision. But… What about a totally different problem? What language should you learn? Um… For instance, uh, for higher pay. Um, higher pay, Rust engineers are starting to be more and more in demand. If you are interested in doing infrastructure stuff. Go programmers make money? Remember, learning a language where there are fewer of them makes you more in demand, and there are tons of Python programmers. I love Python, but if you are asking me how to make more money. The answer probably isn't learn Python. I mean, it might be, why don't you already know Python? It might be that.
Jim McQuillan:Yes.
Wolf:and like it's Monday first learn Python and then on Thursday I'll tell you your second task but. For higher pay, Rust, Go, TypeScript. Not exotic stuff. Stuff that's real, in use, lower incidence of the number of people who know it, but in positions where they're gonna pay more. But there's a whole nother reason, the reason you and I like to learn stuff, Jim, and that is languages that change how you think.
Jim McQuillan:Sure.
Wolf:Rust is, again, I think, one of the top choices here, because it is smart. It thinks about things in a different way, with. lifetimes of the underlying data, and ownership, and the way it manages types, and the stuff it does that's generic. And the things it doesn't give you. that it turns out you don't need, you just thought you did. Like, there is no null. in Rust. Instead, there are, uh, options and results. Um, it happens that one of the choices for an option is none. But that's not the same as returning null. Fundamentally, it's kind of a different type decision, but it solves the same kind of problem. but in a better way. Haskell, at the extreme, is pure functional, and functional, which we've done an episode about, and if I were smart, I would have already known the name and episode number of that. Uh, uh… uh, episode. I think it was called, uh, Functional Programming. You're probably already doing it.
Jim McQuillan:Episode four.
Wolf:Umm. And it was actually pretty popular. Um, learning Haskell is absolutely gonna broaden your perspective.
Jim McQuillan:Yeah.
Wolf:Lisp, or Racket, or Clojure, or Scheme, or any of those, um… Where code is data. That's a big deal. That's how macros work, because the thing you think you know, the thing that's in C, a macro in C or in C++, that is not what macro means in Lisp. In Lisp, um, and in Rust, by the way, as well, a macro is not, hey, replace this text with this text. A macro is… Here's a hunk of stuff from the underlying, um… Parshtree. Along with types. Like, we know what this thing is. It's a blah blah blah. I want to transform it into this totally different way of getting to that thing. Including how the types work. It's not a way of turning null into zero. It's a way of changing the language. In Lisp, there's a very, very few actual language operations, but there are a lot of things that are part of the language because they're implemented as macros. Um, for instance, uh, conditionals and looping and, uh, a zillion things that you would think are in the language, but they're just backwards. Um, Erlang and Elixir, the actor model and the whole let it crash philosophy, if you've never seen actual fault tolerance designed from first principles. Uh, dipping into Erlang and Elixir is gonna change you. So, most engineers don't need Haskell, uh, or Prolog. to have a productive career. In fact, I think you are the evidence of the fact. It doesn't matter what tool you use. You're doing absolutely fine, productive, useful. Tools that are helping doctors. in the business of saving lives, and you're writing it all in Perl. it doesn't matter what brand of table saw you have. Um, you can have a productive career, but the engineers. who take the time. to look at these other tools and why they're good and why they're bad. Umm. They become more capable. Um… If you look at you and me, Jim, and… I absolutely don't want to say this in any kind of way that makes it sound like I'm putting you down because that's not what I'm doing. But there are a bunch of interesting skills and things that I can do. Because I'm always looking at alternative tools.
Jim McQuillan:No. No doubt.
Wolf:Umm. You and I both solve problems, and we both deliver things to the customer. The fact that I know this other range of things, it does give me the opportunity to use other techniques to deliver those things.
Jim McQuillan:It's your superpower.
Wolf:But we're both doing the job.
Jim McQuillan:Umm.
Wolf:So. The thing I want to tell people here is… Look around. Is there a language you have learned, Jim? Even if you rarely or never use it, now or anymore or ever, that you were glad you learned?
Jim McQuillan:Well, the first one would probably be COBOL. I'm certainly not using it, I haven't used it in 15 years, or longer, probably 20 years, but I'm glad I learned it. It allowed me to think in terms of business logic. So that helped. You know, I do a lot… I've done an awful lot of C programming, and I'm really glad I learned that. I've done assembly language programming. I'm very glad I've learned that. I don't do any of those anymore. Uh, but they certainly helped me understand how, how computers work. No doubt.
Wolf:I have definitely learned a few languages that I think changed me. And one of them doesn't even count as… I guess two of them don't even count as full-scale programming languages. One is regular expressions.
Jim McQuillan:Oh, yeah.
Wolf:Regular expressions is technically a language, but it's not a programming language, but it changes… I do. And it changes the way you think. Another is SQL. Yes, if you are a god, like you.
Jim McQuillan:But you use that every day. Yeah. Yeah, I.
Wolf:you can write an actual program in SQL that does something. Most people just use SQL in the same way that they use regular expressions, that it solves a fraction of their problem, but it solves it in only the way that tool can. So those two things were life-changing for me. And I think when I moved from languages that didn't really have types or didn't express types in a good way into languages that did have good types, I think that was changing.
Jim McQuillan:Right.
Wolf:Because I learned about, um… I was just explaining to someone, uh, yesterday, um… I was saying to them, and I wasn't as kind as I should have been, I said to them, I don't think you understand what my job is. Because you think my job is, uh, adding these numbers together and finding the answer to this problem. But that's only a small part of my job. My job is teaching people how to think. Because when I build an API for something. The types that I use, the shape that I've made, the way I gave them access to the underlying functionality, the fact that I said, and by the way, this is a context manager, so when you start it. You can't NOT stop it. It's going to stop, that's just how it works. Um, the fact that I said those things lets them use it in a way where it solves their problem with less friction. That's my job. My job isn't just to solve the problem, because anybody can solve the problem. Anybody can cook a sausage.
Jim McQuillan:Mmhm.
Wolf:You don't go to Metzger's because they're gonna make you a sausage. You go to Metzger's because they're gonna make a goddamn good sausage. Right? You go to these places because they're going to do it in a way where it's way better than you could get if you did it some other way.
Jim McQuillan:Yep.
Wolf:And I don't just solve the problem, I solve the problem in a way where other people can use that answer when they're solving their problem. Um. So that was a big change in my life, learning about how to make those promises and shape those ideas. So let me close it all out. What do you actually want? You. Want. Boring. Uh, that is a term of art in engineering, and it means predictable, well understood, proven at scale, extensively documented. widely staffed with known failure modes, and all the corners are brightly lit. The opposite of boring is exciting. Sounds good! I want exciting! But guess what? I don't want exciting. You do not want exciting. Uh, in production. Exciting is a liability. The boring answer is the language your team already knows or can learn. An ecosystem that fits your problem so you don't have to get it brand new, write it yourself. get it from someplace where it's random. Uh, they can produce correct, performant, enough, maintainable code, and that doesn't make the language itself a source of friction. The failure mode of avoiding the boring answer. Six months of a language debate. Do not let the language be the problem. Debating a language for six months is wrong. pick an answer and be done. The success mode is you spend two days picking the right language and you stick with it and spend six months building features, delivering to the customer. Exactly the thing you want, Jim, and exactly the thing I want. The language is not the product. It never was the product, and it never will be the product. Um, and the growth angle… is… Pick the right language. And sometimes saying, "You know what? This one wasn't good enough. We need a better one. That's your opportunity to grow and change. You did it. I think you told the story of moving from a COBOL answer to a PEARL answer.
Jim McQuillan:Umm.
Wolf:Umm. And you did it exactly the right way. One valuable step at a time, where you could stop in the middle, at any point. What you had worked, passed all the tests. Solved the problem, did the job, but every piece, you are on your way to a better final answer. Yes, sometimes you have to change the language. And do it just that way. So…
Jim McQuillan:Yep.
Wolf:If someone came to you tomorrow. And said I want to pick a new language to learn this year. What would you tell them?
Jim McQuillan:Well, I'll tell you the language I've been learning for the past month or so, and that's TypeScript. I'm a pretty good JavaScript programmer, I can do a lot with it, but I wanna do something with types. So I chose TypeScript, and I'm learning that, and I think that's a great language to learn. Somebody who doesn't know Python should learn it. Rust is a good one to learn.
Wolf:I 100% agree with you. If somebody came to me, the boring answer, the one that is reliable and well-tested, and in this case, very high ROI. is TypeScript or Go. Those things are used in lots of places, they're valuable to learn, they're better to work with than what you probably were working with before, um, you're going to enjoy them, they're going to broaden you.
Jim McQuillan:Mmhm.
Wolf:But they're still safe.
Jim McQuillan:Mmhm.
Wolf:And if you wanted the growth version. Uh… I'm on board with Rust. I think Rust is fantastic. Haskell is going to change how you see everything, but the truth is, you'll probably never use it. Um… I guess the final thought is the language is not the product. The language is the tool. It's the table saw, the chair, dresser. The… medical records-keeping software. The… Map. That's the product. Don't let the tool be the conversation. Start letting the problem be the conversation. Deliver answers, solutions, to the customer. And don't fight about which saw. That's stupid. Umm. I think that's all I have to say. I love the phrase "resume-driven development.
Jim McQuillan:I… Yeah, I like that too, because it makes you think that people use that a lot and don't know it. But yeah, you've covered some wonderful material here. I was looking forward to this episode, and you did not disappoint. Uh, so thank you. Up. So. Thank you, everybody, for listening. This was a nice, long episode. We're perfectly happy to do these long episodes. keep tuning in. Uh, as always, uh, we have, uh, show notes at the end. Uh, we'll, we'll include some, some information about this episode. Uh, certainly we'll include.
Wolf:Read the transcript.
Jim McQuillan:We have a transcript. We have, gosh, what else? I'm at a loss. Oh, contact information. Yeah, contact information. Our Mastodon accounts are there. Our email addresses are in the show notes.
Wolf:Feedback?
Jim McQuillan:Um, and feedback. We love feedback. Um, we, we learn from the feedback, and we, we try to incorporate that into everything we do. Uh, so send us feedback, uh, to feedback at runtimearguments. FM. Um, and if you forget that, just look at the show notes, because the address is there. And we have a website, uh… www.runtimearguments.fm. So yeah, no, did I get that wrong?
Wolf:No, I don't think it has www. I think the thing is that it's HTTP. No S.
Jim McQuillan:Yeah.
Wolf:And it's runtime-arguments.fm.
Jim McQuillan:Yeah, right, okay. Do not do www. Because that just… because that just won't work.
Wolf:You know, I do want to say one little tiny piece of feedback I missed. It's tiny. It's something I told you before the show. And that is, uh, you know, we just had the SSH episode, and we talked about jump boxes.
Jim McQuillan:Anyway… Yes. Yeah.
Wolf:And, um, I have a pair of boxes inside our firewall, and I can get to one, and I can't get to the other. unless I go through the one, so it is a jump box for me. Um, it turns out that if I use the jump proxy, uh, statement inside my .ssh slash config. It just works, and it was so easy, so look that up and use it.
Jim McQuillan:It it just works. No friction. All right. Thanks, Wolf. It was a lot of fun.
Wolf:Thea.
Jim McQuillan:Bye.
People on this episode
Podcasts we love
Check out these other fine podcasts recommended by us, not an algorithm.
CoRecursive: Coding Stories
Adam Gordon Bell - Software Developer
Two's Complement
Ben Rady and Matt Godbolt
Accidental Tech Podcast
Marco Arment, Casey Liss, John Siracusa
Python Bytes
Michael Kennedy and Calvin Hendryx-Parker