Relicans host, Kirk Haines, talks to former Relican, Chael Wright-Munn, about how programming is just as human as art, and poetry, and music where you’re following certain rules and certain conventions to create something that didn't exist before, making habits and systems versus trying to keep things in your head, and how she feels about the Rust programming language compared to other languages.
Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.
Do you have ideas about how we can make our show better? Or would you like to be a guest on an upcoming episode? Reach out to our #devrel team at devrel@newrelic.com. We would LOVE to hear from you with any questions, curiosities, and/or feedback you have in hopes of making this the best show possible!
Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.
Kirk Haines: Hi. Welcome to Polyglot. My name is Kirk Haines. You can find me @wyhaines on Twitter and pretty much everywhere else on the internet. And today, I'd like to welcome my guest, Chael. Say hi.
Chael Wright-Munn: Hi, I'm Rachael Wright-Munn. But as Kirk said, you can call me Chael. I've been a software engineer since 2012. And a lot of my professional work has been with billing systems.
But most people probably know me from my Twitch streams as ChaelCodes; I do a lot of open-source work, play programming games, and often do tutorials. I've actually been doing a tutorial with your co-worker, Aisha, where we go through the Rust Book. And that's been really interesting.
Kirk: So it's kind of funny here.
Chael: [laughs]
Kirk: Just to let everybody else in on the secret, Rachael and I know each other. Normally when I do these Polyglot episodes, I'm talking to somebody that I may not really know, but I know Rachael. And so this is a little bit of a different conversation than most of them that I have.
But I like to start at the beginning with people and just get a sense for how they ended up where they are, where they started from, and how they got there. You've been a developer since 2012. But how did you get there? What was your starting place?
Chael: Also, it's a little weird for me as an ex-Polyglot host finally getting to be the guest. It's exciting too.
Kirk: [laughs]
Chael: So, where I started is in college. When I entered college, my degree was chemistry. And in order to take that class, I actually had to take an intro to programming class. In the course of that intro to programming class, what I realized is that I really loved programming. I liked the logic of it. I liked the idea.
I can actually pinpoint the moment where my major changed to information technology with a concentration in software development. I was in that intro to programming class. And before that point, I was enjoying programming, but I didn't really see myself in the field.
But we were in class, and we were doing this very small, little task. We were writing a Java program. And what it would do is if it was an even sentence, it would take the middle two letters out. And if it was an odd sentence, it would take the middle one. And the idea was that we would learn about if statements and practice them.
And the professor was very explicit about this. He was like, "We're learning about if statements right now." And there's this person sitting a couple of rows back. And every minute, he would raise his hand with a different question. "What if I find a different way to get the substring? What if I find a different way to tell if it's odd or even? What if I do this? What if I do that?" And I'm just like, we're learning about if statements. The professor does not care as long as you write an if statement.
Kirk: [laughs]
Chael: So I literally raised my hand, and the professor calls on me. And I'm like, "What if I remove the if statement?" And he's like, "I don't think you can do that." And I was like, "Well, technically, if I subtract the remainder from the second number, then I would get two letters [laughs] versus one." And then my professor looked me in the eyes, and he asked me, "Are you an IT major?" And I was like, "No." And he said, "You should be."
And before that moment, I had never seen myself as a developer, or a software engineer, or someone who could do this professionally. But I just felt so excited and flustered and proud of that moment and recognized. That carried me through the rest of my degree. [laughs]
I got an IT internship. That one was a little bit of a fumble too. [laughter] So what I did was I applied to work at Macy's, like in the store. And so I had written up my resume, and I was like, here's what I'm doing in college. Here's all the stuff I'm doing.
And the store that I had sent it to forwarded my resume on to a Macy's Systems and Technology campus that was in the same state. And they were like, "Hey, we don't have any openings, but I forwarded your resume to them." And that's how I got into their IT internship program. [laughs] I was applying to be a clerk.
Kirk: That's sweet. That's a good story. I love your story about how your major changed. I guess that it was almost a snarky "Can I remove the if statement?"
Chael: Oh yes. Absolutely.
Kirk: Because you were totally exasperated by the other person, and that turned into a complete transformation of your career path.
Chael: [laughs] I was sassy, and that's how I ended up in tech.
Kirk: [laughs] And it worked.
Chael: Well, I think also the important thing to acknowledge about that moment is that my professor didn't see this as me being disruptive and snarky, and sassy, which in some ways I was. He saw this as an opportunity to recognize my potential. And I had a lot of professors in college who did the same thing.
When I think about the people in my career that have really inspired me, a lot of them come from my college, like Dr. Rick Price, Dr. Evelyn Brannock. Honestly, those people encouraged me and made me feel like I had the potential to do great things. And then I worked on making companies...
Kirk: So with that internship that you mentioned with Macy's, was that where you count the start of your career? I mean, was that 2012 or was that pre-2012?
Chael: That was 2012. That's where I count the start of my career because I started working part-time and actually working on software and collecting requirements, and building things for a company. At the end of that, my mentor...all throughout my story, you can see all of these key people who were so important to me becoming who I am, who gave me these opportunities.
My mentor went and talked to my manager and was like, "We should bring her on part-time even once the internship is over until she finishes her college degree." That was the start of my career.
Kirk: So in college, you were using Java and probably had exposure to some other languages. At that internship, were you also a Java programmer then at the internship?
Chael: No, I worked a lot with SharePoint. So that was really where my introduction...So, first of all, a lot of it was honestly working with drag and drop tooling. And then I worked with TIBCO BW, but don't tell the recruiters that.
Kirk: [laughs]
Chael: I fervently denied.
Kirk: Awesome.
Chael: Oh, and I got to do some SQL. That was fun.
Kirk: SQL is always useful. But here's what I want to know. So you had this beginning, Java with these other tools. Now, I know, and anybody who knows you knows that you're a Rubyist. So how did you go from that beginning to Ruby? And were there any steps in between?
Chael: Oh, absolutely. I was an ardent polyglot. I was like, I don't care what language it is. I don't care what tool it is. I'm going to use the same patterns that I learned from that first language.
I remember this drag and drop workflow thing that I had to build in a SharePoint list that had to track people's vacation. And what I ended up doing was essentially making it recursively call a workflow on the next one. And that was literally like; they didn't have loops. And I was like, I'm still going to build something with this.
So before Ruby, I literally would work with anything, anything I could get my hands on. But CallRail was where I first worked with Ruby. I went in a polyglot, and I came out a Rubyist. [laughs]
Kirk: And what drew you to Ruby? Was it just that that was the language used there, or was there something else? You sort of landed on Ruby, and Ruby has been a focal orbit for you. But what drew you there?
Chael: That's actually a good point. I actually forgot about part of my history with Ruby. So I joined a group called Rails Girls in ATLRUG because one of my friends in college worked on Ruby on Rails. And I think that being part of the community of Rails Girls and how welcoming ATLRUG was was part of that journey to feeling like part of a community.
And I tried a couple of other ones. I tried Django…PyLadies, PyLadies, that's what it is. And I think it's Django Girls or something like that. And those didn't resonate with me in the same way. I didn't feel like I fit the same way I do with the Ruby community. But as far as me actually converting versus just being interested in joining, I would say that the community sparked my interest in working with it. But it's just the elegance.
Like I mentioned before, I was like, oh, this system doesn't even have loops, and I'm going to make it recur something. There's a part of me that likes applying the patterns I've learned in other places to these very crunchy systems that aren't supposed to accept them. I think it's part of why I like the Zachtronics programming game so much and why I like SQL and Redis. [laughter] It's because you have these different patterns.
But with Ruby, that's all you're writing. It's such an expressive language that's really focused on the logic. So everything else just gets stripped away, except for that pattern and the bare minimum. Do you ever think about programming as this very human thing to do?
Kirk: As a human thing? That's a hard thing to tease apart because, like for myself, I've been programming in one form or another for 40 years. And so programming is something that, for me, is very human because it's like everything in my life is touched by it one way or another.
Chael: [laughs] Revolves around it.
Kirk: Yeah. But like, I wanted something fun to do because I'm bored. Well, let's not go play a game, maybe, but also, let's just go write some code. And so in that way, it's a very, very human thing, but I'm not sure if that's the human thing you're referring to.
Chael: So hear me out because I think that it is. I think what you're describing is how you innately express yourself with programming. And in my eyes, programming is just as human as art, and poetry, and music. All of these things are built on this foundation of math and language. And both math and language are things that we made up. They didn't exist before humans showed up. Sure, birds have birdsong, and they communicate.
But the idea of using language frivolously, I think, is kind of a new one. Math is definitely new. That's an exciting thing that humans came up with. The number zero was invented. And then we were like, that's not good enough. We need nil, and we need undefined, [laughter], and we need null too.
Kirk: And negative numbers.
Chael: Exactly, exactly. The concept of negative numbers is something that people came up with. And then we stick all these concepts together, and we mix them up, and out of it comes programming. And if you think about it, most of the time, when we're programming, we're trying to describe our world.
When you model an object-oriented system, you're like, I have a user, and my user does this action. And they're these nouns that exist. What you're doing is you're modeling how that user interacts with the world, and you're describing it.
And I say this because, from my perspective, I work on web apps that are very much like, extract, transform, load. That's all we do. [laughs] But at the same time, that's what the job is: extract, transform, load. It's take all of this information, model the system, and then graph how people interact with it.
Kirk: So it's an interesting way of looking at it. I've never consciously thought about it in that way. But if I think about how I feel when I am writing code versus how I feel when I am writing something else, they're actually very similar.
It's, in both cases, a creative expression where I'm following certain rules and certain conventions to create something that didn't exist before. And I've never really thought about that, but it actually is very, very similar. I like to build things myself. The house that I live in I built it, and I like building things.
Chael: Really?
Kirk: Well, part of it. It's a very old house. It's two very old houses.
Chael: Ooh.
Kirk: And I built the piece in between that joins the two very old houses into one house. But yeah, that is a creative process. That is basically the same as programming, even though the tools are completely different. So that's a really interesting observation you made.
Chael: Yeah, I'm good at those.
Kirk: [laughs]
Chael: That's really cool that you built your own house. That's a ton of work.
Kirk: Yeah, it's still happening.
Chael: But what codebase is complete?
Kirk: You know how when you're working on a software project, or you're getting ready to work on a software project, and you're speccing out the work, and you need to make estimates? And you estimate okay, that feature will take this amount of time, and this feature will take this amount of time.
Chael: It's always wrong.
Kirk: It's always wrong, and it's always optimistic.
Chael: Yes. [laughs]
Kirk: That's what it was to build my house because I'm still building my house, and I've been living here for 14 years. [laughs]
Chael: Wow. Okay. So this has been a long-going project. You have a legacy connection between your two houses. [laughs]
Kirk: Yes, that's it exactly. It's one of those software monoliths where you keep adding new things and to the legacy codebase. [laughs]
Chael: You started off with two microservices, and then you merged them into a monolith. [laughter]
Kirk: Yep, that's exactly it.
Chael: Can we go back to this velocity thing?
Kirk: We absolutely can. I love the velocity.
Chael: So I've been a team lead five different times. And I have lots of opinions about Planning Poker and velocity and how teams underestimate tasks.
Kirk: [laughs]
Chael: And I think you're absolutely right; we're too optimistic. We see the path forward, but we don't see the refactors that are going to happen. We don't see the craft in the codebase. We don't see the bugs we're going to uncover, right?
Kirk: Yep.
Chael: And I think what velocity and Planning Poker allows us to do is accurately account for that time because another thing that developers never think about is review and deploy time. They always think the job's done when the code is written. But it goes through a whole review cycle that can be a couple of days, or a week, or a month.
Some of the code reviews that I've had recently have just dragged, and some of that is not getting back to them quick enough. And some of it is just delays in leaving reviews. It can take a lot of time. And I think that when we describe things in terms of complexity, what we're really doing is we're creating a map. And then, that map has to be looked at from a meta-perspective in order to get an accurate estimation of the amount of time.
Because if we sit there and we say, "Oh, this is like a two-point task. This should take me two weeks," or something like that...and by the way, if it's a two-point task, it probably shouldn't take two weeks. But that's not surprising with the review and everything. [chuckles] But if you are thinking about it in those terms, then you're actually undermining the efforts of the points originally.
If you're not mapping like, here's how many points my team can complete in a sprint and using that to decide how much work to put on your team's plate, then you're not really getting the benefit out of Planning Poker.
And the other big mistake that I see teams make is they don't actually discuss the points. Because I feel like the benefit of Planning Poker is not just like, oh, we have assigned points to this task. And now we can figure out how long it's going to take us based on a meta-analysis of how long it takes our team to complete points. But it's actually the conversations around that task and how it's going to be done and figuring out what you're going to need to research in advance.
Because I'll see a lot of times where it'll be like, three people are fours and...well, not fours because we work with Fibonacci most of the time. But like, three people are fives, and one person's a three, so we'll make it a five. And I'm like, no, ask the person who's a three, ask the people who they're fives because even if it settles at five, that discussion was worth the time.
Kirk: Yeah. And it's an interesting thing, too, because, like you said, developers so often forget the whole review and deploy step. But it's also I think that generally speaking, developers want to get things done. They want to deliver on things. It's just a personality characteristic that often goes along with the job.
But hear me out. When you're sitting there, and you're looking at a task, and you're trying to figure out what it's going to take, there is a prejudice towards thinking, yeah, I can get this done, and I can deliver it, and I feel good about it. And that part of I think what leads people to not think about all those things that you mentioned. I've been doing this a long time, and I'm still super guilty of that a lot.
Chael: [laughs]
Kirk: It's something that I have to constantly remind myself. Because I will sit there and I will look at a problem. And my brain is like, okay, I see the solution to the problem. This can't be that hard. And it's like, yeah, but brain, you're forgetting this, and you're forgetting this, and what about this? And oh, you didn't take into account that you're going to hit a roadblock here. And that's going to take you a day to realize that you dropped one character somewhere.
Chael: [laughs] I spent three hours on a parenthesis that was in the wrong spot literally last week.
Kirk: [laughs] Yeah, I think everybody who's listening to this who's been programming for any length of time, any length of time is more than a week, can empathize with that particular pain point. And so yeah, that inherent optimism leads us to disregard those things. And so when you're talking about the point poker, a lot of people fall into the trap of okay, two points. That must mean it's a day, maybe, but maybe not.
And when everybody's bidding, when you have that person who is voting a three, that conversation that you're talking about, why are they voting a three? Are they voting a three because they are being overconfident? Or are they voting a three because maybe they've thought about it in a different way than the people who are voting fives? And you don't know unless you have that conversation.
Chael: Exactly. And it could be the person who came up with the three has a different way of implementing it in mind that would be more efficient. It could be the people who voted fives; all of them have a different thing that they think makes it more complex. So the whole thing turns out to be an eight. You don't know unless you have that conversation. That's why I always think if everybody agrees on the points, that's a missed opportunity to have a conversation.
Kirk: So this brings up something that I'm wondering too. And I'm just curious about your experience with this when we're talking about points. Because one of the things that I've struggled with at times in very, very small teams is that sometimes points are more difficult to use as an analytical tool in a very small team because the noise is magnified, you know, the "Oh, on this particular sprint, we just happened to run into a whole bunch of problems. And so our estimate was way off," or whatever. What's been your experience with that?
Chael: Oh, same thing. The point values will swing. Certain teams have been more dialed than others. So there was one team I think I was with them for around a year-ish; maybe it was only eight months or so. But we managed to really dial in on points, and we were consistently hitting the same number. It's been a couple of years since then. So I can't tell you what the number is. But we were able to really dial in.
But the other thing is that it's about relative success. So in my eyes, the alternative to using points is guessing how long the project will take based on t-shirt sizes or guessing how long it will take overall. I've seen the guess how long it takes overall. And most of the time, they're like, oh, it'll take less than eight months regardless of the size of the project.
Kirk: [laughs]
Chael: I've never seen a developer give an estimate that's longer than eight months unless it's actually multiple projects. But in reality, those projects can take a very, very long time. And the more you break them down, the better you understand them.
And if you say we have to point this before we can understand how long it will take, then that pointing process becomes part of breaking it down and really understanding what it is that you're building. So you're right. Month to month, the values do vary a lot. But I found that Planning Poker consistently gives us better insight into what we're building.
The other thing it really helps with is newer developers especially. So when you have more experienced developers talking about what makes something more or less complex, your newer developers or your more junior developers are going to be able to learn those are the challenges; those are the things that make it more complex. They're going to be on the lookout for that. They're going to be thinking about it for a few days before they pick up the issue. Or you may even talk about how you want to solve it and put that into the ticket. That's huge.
I love, and I've worked so hard to get to this point, and I don't think I've successfully made it on any teams yet. But I want to get my tickets to a point where I can hand them to somebody on a different team, and they can work on them and implement them correctly. I've had a number of tickets that have met that criteria but never consistently.
Kirk: Both of those things are interesting insights. I think that the one just talking about how pointing process can help younger developers is a really good one because what it boils down to is it's an opportunity to use situationally appropriate...there's a term that if you're a parent and you have a child, and your child asks you a question, you can just answer the question, or you can take that as an opportunity to actually teach something while answering the question. And my brain will think of the word that I'm looking for as soon as we stop recording.
Chael: [laughs]
Kirk: But that's what you're talking about is you're talking about we're going to discuss these things. And in the process of discussing them, it's an opportunity for us to share some insight or some thought processes that might otherwise be difficult to share because you have to have the appropriate context to do it. And that's, I think, a really good insight into the value of that whole process.
Chael: It is. I'm going to go back to CallRail. That was one of the best teams I've worked with, best-run teams. I'm just going to pat myself on the back. I did some really innovative things there as a team lead that I really enjoyed. The retros were phenomenal. [laughs]
But one of the things that I really liked is that later on in our maturity cycle, we started doing these architecture review meetings where we would discuss how do we want to solve this problem? Here's the problem. Here are some ideas I have up on the board for how we could solve them. What do you see as the different opportunities, different solutions?
And in bringing the whole team, our junior developer was able to have context and a foundation for understanding what we were doing. Because I think a lot of times in these architecture review meetings, they're like, how can we minimize the number of meetings that people are in? And they're like, only bring in the people that will have feedback and insight and concrete suggestions. They're like, only the senior developers.
But in reality, what you're doing is you're preventing junior developers from learning about that process of building things. You're starting them off on a foot behind everybody else because your senior developers have seen the architecture. They had the discussions. They know what they're building, and your juniors don't.
Kirk: It's a nice way to build mentorship simply into your processes that you're already doing instead of making mentorship something that is tacked on as an extra. It just becomes part of the regular workflow. That's a really good idea. I'm going to have to remember that for the next time that I'm in a position where I am running a team.
Chael: Yay.
Kirk: Because that's a really good insight.
Chael: So I really think that when you're building systems and team processes, as much as possible, you want to make habits and systems versus trying to keep things in your head. This actually reminds me of something that my best friend's husband said. He said to me...and this completely changed how I even looked at the world. He said, "You don't decide what you're going to eat when you're standing in front of the fridge.
Kirk: [laughs]
Chael: When you open up the fridge, and there's a frozen pizza in there, and you're tired, and you're exhausted, you're going to have a frozen pizza. There's no other result from that. You actually decide what you're going to eat at the grocery store. You have set up the situation. You have set yourself up for future success when you're in the grocery store and when you're picking out what you're going to eat."
Kirk: Very true.
Chael: When you're in front of the fridge, you can be like, oh, I want to eat healthy. I want to do all these things. But you're hungry, and impulse is going to guide you.
I can say as much as I want. Like, I want to be a good mentor. I want to take care of my mentee. I can say as much as I want. I want a clean codebase. I want to write tests for everything. If I want to write tests for everything, then I need to report on code coverage. That's going to push me to cover everything with tests.
If I want my mentee to get good experiences out of their mentorship program, then we need to have a setup schedule and cadence of meetings with some format to discuss what they need. And I need to understand what it is that they need and what it is that they are trying to get out of it.
Kirk: That's a really good insight, just the overall concept of not having wishful thinking but of building your system to steer you in a way where you don't need to have wishful thinking because the system is built to provide those things inherently.
Chael: It applies to bias and discrimination as well, like when you're thinking about your hiring system. And people always say like, oh, it's a pipeline issue. We're not getting enough people. I'm like, no, it's not a pipeline issue. It's your hiring panel; it's whose resumes you select. It's where you're posting your job. It's everything.
How you set up that system impacts the candidates who apply. And who you have doing your interviews impacts the candidates who choose to work at your company. I can't tell you how many times I've been to a panel of interviews, and I only interviewed with men. And I was like, oh, okay.
Kirk: [laughs] I'm just thinking about my own experience interviewing for various jobs. And I actually do not think that I have personally ever been interviewed by a woman.
Chael: Wow.
Kirk: Ever. Which I never thought about until you just brought it up, and I had to go back and catalog my history.
Chael: It's important. At one company, I used to do the cultural interview. And this was very deliberate; they always made sure that there was a person of color and a woman in the room when we did cultural interviews. And this guy comes in, and he's interviewing for a manager position. And we're all sat, and we're talking to him. And we're asking him like, "Oh, how would you manage people? What would you do?"
And I don't even remember how this conversation started. I don't know if he offered this up unprompted or what question it was that resulted in this answer. But he looks at us, and he goes, "I would never have a one on one alone with a female report. I would bring in another senior developer to have that one on one with me because I can't trust her." And I'm like, what? What? You're sitting at a table.
Kirk: Wow.
Chael: I'm here, I'm interviewing you, and you're telling me that you can't interview me one on one. And those uncomfortable explanations, those uncomfortable discussions those tend to only come up when there's somebody who would be influenced at the table.
Kirk: That's really interesting.
Chael: So it's important, and companies don't think about that. They don't build it into their systems.
Kirk: I'm still just a little bit speechless trying to put myself in your shoes and hearing those words coming out of somebody's mouth while you're sitting there.
Chael: That interview was over. [chuckles]
Kirk: I'm a little bit flabbergasted. Wow.
Chael: We asked him some more questions. And we politely finished up the time. But that interview was over with that answer.
Kirk: I can imagine.
Chael: We can move to a different topic. [laughs]
Kirk: I want to switch directions just a little bit because time flies when we talk. I mean, this is something that has always been the case. And so before we run out of time, I just want to pull back into Rust.
I know that you have been doing Rust, and you've been working with Aisha on Rust for a lot of months. And Rust is a very, very different language from Ruby. And so, I'm curious on a few fronts. I don't think I ever asked this back when you first started doing it. But why Rust? Why did you guys pick Rust? Start there.
Chael: A lot of languages are using the existing technology that we have. They've got C at their core, or maybe they've got some C++ in there. And they're running on either compilers or interpreters. And then that gets converted into your bare-metal language that gets parsed or somewhere in between. Rust is kind of new in that regard. It runs at the same level as C and C++. But it has modern development tooling. It has fantastic documentation. It's got tests built-in. The error messages are phenomenal.
So I think it feels like something new. It feels like a modern language at a lower, more performant level than we've ever seen before. And that was something that intrigued me because I don't buy into fad programming languages. I didn't hop on the boat with Haskell or Go or whatever the new performant language is. I didn't pick up Kotlin. Because I think that those languages will exist, will continue to exist, will continue to be strong.
But they're not revolutionary. They don't offer something that didn't exist before. And in my eyes, with Rust's new method of memory management, with its low-level but...how should I describe it? It's got low-level speed in a high-level language, and I think that is new. That feels like something that doesn't exist because it's cool.
I'm going to acknowledge it; Ruby exists because it's cool. It's in that category of languages that are interesting and fun but don't offer something new. You pick Ruby because you're like, I like writing Ruby, and I think it's a beautiful language. And I like the way it expresses logic. But if you crunch the numbers on Ruby versus PHP versus Python, you haven't gained anything demonstrable. And that's how I felt about Rust is I felt like it had something that no other language could claim.
Also, the community feels like the Ruby community felt and like the Ruby community feels to me. It feels like this weird and wonderful and accepting place of very passionate people. And I think that's where I like to be. I like to be with people who care about the code that they're writing and are very passionate about it.
Kirk: So one of the things that I've always appreciated about the Ruby community, and of course, as with everything, there are always exceptions. But going back to my earliest exposure to the Ruby community, the Ruby community has always been welcoming and supportive, just as a general rule.
And so what I hear you saying is that the Rust community is like that too, that newcomers can come in and ask the stupid question, you know, in quotes, "the stupid questions," and somebody will point them towards the answer. And that sounds like a really strong quality.
I'm going to plug another community that I'm personally very fond of. That's actually one of the things I like about the Crystal community too. They're very much like the Ruby community in that way. So you've been doing Rust for 9, 10 months, something like that now. Do I have that right?
Chael: Probably. I didn't count. [laughs]
Kirk: How has that voyage gone? That's a long time to be regularly revisiting this language, and you aren't using Rust in your day-to-day paid job, are you?
Chael: I have the opportunity to, but I have not yet taken it. Well, I think. I'm not sure.
Kirk: [laughs]
Chael: Companies, their opinions come and go. I thought we were building our availability engine in Rust, but I may be wrong. Because recently, we've got a whole microservices thing that's coming out, and they're like, here are the frameworks that are allowed. [laughs]
Kirk: So I'm just curious. That's a long time to stick with a language. I know that part of it is the series that you're doing. But it's still a long time to stick with a language that you're not using in some other context.
So I'm just really curious. After all this time, how do you feel about the language? I don't want to put words into your mouth. I just want to hear how you feel about the language. How do you feel about Rust after all this time?
Chael: It's crunchy. It's cool. It offers something new. I like the error messages. The error messages are some of the best I've seen. I like the documentation. I love the book format. I would say that what brought me to Ruby was the community and what kept me here was how pretty the language was and how much I enjoyed writing it. I don't enjoy writing Rust the same way I enjoy writing Ruby.
Rust wasn't optimized for developer happiness, and it shows, but I like it. I've learned a lot about it. I haven't gotten into the Rustonomicon yet. And I'm well known for loving the dark arts. So it's possible that I get into the Rustonomicon and a new love for Rust emerges as they hand me the sharp knives.
Kirk: [laughs] Uh-huh. That makes sense.
Chael: But right now, it's very crunchy. And I've never been a fan of crunchy languages. I will say I like the type inference system. I do like that. I do like Rust's type inference system. I was going to say I normally don't like statically typed languages. But I've learned what I don't like is I don't like pedantic languages. [laughs]
Kirk: You don't like static typing that gets in your way.
Chael: Yes. I never want it to get in my way.
Kirk: Yeah, I think you and I are in agreement on that.
Chael: And it has opened my eyes to the fact that static typing doesn't have to be so burdensome as it was in Java.
Kirk: Yeah, Java's static typing, I think, was very strongly influenced by C. It really shows. And there have been a lot of years since then for people to try other things. And I love how we have this whole new stable of languages coming out that are statically typed.
Even Ruby, in some ways at this point, is falling into this category with Sorbet and RBS, where you can get the benefits of static type. But the typing system, whether it's through tooling or through type inference or whatever the typing system largely stays out of your way until it's time for the typing system to say, "Hey, over here you messed up, and you need to fix this." And that's what I love.
That is the feature that I love is how static typing it's like a whole bunch of specs that you don't have to write yourself. The system writes them for you because it checks a bunch of things. Tell me your thoughts.
Chael: So hear me out, hear me out. Static type checking and the tests it writes for you are literally the most boring tests you could possibly write.
Kirk: That's why people don't write them.
Chael: It's literally this returns kind of. But I mean, that's the bare-bones minimum. When I write tests, I'm like, what is the behavior? What is the return value? I'm not like, does this return a number? I'm like, does this return the correct number? And if I say, "Does this return the correct number?" It probably returns the number, right?
Kirk: Probably.
Chael: [laughs]
Kirk: But I'll tell you from experience from taking Ruby code that in some cases had been running in production for a decade or more and converting it from Ruby to, in this case, Crystal, and all of a sudden, I discover oh, this intermittent crash that I've never been able to figure out I think it was because I had this error here that I just managed to never write an appropriate test for and never managed to find. And the static typing said, "Hey, Kirk, right here. Right here, you've got a problem." And it's that kind of thing.
Chael: I just wanted to say I do like RBS as a hardening step. I think I probably develop differently from most people. Because when I'm writing a method, oftentimes, I'll grab whatever that method currently returns and take a look at it.
For example, if I'm going to return the maximum value in a list, I might start by returning the array and being like, what is this? Can I see it? Can I look inside it? Then I might grab the first value. And then I might work on what is the actual correct value? And returning that.
And I often find that static type checking gets in my way because it says, "You can't return an array. That's the wrong value. This is supposed to return a number." And then I have to go and change the signature, and then I have to run it again. And then I have to go back and change the signature again.
And a lot of times, I have issues figuring out what my data currently looks like and the format it's showing up in. And in those static type systems where it gets in the way, I often struggle with that because it'll tell me, "Oh, you have the wrong type." And I'm like, okay, if you just showed me the data, I would know why I had the wrong type.
Kirk: I think that's where a good type inference system comes into play. Because rather than even having a type signature at the beginning, if you just let the type inference system do its magic --
Chael: Sorry. I'm thinking about Rust. I love RBS.
Kirk: And see, I don't know exactly how theirs works. But that is one thing that in Crystal, I will often write my Crystal code almost exactly like I write my Ruby code initially. I won't put in any more typing than the absolute minimum because there are certain things that you have to type that it can't guess. There's no way for it to guess and know.
But outside of that, I leave things completely untyped while I'm developing because it does give me that freedom to play around and to guess and to figure things out. And then once I have it locked down, then I can go put the type signatures in because not only does it then serve as a form of documentation, but it helps make sure that when I come back, and I change the code later, if I break something, it'll help me catch it.
Chael: Yeah. I 100% agree with you. That's the nice thing about RBS is that it's optional, and you can put it in at the last minute. I love it so much.
Kirk: And RBS typing in general, whether it's Sorbet or RBS, coming back to Ruby, is one of those things that once we have static types, then it opens up a whole world of language optimizations that didn't really exist beforehand.
And I think we're seeing that in some of the stuff that is happening with Ruby right now. Some of the stuff that we're going to be seeing getting a lot of attention in the coming year is because things like Sorbet and RBS now exist and can let the code get insights that it didn't have before, so then it can optimize before.
And I would keep talking for way longer than we're supposed to talk. But I've already gone longer with you --
Chael: We're already out of time. [laughs]
Kirk: Yeah, I've already gone longer with you, honestly, than I've ever let myself go on one of these before. So I think we should probably start wrapping up.
And so I will just turn it back over to you here for a minute. If there's anything that you want to mention, that you want to point people to, anything that you want to put out there before we wrap up, now's your chance.
Chael: I regularly stream at twitch.tv/chaelcodes. I like hanging out there. Come chat and say hi. Tell me that you heard me through the Polyglot and that you didn't know that I was a cool person. You just thought I was a cool Polyglot host.
Kirk: [laughs]
Chael: And I will just be thrilled, like, over the moon. [laughs] The other place you can find me is Twitter and YouTube. I'm taking a little bit of a Twitter hiatus right now. I'm just tired. I'm hiding out on Instagram because Instagram just has pictures of my friends and recipes on it.
Kirk: [laughs] That works. That works.
Chael: But yeah, I also have a YouTube that I never update. And that's pretty much it.
Kirk: [laughs] Well, thank you so much for joining me. This has been a lot of fun. For everybody who's listening, thank you for listening to Rachael and I here on the Polyglot Show. You can find us on Twitter @PolyglotShow. This is Kirk Haines for The Relicans. Thank you and catch us next week. Bye-bye.
Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.
Top comments (0)