34: Bringing Types to Ember with Chris Krycho

Robbie Wagner: [00:09] Welcome to Whiskey Web and Whatnot. It's been a little bit since we've had an episode. We mentioned a couple of episodes ago, I don't even remember when, and we recorded that, that I was having a baby. And was going to be gone. We're back now. We since have.

Chuck Carpenter: [00:24] Did it hurt?

Robbie Wagner: [00:25] No, it didn't hurt me.

Chris Krycho: [00:27] That was the joke I was going to make.

Chuck Carpenter: [00:29] Yeah, we had a baby is what you're supposed to say. You're still learning. We had a baby. Not me and you, but you and your wife.

Robbie Wagner: [00:36] Yes.

Chuck Carpenter: [00:37] You and your partner. Yeah.

Robbie Wagner: [00:38] I mean, political correctness is never my strong suit, but anyway, yeah. Charles. Charles William Carpenter III, the third. My co host, as always. And our guest today, Chris is it Krycho?

Chris Krycho: [00:49] You got it right.

Robbie Wagner: [00:50] Cool.

Chuck Carpenter: [00:51] Krycho. I was like, Krycho? Kraken.

Chris Krycho: [00:57] Krycho.

Chuck Carpenter: [00:57] Yeah, Kraken.

Chris Krycho: [00:59] It's okay. There are people I've known for half a decade around the Ember community who still can't get it right, who go with Kry-Ko every time i'm like, nope, it's Cho. It's Krycho. It's okay.

Robbie Wagner: [01:09] Chris, do you want to tell people just a quick couple sentences about who you are and what you do?

Chris Krycho: [01:15] Yeah. So, I am currently a software engineer working at LinkedIn, one of the leads for the flagship web app there, which is what most people think of when they think of LinkedIn. We have a bunch of other nontrivial apps as well, things for recruiters and businesses and LinkedIn Learning and all sorts of things. But the big, big one is the flagship app, and I'm one of the tech leads for that. I'm also a dad, a husband. Those things are more important than my day job. But when I'm not doing those things, I run, I compose music. Sometimes I drink whiskey. So I have some here as a courtesy of these people, which is fun. I don't normally do that at 3 pm, but it's 3 pm here, and I'm on a Whiskey web and whatnot, so I couldn't skip it.

Chuck Carpenter: [02:07] Yeah. It is almost required for anyone. Maybe if you were as famous as Kent C. Dodds, we'd let it go. But since you're Krycho you have to drink with us. It's 2 O'clock for me, so I feel your pain.

Chris Krycho: [02:19] It's early.

Robbie Wagner: [02:19] Yeah, it's five here, so.

Chuck Carpenter: [02:22] Yeah. Somewhere always is somewhere, isn't it? That's what they say.

Robbie Wagner: [02:25] What can you do?

Chuck Carpenter: [02:26] Let's talk a little bit about this whiskey. This would be the Old Forester 1920, Prohibition Style. Although Robbie, you took the notes on it, so I think maybe you should talk about it.

Robbie Wagner: [02:35] Yeah. You want me to chat about the whiskey for one of the first times ever?

Chuck Carpenter: [02:39] Yeah.

Robbie Wagner: [02:40] Yeah, so this I found out the Prohibition Style is not just hype. It was actually made all the way through Prohibition. The Volstead Act of 1920 allowed six distillers to actually continue distilling for medicinal purposes during Prohibition.

Chris Krycho: [02:58] So this is medicinal whiskey.

Robbie Wagner: [03:01] This is stuff like Churchill would probably drink because I know he had a card for, like, he could drink anywhere during Prohibition.

Chuck Carpenter: [03:07] Right. Strange how that went.

Chris Krycho: [03:09] Churchill.

Robbie Wagner: [03:10] Yeah. When he would travel.

Chris Krycho: [03:11] Or Roosevelt.

Robbie Wagner: [03:13] No, Churchill.

Chuck Carpenter: [03:14] Churchill. He had a pass as, like, a point. Okay. Yeah. That's interesting stuff. So, yeah, you would use it for, like, a cough or a light cold, things like that.

Chris Krycho: [03:24] That does actually work. It is good for that.

Chuck Carpenter: [03:27] Yeah. As a Kentucky native, you learn that it's also good for babies if they are teething. That's what we used it for.

Robbie Wagner: [03:37] Sure.

Chris Krycho: [03:37] Throw a little on your finger.

Chuck Carpenter: [03:39] Yes. Very small amounts.

Chris Krycho: [03:41] Only a little.

Chuck Carpenter: [03:42] Don't let your baby chug the bottles.

Chris Krycho: [03:43] Let's be very clear.

Robbie Wagner: [03:46] Everything during Prohibition had to be bottled. I said bottled. I didn't mean bottled barrels. Put in the barrel at 100 proof. And then so, this became 115 proof after aging. Its mash bill is 72% corn, 18% rye, and 10% malted barley.

Chuck Carpenter: [04:03] Yeah, that's all I got. The corn is strong in this one. Okay. I'm going to do a little maple syrup on the smell. Yeah, it's got some hug, I think.

Robbie Wagner: [04:16] Yeah, it's a big bear hug.

Chuck Carpenter: [04:18] You gotta chew it first. Come on. We were taught chew your whiskey.

Robbie Wagner: [04:22] I forgot about the technique.

Chuck Carpenter: [04:24] We're in Nashville.

Chris Krycho: [04:25] Get the mouthfeel a bit.

Chuck Carpenter: [04:26] Went to Green Brier in Nashville. I've been to a lot of distilleries. This is the first place that told you to chew it so that you activate your salivatory glands. Get it, to, and then your next year to be able to taste a little better. Yeah.

Chris Krycho: [04:39] Which I think works. Today I learned.

Chuck Carpenter: [04:42] It's the only thing I'll ever teach you in life. I'm no staff engineer at LinkedIn, but I do know something about whiskey.

Chris Krycho: [04:52] It's probably good. That's not a qualifier for knowing something about whiskey. You're not allowed to know unless you reach a certain rank at a certain company. Seems unhelpful.

Chuck Carpenter: [05:03] Yeah. Like Master Distiller at Four Roses. Then you get to know something. That's it.

Chris Krycho: [05:08] Yeah. Then you get to know things.

Chuck Carpenter: [05:10] All right, I'm good. Yeah. I definitely feel like a leathery bit on the finish. A little, maybe I want to say like orange rind, citrus rind, something like that. Like that bitterness in there, too, for me.

Robbie Wagner: [05:25] Yeah. I would describe it as like a very bourbony sweet, classic bourbon on the initial taste, then tons and tons of alcohol, and then the punch of the rye at the end. You get a little bit of spice at the end.

Chuck Carpenter: [05:40] Yeah.

Chris Krycho: [05:41] Gives it just a little heat on the back end of it. That was what surprised me when I first tasted it, actually, is it starts out very sweet, and it ends not sweet at all.

Chuck Carpenter: [05:54] Listen, this is medicinal bourbon.

Chris Krycho: [05:57] You don't want it to taste good going down.

Chuck Carpenter: [05:59] A spoonful of sugar.

Chris Krycho: [06:00] You want it to burn your throat.

Chuck Carpenter: [06:02] Exactly. Whatever's in here, let's just get rid of that. Burn it up. Probably going to have some heartburn. Take care of the rest. Sounds right.

Robbie Wagner: [06:09] Yeah, but it.

Chris Krycho: [06:11] it's good.

Robbie Wagner: [06:11] It's good. Yeah, I enjoy it. So we do a tentacle rating system, if you're not familiar, Chris.

Chris Krycho: [06:18] I am not.

Robbie Wagner: [06:19] It is one to eight tentacles. One being the worst ever, eight being like the best possible whiskey. And I think I would give this one a seven. I'm a pretty good fan of this one.

Chris Krycho: [06:30] Pretty positive.

Chuck Carpenter: [06:31] Yeah. I mean, I am coming into this bias because I have had this before, perhaps more than once, and I like it. It's my favorite of their, so they have, I don't know, four or five different ones that are recipes from different times in their history. And this one is by far my favorite ones. My go-to would grab, given those choices. So it's a solid seven to eight for me. It's like pretty great. Especially the price point. Somewhere around $60 bucks.

Robbie Wagner: [06:57] 8 was mentioned.

Chuck Carpenter: [06:58] I know.

Robbie Wagner: [06:59] The first time ever.

Chuck Carpenter: [07:00] I think it's time to let the no-fully identified cephalopod to branch out. All of them. So let's just say I'm going to give it an eight.

Chris Krycho: [07:13] Alright.

Chuck Carpenter: [07:13] Yeah, I like it. You should buy it. $60 bucks. It's good.

Robbie Wagner: [07:17] Chris, what are your thoughts?

Chris Krycho: [07:18] Do I have to give a rating?

Chuck Carpenter: [07:20] Yeah. Do you want to opt-out?

Chris Krycho: [07:22] I agree that you would probably enjoy it. If you like whiskey. I don't know if I could give it a seven or an eight, but some of that's because my tastes run to sweeter, and the back end on it is good, but it's not going to fall into one of my favorites of all time. It's going to be more like, yeah, I'll have that on the rocks occasionally kind of drink. So I would probably put it in the four to five range. Not because there's anything wrong with it, but just kind of a solid middle-of-the-road good. Didn't blow my mind.

Chuck Carpenter: [07:54] The sage advice I was given once by a retired tour guide at a distillery was the best whiskey is the one you like. So if that's a $300 or whatever, or if it's at the time, Weller was only like $20 $25. It was like, if it's $20, Weller, then that's great. He said in that accent too, so it made me believe him more. What is your seven?

Chris Krycho: [08:19] That's a hard question. Probably my seven would be the Glenlivet 14 year. Just a really sweet highland scotch. And it's very drinkable. Got a lot of floral to it. Very good. If I'm going to just grab a random glass on a weekend evening or whatever, I'll probably grab something like. I don't know. I love a good Four Roses just for a very baseline, but I wouldn't call that a Seven. I'd call that like my six. It's just like this is not expensive. This is very solid, very reliable. I know exactly what I'm getting every time. It's good.

Chuck Carpenter: [08:55] Yeah, I love a Four Roses Single Barrel. You can pick it up at Costco for like $35 bucks. You're like, yes, why wouldn't I do this?

Chris Krycho: [09:03] The value for price of taste to price ratio there is about as high as I've found anywhere. It's very good.

Chuck Carpenter: [09:12] Yeah, I agree with that. It's a beautiful property, too. If you ever find yourself, have you been?

Chris Krycho: [09:18] I have not, but I have heard that.

Chuck Carpenter: [09:19] Yeah. If you find yourself in Kentucky for whatever reason, if not the Bourbon Trail, then I would suggest dashing off for like that and a couple of others.

Chris Krycho: [09:30] Noted.

Robbie Wagner: [09:31] Do they have more than Four Roses on the property? They just keep four.

Chuck Carpenter: [09:35] They murder the rest of them and keep only the four strongest roses. There's a rose battle. Battle of the roses or whatever. Isn't that thing? I don't know.

Chris Krycho: [09:44] Sounds right.

Chuck Carpenter: [09:46] Race of the Rose runs at the Derby. When you win the Derby, it's actually the big rose. I don't know. So there's some sort of rose analogy there that I'm losing. We should probably talk about tech things before it goes down.

Chris Krycho: [10:01] Yeah, the terrible.

Robbie Wagner: [10:02] Well, before we get there, I have a very important question. So we've had a lot of Chris's on. Over half of them have been not actually named Chris.

Chris Krycho: [10:10] No, I'm a Chris. Okay. I'm actually Chris. But now I want to know who wasn't actually named Chris. I'm going to listen to all the episodes.

Robbie Wagner: [10:18] Runspired is not Chris. Who is the other one? Chris Manson is not Chris, either.

Chris Krycho: [10:24] So on the Manson and Runspired episode, you had two Chris's who aren't actually Chris's.

Chuck Carpenter: [10:29] Right.

Robbie Wagner: [10:30] Correct.

Chris Krycho: [10:31] Lies all the way down.

Chuck Carpenter: [10:33] It's called marketing. It's not lies.

Chris Krycho: [10:35] In one of the Discord chats during Ember conf this year, somebody made the joke, is LinkedIn taking over Ember? And we all said, no, of course not. And then somebody said, the truth is the Chris's are taking over Ember. And we said that might actually be true. There are many of us.

Chuck Carpenter: [10:55] There are, yeah.

Robbie Wagner: [10:57] So anyway, that kind of brings me some of my next things. I have been out, as I mentioned, we had a baby recently.

Chris Krycho: [11:06] Good job.

Chuck Carpenter: [11:06] There you go. Excellent.

Chris Krycho: [11:07] That's how you say it.

Robbie Wagner: [11:08] So I missed Ember conf. I missed kind of this whole TypeScript core team being announced thing. Tell me about how that came about. Like, where did the TypeScript core team come from?

Chris Krycho: [11:21] So the best way I can summarize that is to say the Ember TypeScript core team. And I always have to differentiate very clearly there because there's the TypeScript core team, which builds TypeScript, and then there's the Ember TypeScript core team. We probably should have just stuck with Typed Ember. The Ember TypeScript core team is just the Typed Ember team, which at present our, membership consists of Dan Freeman, James Davis, and myself. Historic emeritus members would be Derek Wickern and Mike North. And I make a point to call them out because while they're not people who are ever going to show up on the list of official emeritus members on emberjs.com, we wouldn't be here today without the work that Derek did in the first six months in particular of the kind of team forming and then the work that Mike did over the course of especially 2019. 2018 into 2019. For example, the fact that we have all of the imports for types live in actual modules rather than just one giant global thing on the TypeScript side that was Mike's work. He did the work to mirror all of the stuff that we did in Ember itself to make modules be a thing into the types. The thing that fell out of that over the last half-decade, and maybe that's a good place to start is to say that half a decade ago, in early 2017 I had been looking around and poking around at what we could do to bring types to Ember because I was one of the handful of engineers on an Ember app at a scale-up phase startup at the time, Olo. And credit to Olo for funding a lot of this kind of work as we went, and I experimented a bit with Flow which was Facebook's type-checking system for JavaScript and it had a number of features at the time which TypeScript didn't that allowed us to represent some of the old school shenanigans that existed in Ember, in particular, wanting to be able to somehow represent how get and set work and how mix ins work and all of those things key property look up and whatnot in kind of Ember classic and then TypeScript 2.1 came out in late 2016, and it had these key features if you want to go look them up afterward. Key of and mapped types, which let you say hey, I want the types which represent the keys of this object, or I have a type which represents a mapping from one object to another. They give us enough tools to actually start representing some of the old-school Ember shenanigans of these keys, generate these computed properties, or this maps to this service, or whatever else. So I started working on it. Ember CLI TypeScript existed at that point, but it was not usable in an app. It existed as like this would be a good thing for someone to do, and locks had commit bit on it and said well if you want to do it. Come work on it, and so I div and then RWJ Blue Robert Jackson helped me when I inevitably had problems with the Broccoli TypeScript pipeline and got me unstuck and I just started working on it and telling people I was working on it and other people were also interested so sort of unintentionally we formed a group of people working on it and we built a Typed Ember organization on GitHub to maintain that to build Ember CLI type script to get types on a package called DefinitelyTyped on GitHub, which is GitHub's repository for maintaining third-party definitions for packages. And we can talk about in a little bit why that might be necessary. I think that's an important thing for people to understand who aren't deeply, deeply familiar with this space like I am at this point. And we just kept iterating on it and iterating on it and iterating on it. And over the last couple of years, first Mike North and then I were working on how do we solve semantic versioning for TypeScript because TypeScript doesn't do SemVer at the compiler level. They just say all changes to a compiler are breaking changes. So no, we're not doing that. Ember doesn't think that way about semantic versioning even a little bit. And how do we bridge these two worlds? And at the same time, kind of in parallel, Dan and James were working on a tool called Glint, which lets you have Type checking for your templates, which is really nice. JSX has had this since late 2015, courtesy of TypeScript shipping built-in support for it. Vue has had it via a language server and tools since 2018 or so cells got good support, and I want to say late mid to late 2020. So we recognize this as a thing, but it's hard. You have to turn an of our templates into a thing the TypeScript understands. And all of that community-driven work ultimately became one of the most popular add-ons out there. Some of the most popular ways of working out there. If you go look at Ember Observer, it's Ember CLI Babble, and then Ember CLI Type JavaScript are the top two add-ons. And if Ember CLI Babble happens to drop a little bit because it hasn't had a release in X months, then Ember CLI TypeScript will drop or vice versa. But the thing that fell out of that was a recognition that TypeScript support is pretty essential to modern web development. Even if you're not using TypeScript in your web app, you are using TypeScript because under the hood all of the tooling that exists across the ecosystem more or less uses TypeScript for things like providing autocomplete and go to definition and refactoring and all of that, even if you're just writing JavaScript. The big exception here would be the IntelliJ JetBrains IDEs. They provide completions their own way. But everything else from Vim to Visual Studio. And I didn't say Visual Studio Code. So obviously, that's included. But literally from Vim to Visual Studio. The big ginormous thing for .Net stuff from Microsoft uses TypeScript types under the hood to provide autocomplete and go to definition and all of this stuff for Ember these days. And for everything else, for that matter. So the core team, the framework team, recognizing that and recognizing that it's really important to have someone with that representing that particular bit of expertise. I say it that way on purpose because I'm a member of both the framework teams and the TypeScript teams, but I'm not a member of the framework team. As a representative of the TypeScript team. I'm on the framework team as a representative of kind of the TypeScript concerns, and I am also on the Ember TypeScript team. We think about that pretty intentionally. It made sense because this is really key to what we want the experience of the upcoming Ember edition Polaris to be. We wanted to have first-class TypeScript support because we want Ember overall to be thinking about the ecosystem it participates in, as this is what we target, this is how we think about the world. We layer on a very thin layer of Emberisms rather than having the historic pattern, the historically needful pattern, but the historic pattern of lots of custom Ember special sauce. At the same time, we also recognize from a governance perspective that the Typed Ember team has been doing this with no particular official support or in premature or anything for five years. And it would not make any sense whatsoever to say, now we need to form a TypeScript team. No, we have one. We've been doing this for five years. We are here. We don't need supervision or a new team or anything else. This is the team that's doing it. So it was more a matter of recognizing this is the team that owns these concerns as we walk toward official Ember TypeScript support. That's the big picture. Summary I also just talked for like six minutes straight, so questions, comments, etc. Now welcome.

Chuck Carpenter: [18:56] No, I think this is good. I think that that helps us. Well, I mean, we have some notes, but we make up most of it on the fly.

Chris Krycho: [19:01] Oh, yeah, same.

Chuck Carpenter: [19:04] So Robbie frequently likes to be like, okay, but what about the opposite, right? So my thoughts here on this is that you're a subject matter expert in implementing this in enterprise-level applications, on down, that kind of stuff. When's the time I know you were saying like, whether you do it or not, you're using it, but when is the time that this TypeScript isn't necessary? When would you say, like, it's egregious for your project?

Chris Krycho: [19:30] The answer to that is maybe subtler than is comfortable for a lot of folks. It might be surprising coming for me. There's no project in which TypeScript is necessary. There are very few projects in which it might not be useful, but that's going to depend on your team, your coding style, your mental frame, your background, etc. The riff on some of the conversation that the Chris's, Manson, and Runspired had Chris Runspired is not his name. But maybe it should be.

Chuck Carpenter: [20:01] Maybe it should be. He's going to be like Prince. He's changing it. He's not Runspired anymore.

Robbie Wagner: [20:08] That's his new Twitter, not Runspired.

Chris Krycho: [20:09] Twitter, not Runspired. It's important to recognize that there are some costs to adopting TypeScript in terms of training, in terms of leveling up your team, etc. Now I think if the project is going to exist for any length of time at all, those tend to pay for themselves from that point of view. But they exist. They're real. I'm not going to pretend that they're not. And the transition from an untyped language, if you're only background untyped, is maybe pejorative sounding, but I just mean no statically checked types here a dynamically typed language to a statically typed language. So if you're only coming from JavaScript in Ruby or JavaScript in Python, without Sorbet or any of the various Python type-checking systems into TypeScript, you're going to have a learning curve there because it's a different way of thinking about things. If you're writing a throwaway script, you may not need TypeScript, and it might be a mild impediment. It's not for me because I've been writing TypeScript for so long that not having types feels like being punched in the face all the time by the computer. Why won't you tell me what I missed? I made a typo over here. Why didn't you tell me? I feel very grumpy now. Well, that's not everybody. And even beyond that, I think there are cognitive style issues that mean a good example of this would be Stefan Penner. He is a guy who works repl first, who likes the kind of lisp view of the world where I'm working with data in a very unstructured way in a repl, and that feels very natural to me, and I can work and iterate very quickly that way would be how he would describe that to me in conversations we've had. I don't work that way. I've never worked that way. I've always even back when I started my career with Fortran and C, which, yes, is actually how I started my career. I've always thought types first. That seems to be pretty deeply baked for a lot of people. I've talked to a couple of friends of mine, not in the Ember community, Greg Vaughn, who these days does mostly Elixir but did a bunch of closure and other things over the years, and Ruby. Glenn Vandenberg who's pretty well known. If you go looking up his keynotes, you'll see they're well-watched and for good reason. He's brilliant. Also lots of Ruby closure, et cetera. The way they talk about how they work when I talk to them is just very different from the way I think and work. And so, I think it is worth acknowledging that, in most cases, TypeScript is not necessary. LinkedIn, for example, has a millions of lines of code base that is the flagship web app that until a few months ago had zero TypeScript in it. And we're getting zero benefits from Typescripts directly because we weren't wiring up the Ember types or anything else. And it works, right? It's a very valuable web property. It's one of the largest social networks in the world. We clearly didn't need TypeScript. Now we look at it, and we think TypeScript is going to give us some benefits, far more than the cost of training and adoption, and migration. So we're doing that, we're converting now, but you don't need it. And there's a tendency among enthusiasts for typed programming, and especially for typed functional programming, and I count myself a type functional programming enthusiast, to say that it's irresponsible not to use types, et cetera. And for 99% of things out there, I think that's bunk. I think you should choose a working style that works well with the cognitive style of your team, with the expected overhead, with the expected churn rate, etc., etc. Types provide a lot of value when you're transitioning between people because it's much more explicit about what the contract is here. If you're doing purely dynamic types, you end up kind of trying to do that via docs sometimes. If you're disciplined, maybe, hopefully, yes. But it can be really hard when you're looking at some particularly dynamic piece of code to know, what the heck does this intend?

Chuck Carpenter: [24:00] All right, hold on. And may I give you a quick pause there? Because I'm getting old.

Chris Krycho: [24:05] Yes.

Chuck Carpenter: [24:06] And I will forget things.

Chris Krycho: [24:08] Please pause me however often you need to.

Chuck Carpenter: [24:10] Yeah. And now, I'm up to four points that I want to interject into. First of all.

Robbie Wagner: [24:14] I have points as well.

Chuck Carpenter: [24:16] Are you saying that Microsoft hasn't required you as your mothership to use TypeScript?

Chris Krycho: [24:23] 100% No, two things that folks should know.

Chuck Carpenter: [24:25] That was more of a joke. I'm just going to tell you.

Chris Krycho: [24:27] No, it's actually really important. And I've had some interesting conversations with VPMs, and some of the tech leads for TypeScript at Microsoft. They on the TypeScript project in particular. Do not push anybody in Microsoft. There's no pressure in Microsoft itself. There's no pressure in any of Microsoft subsidiaries, which at this point include GitHub and us and.

Robbie Wagner: [24:49] Everything.

Chris Krycho: [24:50] Via GitHub and NPM. There's no pressure to use TypeScript. They want TypeScript to be so good. There you go. That teams adopted organically.

Robbie Wagner: [24:58] Yeah, spoilers. That's what's happening. Well.

Chuck Carpenter: [25:01] And that's it. So that is just like, let's just have a good product, and people will want to have uptake even internally. So that's a good one.

Robbie Wagner: [25:08] Can I say something real quick?

Chuck Carpenter: [25:09] Okay, sorry.

Robbie Wagner: [25:10] I just wanted to say.

Chuck Carpenter: [25:11] I'm definitely going to forget at least one of them.

Robbie Wagner: [25:13] We don't have to talk fully about this right now. You can come back to your point, but didn't Microsoft open the proposal for Types in vanilla JS? Yes, and that's different than Typescript. So it's like, again, not that they didn't believe in types, but it doesn't have to be TypeScript.

Chris Krycho: [25:28] That's right. The idea is that the syntax they proposed would be usable by TypeScript or Flow or anything else. It's basically the same way that Python, I think in Python three six or three seven made the syntax for type annotations legal Python syntax and in regular Python is just completely inert. It does nothing, and you can wire up a type checker on top of it. It's the exact same idea, and it lets you have type annotated JavaScript, the TypeScript or Flow or whatever could provide type inference and everything else based on, but that the browser could just run it and basically just treat those as comments and throw them away.

Robbie Wagner: [26:05] Right. Sorry, Chuck, you can go back to whatever you're saying.

Chuck Carpenter: [26:08] It's hard to say what was going to happen there originally. Oh, you were talking about like dynamic, and the other way to do it is essentially have good documentation, go down the JS doc path, and make it very verbose in different ways without enforcing that. But yeah. I was going to say I think that that is probably one of the like, even with smaller projects or smaller teams where you might say like. Oh. We don't need this enforcement. But it's like, in a way, self-documented code because, as practitioners, we know how to read this, and we know what that means, and you can sort of like trace all of that without having to say this function expects Arg number. Actually you're saying it's Arg number, so I definitely agree with that in that sense. You've mentioned a couple of different times. So are you like former Python person?

Chris Krycho: [26:55] I've done Python a long time ago, but I mostly I am a programming languages enthusiast so I watch the space pretty carefully, and I have professionally written C, Fortran, PHP, JavaScript, Python, JavaScript TypeScript and Rust. I have Unprofessionally also written Swift and Ruby and Haskell and Elm, and probably at least one or two others that I'm forgetting. So I watched this very carefully and particularly when it comes to type systems and things like that. Ruby's Sorbet, Pythons Pi types, etc. Are obviously very interesting as kind of parallel efforts to what we're doing with TypeScript in the JavaScript ecosystem.

Chuck Carpenter: [27:44] Interesting. How many of those personal projects or personal learning experiences happened before versus after you had children?

Chris Krycho: [27:53] That is a very good question. Roughly half and half. I did more of that, to be fair when my children were younger as they've come into kind of elementary school age, which is the age they are now. They're turning ten and eight this month.

Chuck Carpenter: [28:06] Oh wow.

Chris Krycho: [28:07] I've had much less time for that because I am going to piano recitals instead, and it just makes a lot of sense. And their bedtimes are later. Our family times run longer. You know when your kids are in bed at seven and don't get up till seven? That's some time between when they go to bed and when I go to bed. Now they go to bed more like eight to eight. Like they get in bed at eight, and they don't go to sleep till 8:30 if they go to bed when they should, and maybe it's nine, and they might be out, and it's a lot fewer. Hours when I'm still awake.

Chuck Carpenter: [28:38] Yes.

Chris Krycho: [28:38] Okay.

Chuck Carpenter: [28:39] That actually brings me to another question. As a new father, what advice would you give Robbie?

Chris Krycho: [28:45] That's a really interesting question. In general, I only give people two pieces of advice there, and one of them is, I'm a Christian, so, like, I think that following God and teaching your kids to is important. And the second piece of advice I have is expect change. And literally, any other advice I can give you is useless pretty quickly because A, every kid is very different. We have two kids, and they're polar opposites of each other. But I have a friend who had seven kids, and he and his wife like to say that all of their children are completely opposite of all of each other. And yes, that means you're talking seven-dimensional geometry. But in my experience with my own and other people's kids, it's accurate. And so you can't really generalize other than be patient and expect change. And they expect change part is the big part because you just start getting comfortable, like, okay, we've got a rhythm down. We know what we're doing now. We kind of have a feel for this. And they change, and you repeat that process over and over and over again. Sometimes you get like three months where you're like. We kind of got this now. And then they changed. We always ask our kids bigger inside. And they say yes. And you can tell sometimes when they're newborns, you can tell, oh, they stopped sleeping for a week. They just went through some kind of big mental transition. And you can tell these days at eight and ten almost. They're more like they're extremely moody for two weeks. What is, oh, right? They're going through some mental transition. Okay. Get to learn how to do this over again. Every time.

Chuck Carpenter: [30:17] There we go. Excellent. Yeah.

Robbie Wagner: [30:19] I think we maybe mentioned it before on another podcast, but I think a common thread that's kind of similar is everyone says all advice, just forget all of it because it doesn't matter. It's basically like. There's only so much you can do, and you're going to figure it out. It's fine.

Chuck Carpenter: [30:37] Yeah. If only human beings were just like carbon copies. And then it would be like. This thing always works, but.

Chris Krycho: [30:44] Not how it goes at all. No, you're like, you love hot dogs. You love hot dogs. Here's a hot dog.

Chuck Carpenter: [30:50] I hate hot dogs.

Chris Krycho: [30:50] I don't want this hot dog. I hate hot dogs. Throw it on the floor. That is the sort of thing.

Chuck Carpenter: [30:56] Oh, yeah.

Robbie Wagner: [30:58] So, to circle back for a minute, I think the only problem I have with TypeScript consistently is when the add-ons or things I'm using do it wrong. So I have like 50 TypeScript errors, and I can't fix them because they're in. I could PR in The Fix, but they're in another library, and I'm a novice at TypeScripts. I don't really know. I think there's like a flag where you can say ignore stuff from packages, but I think when I do that, it breaks more stuff somehow. Do you have any advice on what to do in those kind of situations?

Chris Krycho: [31:36] Yeah, so I think there's two things. The first thing I would say actually is it's worth noting the exact same dynamic holds for runtime code. It's easy to see it sometimes because it gets surfaced in your build when you're doing it with TypeScript, and in some ways, that's nice, right? You know about the problem sooner rather than being like oh, my app just blew up in prod, and it's because of something my test didn't happen to cover that came from a third-party add-on ouch. At least when it blows up in the type checker, that happens before you get that far. But the other thing I'll say is one skip lib check, which is the flag its compiler options skip lib check, which just says don't check the types of the libraries that I consume themselves, only check, and this may be where things get messy, only check the cases where in fact I'm explicitly using a type from there. So when you use that flag, it doesn't say go ignore all the types from all my dependencies. It says don't additionally go check all the types for all my dependencies. Only check the things that I'm actually explicitly using on and following that thread. And that's a really important rule because otherwise, if you turn that flag on, TypeScript would say haha, I don't know what anything is. Do what you want, bro. And that's not actually a very helpful way for TypeScript to treat you. You wanted to actually check the things you are using even in that scenario. Now in the situation you've described, I expect what's happening is you're saying hey, don't give me the errors from the library itself, and so TypeScript is skipping that part of its checking, and it's been showing you only the parts where there's a problem with what you are directly using. But if the library has done something wrong, then that can end up cascading into all of your types and all of your usages of it, and it can trigger many more errors that show up in your app as a result. So the best thing to do there is the same thing you would do with a runtime bug, and that would be file an issue and say hey, I'm having this problem with your types and maybe reach out in the topic TypeScripts channel and Discord or raise something in Discourse for Ember or whatever, but more generally getting in contact with the maintainers. But I'll also say that this problem is a big part of what motivated the work that we did with LinkedIn and as the Ember TypeScript team back when we were just the Typed Ember team on semantic versioning for TypeScript types, because both within the Ember community, and then separately within LinkedIn, totally orthogonally. We're big users of semantic versioning. So LinkedIn, unlike some other big tech companies, where you may have heard that Facebook and Google and some others just have these ginormous mono repos where all the code exists in one repository. There's one kind of global version for any package at any given time. We don't work that way. We have a system that allows us to use semantic versioning, and we have for a very long time. We were doing micro-services and service-oriented architectures before it was cool. And if you're going to do that, you need versioning. You need to make that work. So one of the reasons we invested from the LinkedIn side is that we need this for our own internal stuff when we're publishing libraries, packages, etc. For others to consume. And if you go look at the semantic versioning for TypeScript types specification that we, as the ember community and LinkedIn published SemVer/ts.org, this specifies at a high level what you should think about. It specifies in great detail what it actually means to think about all those concerns, and then it has a bunch of recommendations about how can you actually do this from a tooling perspective to avoid doing to people exactly what you just described, Robbie. Because in the same way that you want your test suite as a library author to exercise the entire API surface of your library and make sure that none of it breaks when you make an internal refactor, you want to do the same thing for TypeScript. And so we've built up a bunch of infrastructure and guidance that lets you do that, that says, okay, you're going to write tests for your types the same as you do for your runtime behavior. And by doing that in a way that reflects how your code will actually be consumed. And running that as part of your CI. And running it against the whole spread of TypeScript versions that you support. Just like in the Ember community. It's normal to run Ember. Try for a library against Ember, whatever you're currently targeting. And maybe some previous LTS's. And current stable and beta and nightly, we do the same thing with TypeScript. And we say, hey, currently we support TypeScript four dot two through four dot six. And when four dot seven comes out. We'll add that to the matrix. One of the things we want to see is for packages within not only the Ember ecosystem but the broader TypeScript and JavaScript ecosystem support that. And that's why it's SemVerts.org, not emberSemVerts.org or something like that. It came out of our work and because of our needs, but it's really aimed at being general guidance for how can you do this successfully if, for example, you're the maintainer of Redux, which is written in TypeScript. And I've had a bunch of really great conversations with Mark Erickson, who is one of the maintainers of Redux, over the last few months because of this work. So the goal is you see that less in the same way that doesn't happen that much with add-ons. Which actually use Ember Try. We want to do the same thing here and just make TypeScript a first class. Well-supported peer dependency that you run your tests against. Including tests that specifically check that you're not hosing your consumers if they're just using your public API. Because that's dumb. Really dumb. I hate it.

Robbie Wagner: [37:13] Yeah, that makes sense.

Chuck Carpenter: [37:14] I like that you're not judging people for not doing that.

Chris Krycho: [37:18] No, I mean, it's hard, right? My tone may have sounded frustrated there, but it's legitimately hard. And nobody had done.

Robbie Wagner: [37:25] Oh yeah.

Chris Krycho: [37:25] Up to this point, the work to say, here's what it actually looks like to do it. And in the same way that specifying SemVer a decade ago really gave the industry a useful tool for saying, here's how we think about this. Here's how to communicate this. And we're not going to be perfect about it, but we establish the terms of the contract, and then we try to uphold them, and sometimes we end up SemVer lawyering, but most of the time we just say, this is what we're trying to keep, and it's fine. Same thing for TypeScript, and people haven't had guidance on how to do that yet. So our hope is, hey, now you have some guidance, and you can follow it.

Chuck Carpenter: [38:00] I don't mistake your tone for anything negative as much as I do for passion. And I suppose like you said, you've described an easy five, six years of effort going into that, so those would align for me in any way. And as soon as you convert Robbie, I believe that it's legit.

Chris Krycho: [38:18] I'll take that as my next project.

Robbie Wagner: [38:21] I don't like when it causes me a lot of extra work, and that's probably just because I'm not that experienced in it. So if there's a thing and I need to find the type of a thing, that's the type of another thing that's extended from a thing that also is a thing that can sometimes be a thing, then I'm like, yeah, and that is tough. And you have like ten lines of just your types and I'm like, okay, that was too much work.

Chuck Carpenter: [38:49] Yeah, well, I also think that that is an artifact of our business type versus what Chris is doing. Like, you are in an enterprise with multiple products, and this is your home, and you get a long time to make that trajectory. Right? We come in for a bit, and we're like, what can we do to make this better for you? Right? Like, business objectives and all that kind of stuff. And sometimes it's like untangled that mess. Is it worth it? No, you guys put it here, so we'll work with that. But the business objective is something else anyway, so we should focus more on that than fixing this. Not really anyone ever tells us to come in and fix types. Maybe it's implementing from nothing or maybe it's just ignore that and do this other thing, but I think that is probably more of what it is too.

Chris Krycho: [39:38] And I think that informs a lot of the perspective that you get. I see folks in consulting roles experience that and articulate that kind of point of view much more frequently. I think the place where you really feel the long-term value of TypeScript is in the long term where you're living with the same code for three years. Four years. Five years versus, and this isn't in any sense of ding on the consultant model. But when the maximum, your engagement normally lasts maybe a year. You're often experiencing more of the pain and downsides of it and much less experiencing the long-term knock-on benefits of it, and you may get some of them along the way for sure. Like the fact that you can do refactoring with higher confidence. If it's a well-done code base, it's really nice, but you're also paying more of those costs, and you're paying the costs on every code base anew. And the other thing I'll say is languages with rich type systems for good and for ill attract people of whom I may have been one at times, who like the interesting type machinery in some sense that's true of all of our programming stuff like the cool way of doing it attracts all of us, right?And we, I think, tend to find that more to people who are new to it. Like the guy who first comes to Ruby after having been in Java, and his look like, look how cool and short and dsltastic I can make this thing. And you're looking at that six months later thinking, I hate everything about this. I get why it felt cool, though, because it is cool. It's really cool that you can bend a computer to your will in that way and that you can bend Ruby as a language to just you wrote a sentence, and somehow it's code. That's super neat. The same thing happens with types and people who first come to TypeScript in particular or other languages with similar expressivity Haskell, sometimes Rust, etc., can get really pulled into that because it is really compelling, and you start thinking about, like, can I nail this down the most perfect way? And you're seven layers deep in type Tetris and not thinking about the actual maintenance burden that imposes on whoever comes next, about whether they're going to be able to even understand these layers of type arcana. I'm sympathetic to how you end up there, and code bases littered with those things can be really, really painful to work with. I have some pity for some of my old colleagues back at Olo because there's some of that there. There's less of it than might be feared, but it's a real factor. And so when you come into a code base like that, it can be really frustrating, and it can be like, what is this and why is it here? And the way I tend to think about it is, in general, you want library code to pick up some of that burden. Library code is allowed to be complicated because it's allowing you to provide a not complicated interface to your end users. But app code shouldn't look like that. App code. You should basically write types on your function signatures, including like methods, but also standalone functions and your classes or your kind of standalone types, what are they? And that should be it. You shouldn't have deep type shenanigans. If you have deep type shenanigans, you're probably overcomplicating what you're doing in your app. You should take a step back and think, if you cannot do that. The last thing I'll say here though is the other thing you often find is people trying to represent what their existing JavaScript code base actually does. And it turns out that when you're writing JavaScript or Ruby or whatever else with no type checker to handle you, you can end up with wild things your code does. And if you're trying to be responsible and disciplined about how you convert and say, I'm only going to add types that actually represent what it is, I'm not going to change how it functions because I'm trying to decrease the risk of this work or whatever else, then you end up with these shenanigans types because your code was already doing shenanigans and it's just a TypeScript just letting you know, hey, this code does shenanigans and you didn't know it, but now you know it.

Robbie Wagner: [43:46] Yeah, I think that's a lot of the problems that I have. Let's Pivot here to tell me about what a first-class component template is.

Chris Krycho: [43:55] First-class component templates is not JSX. That's the first thing I'm going to say about it.

Robbie Wagner: [44:01] Good.

Chris Krycho: [44:02] I'll tell you a secret. I actually like TSX and JSX. Don't anyone come after me with pitchforks.

Robbie Wagner: [44:07] All right we're out of time.

Chris Krycho: [44:08] Yes.

Chuck Carpenter: [44:11] I don't care enough, and I like trolling Robbie.

Chris Krycho: [44:16] I also like the trade-offs we make in Ember. They're trade-offs in the design space to take a step back and explain why that joke might be funny if you're not familiar with it. First-class component templates is an RFC we merged that allows you to write templates in JavaScript files, but not like JSX. So where JSX freely intermixes XML, basically, and JavaScript syntax. What first-class component templates do is say we can now author component templates with our JavaScript, but still in the distinct Glimmer programming language. So still in handlebars templates. And they live in their own discrete namespace bracketed by template tags within JavaScript. So if you're writing a non-class-backed template-only component, you just write if it's a default export. You literally just write template. The HTML tag and then the body of it and then slash template to close it, and that becomes a default export. So your simplest template-only components look more or less exactly like they do in Ember today, with the exception of this wrapping tag and the exception that you'll actually explicitly import using JavaScript module syntax for imports, any things you reference helpers, other components, etc. In the body of that template. So if you write a template where you invoke some component foo, you would import foo from the path to foo, whatever that might be. And this actually came out of a realization when we were trying to do quote-unquote module unification back in the day, where we were going to have this syntax that allowed us to represent more complex file system layouts on disk. And Sam Selikov asked at one point, why don't we just use ES module imports? Because they'll solve this problem, right? And everybody went, huh, that's a really good idea. And then we spent a bunch of time figuring out what it would mean to do that. What does it mean to just reference values that way? Ember historically has used a Resolver which maps these strings to the thing they correspond to. So when you write an angle bracket foo and then some arguments or whatever else in a normal Ember app today, that goes through the Resolver. The Resolver says, what item, what component does the string foo represent? And it goes and looks through the conventional layouts on your disk, okay, my components or any addons, I consume their components, etc. And the idea is, okay, now we're going to just import that and resolve it. We need to solve a bunch of things. So what does that mean? We're not using Resolver anymore? We need to get things from scope, so we need some way to map these in and other considerations like that. So there's a bunch of design work done over the last, really, three years that says what's the actual underlying implementation mechanics for how that works. And if you've used colocated templates since Octane came out, where you can put your template right next to your JavaScript file, that compiles to the same thing that this new first-class component template syntax compiles to, details aren't very interesting. And I'm certainly not going to try to say the actual code on air. I did that when I was doing a Rust teaching podcast. It hurts. I'm not going to do it now.

Robbie Wagner: [47:39] I just want to pause you right there real quick.

Chuck Carpenter: [47:42] Thank you.

Chris Krycho: [47:42] Yes.

Chuck Carpenter: [47:43] You know, we've been drinking.

Chris Krycho: [47:44] It's true.

Robbie Wagner: [47:45] So, will you be able to still do the current way with the colocated templates?

Chris Krycho: [47:50] For now.

Chuck Carpenter: [47:51] Okay.

Chris Krycho: [47:51] And for a few years? The goal is to get everything to strict mode templates. And the reason is that it's way, way, way faster. It's way, way, way easier for all the tools and some of the stuff we're working on. We're going to propose as general things for the JavaScript ecosystem to use. Like we're working right now on a spec that's an extension of JavaScript that Vue or Svelte or, for that matter, React could choose to use if they want. If you've ever seen a GraphQL thing that says const query equals GQL template tag body, we want the same thing we're doing with template tag to work there, where you could instead write const query equals tag like HTML style tag GQL and have the body of that be that or the same thing for CSS. If you want locally scoped CSS definitions like CSS modules, why can't you just write const style equals tag style, some CSS closed style, and have that just work? We think there's a lot of value there, and then you just have that value in scope, and you apply those styles to your class definition right there in your template, which is defined the same way for a template-only component, or if it's class backed, I was going to mention this a minute ago. Instead of having it as a top-level thing, you can assign them locally, which could be nice because you can extract and refactor things. And in a class-backed component, you just put it in the body of the class, and then it becomes the template for that component. So the idea is, at this point, you can reference values that are in local scope. That means if you have some constants, most Ember developers have the very frustrating experience of saying, okay, I have some constant that only makes sense for this component. But to make that work, I need to introduce a backing class. Even though I have no state and no actions here, it would be a template-only component otherwise, but I need to introduce a backing class because I need some way to say this dot that constant. Well, you don't have to do that anymore. You can just write my constant equals one, two, three, write a template opening template tag curly, curly, my constant close curly curly. And it just works. This fell out of our work on TypeScript because Glint, the tool that my friends Dan and James, the other Typed Ember folks, built, either needs to reimplement all of ember's logic for how the Resolver works, or needs you as a maintainer to do that, which is, let me tell you, really fun when you're authoring in JavaScript, by which I mean it's extremely not fun. It's possible if only just in TypeScript. It's more or less actually impossible to do in JavaScript-only environments. Or we could do something way simpler in JUST. It's very complicated JUST, but it's only one thing. Transform those templates into something that TypeScript understands. And if the rest of our system is also something that TypeScript understands, then everything else just works. Go to definition, refactoring, etc. Or all falls out of that. And that means that for both JavaScript and TypeScript users, we can provide that experience. So that you renamed something in your backing class, it just renamed in your template invocation too. Oh, you renamed your argument to this component. Oh, that just updated every call site in your app so that now every place you use it also updated automatically. No more trying to figure out by gripping, doing a search over your code base. We actually did it correctly 100%, even if you're just in a JavaScript app, because we can now use imports and everything else to know statically exhaustively, hey, what is this thing actually producing? So the big idea is to sum this all up. We want to maintain the good parts of having a dedicated templating language. It's actually nice there are trade-offs in that space, but it is actually really nice while also getting more or less of the benefits of having something like JSX where you have access to all of that local scope and everything else and ultimately do that in a way that hopefully, we can turn into a spec that is usable by the rest of the JavaScript ecosystem. That if Svelte wants to use it, or Vue wants to use it, or Apollo GraphQL wants to use it, or whatever that's available to everybody to use and to build tooling on top of that's. The dream.

Chuck Carpenter: [52:10] Got you.

Robbie Wagner: [52:11] Yeah, that sounds interesting. So we have just a few minutes left here, so let's pivot to something not tech related. You said you compose some music. Tell me about that. What kind of music do you write?

Chris Krycho: [52:25] I have written a lot of different kinds of music over the years, but it's all roughly in the kind of contemporary classical idiom.

Robbie Wagner: [52:33] So is it for one instrument specifically like piano, or is it for a bunch of stuff?

Chris Krycho: [52:39] It varies.

Robbie Wagner: [52:40] Okay.

Chris Krycho: [52:40] I have written solo works and chamber works and orchestra works and everything in between. So I started composing back in late middle school. I think 8th grade was the first time I wrote something end to end. And I actually did the equivalent of a music minor when I was in college at the University of Oklahoma a long time ago. When I was there. They did not offer music minors. Now they do. It's kind of annoying because if you look at the coursework that they do for music minors, I would have one, but they didn't do it then. I just had to get special permission.

Chuck Carpenter: [53:11] You should write them.

Chris Krycho: [53:12] Hey, give me a minor retrospectively.

Chuck Carpenter: [53:15] You should write them and say, can I get one? Yeah. I mean, celebrities get it all the time.

Chris Krycho: [53:20] It doesn't actually matter, right? It's not useful.

Chuck Carpenter: [53:23] Still be validating.

Chris Krycho: [53:26] I mostly write orchestral works. Or I may be writing some things for smaller chamber groups in the community around here. I know a bunch of musicians now that I didn't know a year ago who have interesting little ensemble groups that I could be composing for, and I would like to. So if you go to Spotify or Apple Music or whatever, you can find one piece of music that I put up on all of those. It's a fanfare that I wrote when SpaceX launched people for the first time and launched the Crew Dragon demo 1 flight when they went to the ISS. I was really inspired by that because it was really cool that we were actually sending American astronauts to space on American rockets for the first time in a decade. And SpaceX was doing some really cool stuff to make that happen. So I wrote a fanfare for that.

Chuck Carpenter: [54:16] Nice.

Chris Krycho: [54:16] And you can hear the kinds of things I write. And I also have a SoundCloud that's my tweet, right? Check out my SoundCloud. It's hilarious to me that that's the thing that people do. But it is a thing that people do. And I do have one in every place. You can find me online. It's Chris Krycho. So it's SoundCloud.com/ChrisKrycho. Turns out that Krycho, as we alluded to at the beginning, is a unique name. It is literally a unique name. In the case of Chris Krycho, it is a globally unique identifier. There's only one. So I always get whatever handle I always get that handle on any new service because there are no other Chris Krychos literally anywhere on the planet.

Chuck Carpenter: [54:52] No competition there.

Chris Krycho: [54:54] It's kind of nice.

Chuck Carpenter: [54:54] Yeah.

Robbie Wagner: [54:55] Not the same for Chris Garrett. He had to make up his own thing to be Zuraq.

Chris Krycho: [54:59] Zuraq, yes.

Chuck Carpenter: [55:03] That reminds me. I feel like I have been really into Hot Ones over the last few months, and so I probably watch like an episode at least every couple of weeks. And so that's what I was going to say. It's like this camera, this camera, this camera, tell the people what you got going on. If you've ever seen that, that will make sense for you.

Chris Krycho: [55:20] I have not.

Chuck Carpenter: [55:21] You haven't?

Chris Krycho: [55:22] I have no idea.

Chuck Carpenter: [55:23] All right, so I'm going to TLDR you? So it is an interview show. And it's like interviewer celebrity person. They have ten wings incrementally. The wings get hotter, but actually, the interviewer is very good. Anyway, he's asking very interesting questions, and obviously, the stakes get a little higher as their mouth is on fire. And they're like, oh, I don't know what the PR person told me. And there's some really funny ones, too. And at the end, he's like, yeah, he says that.

Chris Krycho: [55:53] That sounds like torture.

Chuck Carpenter: [55:56] I like theme parties. Haven't done one in a very long time because I'm just tired.

Chris Krycho: [55:59] Fair.

Chuck Carpenter: [56:00] But I would do a hot ones party. Let me set up ten wings. And then the conversation just scales up as our mouths are on fire.

Robbie Wagner: [56:10] I would come to that party.

Chuck Carpenter: [56:12] Okay.

Chris Krycho: [56:13] I would not.

Chuck Carpenter: [56:13] We'll plan it.

Chris Krycho: [56:14] I would hear about it, and I would laugh about it.

Chuck Carpenter: [56:16] Yeah, we'll do a special podcast episode. Which reminds me, you should do either. A blog or a podcast where it's like, how people work, how techies work because you were talking about how do people work, and that's a real interesting, definitive breakdown from the software, your workflow, your style, where do you start to break down a problem and where does it end up? I think that would be really interesting. I just don't want to do it, so you're welcome.

Chris Krycho: [56:41] That's my problem too. I did the podcasting thing and then see earlier part of conversation where I don't do as many things anymore because my children are in elementary school now.

Chuck Carpenter: [56:49] It's true. Yeah.

Chris Krycho: [56:51] Current status.

Chuck Carpenter: [56:52] I just want to be internet famous, and I appreciate a couple of hundred people checking it out. We were on Shop Talk show recently, though, so I feel like we might be legit. I don't know.

Robbie Wagner: [57:03] Yeah, people have at least heard us. They might not follow us. But that's special.

Chuck Carpenter: [57:07] Yeah. People have been like, Why did you do this? Because I know Chris's wife and she made him. I think that's why.

Chris Krycho: [57:15] That's a good way in. That's always a good way in.

Robbie Wagner: [57:17] Yeah, I emailed him before you reached out to him and got no response. So it's definitely from your connection.

Chuck Carpenter: [57:24] Yeah, I texted her and was just like, yeah, what up? Will you ask Chris if we can be on or if you want to be on our show? I'll give him free whiskey, and then people are like, no one's going to see this anyway. Fine. That's how I imagine it goes. I have no idea.

Chris Krycho: [57:39] Yeah, I like it.

Robbie Wagner: [57:40] We're about out of time here, but just real quick, any other, like developers or projects you're really interested in or anything you want to plug or let the people know about?

Chris Krycho: [57:49] That's an interesting question. The challenge is always that the list is too long. I think, in general, my brand is to tell people that they should go look at Rust. So I'm going to stick to my brand and tell people that they should go look at Rust. And if you want to learn it, there's a podcast called New Rustacean hosted at newrustaceon.com, which I ran for three and a half years, and pretty good, if I do say so myself, about learning Rust. I've heard that from a lot of people. I think Rust will teach you things even if you're just a JavaScript developer and you never use Rust in your day job that are really, really helpful. I also think learning if you have only had a kind of object-oriented programming background, learning a functional programming language is really, really helpful. I think the opposite is also true. If you've only ever written Haskell, I don't know why you're listening to this podcast, but cool, go write some Ruby. I think you'll learn things. If you've done both of those, go write some prologue and learn logic programming because that will really make your brain explode a bit.

Chris Krycho: [58:54] I also think. Generally I find two things to be really valuable as an approach, and one is keep broadening your horizons about what's out there. It's really easy to get locked into just the next JavaScript thing if you're in the JavaScript community or just the next Ruby thing if you're in the Ruby community. And that's not even unhealthy. Inherently we should be aware of what's going on in our own ecosystems and working on understanding those things and whether they would be applicable to us or not, but having a sense of what's going on. I mean, I made the joke earlier about the ten or whatever it is, programming languages I've used. The way I think about TypeScript is informed about all of those other experiences, and it's really hard to do that without getting some breadth of experience, even if it's just carving out the last hour of your week every week to say I'm going to learn something. Most places that are reasonably healthy actually support that. They want you to be learning things. The counterpoint there is do go deep. Don't do the thing where you bounce off and say this is too hard for me because it's complicated Ember magic or it's complicated React magic or whatever. The reality is we're blessed to be in a world where a lot of the things we use are open source, and you just go read the code, and I say, just there. Not in the sense that it's easy, but in the sense of it's available. And if you want to understand how Ember works, it might take you some time, there's a lot of croft, but you actually can understand it. You actually can follow it down through and say, oh, this is why the shenanigans bug is happening. You can do that. You can do that. If you want to learn compilers, you can go learn the most complicated compiler in the universe in the form of the Rust compiler. You can go read the Rust compiler source code. Might not be the best first compiler to read, but you can do that. You can learn these things. And getting deep on subject matter as well as having a general breadth is a really powerful one-two punch in terms of being able to grow as an engineer to actually understand what you're working on. And there is a great post, I want to say it's by Julia Evans, Jvns.ca, about just being willing to go one level deeper and ask how does it actually work? There are a couple of others who have written similar posts over the years, but if you're willing to do that exploratory work and ask, wait, why does this work this way that becomes a superpower in your career, in your current job, etc. You have to know when to stop. You can go down very deep rabbit holes.

Robbie Wagner: [01:01:28] No assembly.

Chris Krycho: [01:01:29] But being willing to say why does this work? Or why does this not work, can take you a very long way.

Robbie Wagner: [01:01:37] Yeah, that's great advice. I mean, the Ember code is very interesting to read. I'll say that I've tried many times, and I still don't understand it, but there's always a level deeper that you can go that is comfortable. You don't have to go as deep as once you start to feel really bad, you can jump right out. But yeah, always question it, figure out the underlying things. Great advice. So we're out of time here. Thanks, Chris, for being on.

Chris Krycho: [01:02:04] Thanks for having me.

Robbie Wagner: [01:02:05] If you guys liked it, please subscribe, and we'll catch you guys next time.

Chuck Carpenter: [01:02:12] Thanks for listening to Whiskey Web and Whatnot. This podcast is brought to you by Ship Shape, and produced by Podcast Royale. If you liked this episode, consider sharing it with a friend or two and leave us a rating and maybe a review, as long as it's good.

Robbie Wagner: [01:02:27] You can subscribe to future episodes on Apple, Spotify, or wherever you get your podcasts. For more info about Ship Shape, and this show, check out our website at shipshape.io.