Here is a machine transcription of https://corecursive.com/034-chris-krycho-typescript/
If you are a transcript reader, let me know what you think (via comment or [email protected]). Are machine transcripts useful, how did you find the quality? I just quickly put this up as it is trending on Reddit, and I think better page layout would help with readability as well.
Chris: Typescript is the closest thing to dependently typed and refinement type systems that actually is in production at scale anywhere. It’s not doing those things, but it’s probably the biggest step in their direction that you’re seeing in sort of industry use on a wide scale.
Adam: Hello, this is Adam Gordon Bell. Join me as I learned about building software. This is called recursive.
Adam: That was Chris [inaudible]. Chris is a proponent of typescript who’s been using it since 2016 today. He teaches me about what types of group is and why we should use it. Chris is a software developer at Linkedin who worked on converting one of the largest ember apps in the world to typescript. I was actually shocked by the size of it. Chris also loves rust and types and as a former C and fortran programmer. He also did a podcast called the new rust station, which he’s since retired, but it was really well done. I hope you enjoyed the interview and as always thanks to everyone who has tweeted or blogged or otherwise mentioned enjoying the podcast.
Adam: Chris, thanks for coming on the podcast. I mainly know you as like a a disembodied voice that explains to me new features about rust. But today I’d like to talk to you about typescript.
Chris: I am glad to be here and looking forward to it. I will admit to have had even had the weird experience of walking into a meetup room and saying to someone, Oh yeah, hi, I’m Chris. And having heads turn because they’ve heard my voice from neuro station. And let me tell you, that never stops being weird when people just hear your voice and turn around because they recognize it. So disembodied voice on the Internet is apparently my thing at this point.
Adam: Yeah. Podcasts are there. Strange like kind of intimate medium, right? Because I feel like from listening to your podcast that I know you, but you know, you don’t actually know me so,
Chris: right. But I listened to your podcast so I have the same feeling. Yeah, it’s random. Weird.
Adam: So what’s typescript?
Adam: I don’t know his name either. Anders, let’s say. I like his taste. I remember, you know I did Java development for quite a while, maybe not quite awhile, but then I switched to c sharp and I was like, oh, it’s like Java. But it’s like, you know, it’s kind of polished off. Yeah, they got some nice things that I feel like he’s very pragmatic maybe and how he approaches the language like, oh we should have a way to do x.
Chris: I think that’s a very good description. And that pragmatism is both. One of the things that has made typescript very successful I think. And also one of the things that can drive me nuts on a day to day basis because, well I like to call myself an idealist, but we all know that everybody bought the idealists likes to call the idealists impractical and so on. So I tend to prefer type systems that are a little more rigorous and a little stricter and more sound in particular. The idea of soundness being that if you have a, a program that type checks is not going to fail in ways that contradict those type checks. So examples that many listeners will be familiar with are languages like Haskell or rust or elm. I believe Scala, though, I would not quote myself on that. F Sharp, et Cetera. And typescript is not that.
Chris: You add typescript to your package dot Jason and you type, you know you’ve run yarn or NPM install and you type TSC which is typescript compiler in it and it generates a typescript config file for you in the root of your project. You, depending on how you’re building it, if you’re using webpack or something, there are starter packs for that. Ember js has a tool that I helped maintain in the Cli that just generates your configuration for you actually, so you could in ember you would just say ember install, ember Cli, typescript. I think there’s a similar, just booted up experience for view and for create react app where you can just say view Cli, start with typescript or whatever, but in general you just add this ts, config dot Jason File and tell it if you have any weird layout things you have to tell it about those.
Adam: So where does run Babel
Adam: assume like at Linkedin they’re not letting you FTP some Java script class. And so
Chris: we have a CIA server where we’re running all of that and running the build and running a large exhaustive test suite and then generating those target bills back in ies five and a lot of modern build tools can split it out and say, hey, we’re going to generate in our builds for IEE and then we’re going to generate much smaller, more modern, faster builds that don’t do all that translation for quote unquote evergreen browsers like chrome and Firefox and safari so that you can again get the benefits of an updated runtime that has support for these new features natively. Because when you are back compiling, especially something complicated like generators or a sink in a weight or things like that, you end up having to generate a lot of extra code to support that and every app ends up having to make this trade off of saying, do we use generators here?
Chris: So for example, the app I work on at Linkedin, when I’m working on this big app, we don’t use generators because we have to ship this large runtime that basically acts like generators are part of the language by shipping it as a library, but that’s a lot of code and every bite you download and have to parse and then have to execute in the browser is a penalty to the actual runtime performance of your application. So we don’t use generators in this app even though they’re really nice and make certain patterns really nice because we don’t want to support that back to I e 11
Adam: makes sense. So a lot of people were already using a more modern version of Java script and then transpiling it. Exactly. Typescript steps in and says like, well what if you add some type annotations? Then when you try to add seven too undefined, then we’ll let you know.
Chris: Right? Or you try to
Adam: And then you can have individual servers per language and then you can fit those two together so that if sublime text has a language server implementation and rust now has a language server implemented well those two can just talk to each other basically for free without either of them having to do all the work of reimplementing refactorings for rust and then vim gets that and visual studio code gets that and so on. So that came out of the work Microsoft did for the typescript language server five years ago. And typescript remains kind of the canonical and best example of it. I didn’t know that. Yeah, I think the language server protocol, it’s like a game changer. Yeah. So in my day to day, I’m using skeleton. Traditionally we always, you know, everybody used intelligent cause it was kind of the only really good implementation and now there’s a language server protocol implementation for Skalla called metals and just people are slowly drifting off into using whatever editor they really want to use. Right. I mean if I were intelligent I might be concerned. But I think that, yeah, it’s definitely an enabling force for languages, right? Like there’s less overhead,
Adam: Yeah, so what do I get if I’d moved to typescript, the language server protocol, what does it enable?
Chris: So it enables refactoring, so it’ll say, hey, I want to rename this type, this class or this variable throughout my code base and you perform a rename and it does it. It introspects your whole code base fines everywhere that’s used and does it with a rename or you say, I want to find everywhere this is used throughout my code base and whereas in a traditional Java script code base your left with doing that as your kind of best guesses in your sort of heuristic driven approach which can be very good or are you left with fine doll and graph and hoping that you didn’t rename the wrong one or hoping that you caught them all and hoping that your test suite is exhaustive enough. If you have an application or a library that is actually exhaustedly covered with types. The downside to what I mentioned earlier that it’s gradual and you can layer it in as you go is you only have to layer it in as much as you want to, which means you can end up with a type system or a type coverage level that doesn’t actually let you get some of these benefits.
Chris: But if you do have it fully and exhaustively checked and you don’t use, I should come back to this in a minute. You don’t use typescripts escape hatch called any. If you’re not using those things, then typescript can actually exhaustively tell you, hey, here’s everywhere. This is being used and you need to change it and so you can do the thing that you do in more thoroughly type checks, languages traditionally of making a change and then just following the compiler errors or doing a refactoring that can actually exhaustively know where all of the refactor points are rather than that’s your as tickle model or that drop and hope. The model and just your test suite. Yeah. I mentioned typescripts. Any, I should elaborate on that. One of the places where typescript leaves some unsound snus on the table is it has a type called any which if you have a type that is any, it can be assigned to anything and anything can be assigned to it and this is an escape patch.
Chris: Sometimes you’re just in a spot where you’re saying, I have no idea what this is, or I don’t have time to write the types for that corner of the ecosystem, which leads me to another small tangent, which is to say typescript also gives you the ability to write tight definitions for third party code. So you can create a description of what the types are for some library that you’re interacting with. So I’ll come back to that in a minute as well. But this, any type, anywhere that you’re using it, it’s basically like, yeah, this is just Java script, man, do what you want. I’m not going to try to check anything anymore. And that’s very powerful. But unfortunately it also just means that anywhere you use it, you’re not getting any benefits and any type checking that happens to intersect with it type. It’s kind of like, Nah man, you said any.
Chris: And here you can call methods that exist on strings to it like to lower case or to upper case or whatever else. And it won’t let you do that in the number block. Well if you take that and include the idea of this unknown type were unknown, unlike any won’t let you assign it to anything that is well tight. So if you say let x be a number and then you have y which is unknown and you tried to assign y to x, typescript will say no, that’s out of bounds. You haven’t actually checked that this thing, y is a number, you can’t assign that to x. So similarly you can use this kind of narrowing notion, which is what typescript calls it because you have some set of possibilities and you’re narrowing the set of possibilities. In the example, I give a moment to go from string into number two, just number or just string.
Chris: Similarly unknown says the set of possibilities is unbounded. I have no idea what this could be, which sounds like any, but the difference is here, typescript checks you. It says no, you have to check. So if I have a function which takes in some argument, which is unknown, and I say if the type of this argument is a number, while typescript now narrows it and it says in that block, Hey, this is a number, you can do number things with it, but you have to do that. And so unknown lets you deal with things like, hey, I got this blob of data from across the Internet. I have no idea what it is. I mean in principle it might be what my API promise. But in principle it might just be a bunch of binary garbage or it might be a Jason object that looks nothing like what my API promised or whatever else.
Adam: So one thing that you mentioned that I’m not clear on is like gradual types versus type inference. So if I go back to your example, we take a Java script file, we rename it a t s but so at that point it has no type annotations. Correct. What are the types then? Are they any,
Chris: some of them will be, and some of them it will infer. So if you write let x equals 42 it’s going to infer that x is a number. And if you say return x there from a function, it will infer that the return type of the function is also a number. Now if you have some conditional block and you return 42 from one of them and the string hello world from the other, it will happily just infer that the return type from this could be a string or a number. Cool. And occasionally that’s what you want. But a lot of times it’s not so often good practices to then start adding annotations and say, no, really this function should only return a number. Please give me a typer if I return a string. The things that will default to always making any our arguments to functions because it does not do the kind of flow analysis and type checking analysis that some languages in the standard ml tree of languages will do.
Chris: Where it’ll say, hey, I can see from how this is used that this argument must be a number. It won’t do that. So it will infer return types and assignments but it won’t return function arguments. It also won’t in for items declared in the body of a class. So if you say class person and then declare a property in it name, but you don’t give the name of type, which is a valid thing to write in Java script, just name with semi-colon after it to say, hey, there’s an end property on this object. Typescript will treat that as any as well. And so at that point then you can start layering in and adding in types. We’re needful to say, hey no, this function doesn’t actually accept anything. And there is a flag in the compiler called no implicit any, which is part of that strictness checking, which will say, hey, if you convert it a file from dot js to dot ts, I’m going to you an error.
Chris: But I can say underscore dop map takes in an array and a function to operate over that array and the function has to have the same type signature to work legitimately with this and understands generic types and things like that. So you can write very sophisticated expressions that way. And now when I interact with low dash, I can also install the types from this library. I can install them as at type slash load ashes, my package name for them and I’ll just be able to say, Hey, I actually get, when I import in use under score dot map, I get type annotations for it. So if I misuse it, I’ll get that feedback from the compiler and I’ll get autocomplete from the language server and all of those things. So you have this simultaneous ability to do type inference, which means there’s a lot of stuff you don’t have to write.
Chris: So what it does is it actually looks at the flow of your code, not just the annotations and uses those kinds of checks. It’s smart enough to understand that at time a, the type is string or number, but at point B in your code you’ve done this runtime checking you had on someone who talked about refinement types in the past. And I think you’ve talked with someone who had dependent types and both of those can do some of these kinds of things. Expressing this idea of runtime behavior that has to be validated by the actual checks you do in order to type check to some extent and typescript isn’t doing either of those exactly, but through this run time analysis and also through some other sophisticated things you can express with the type system where you can return different types conditional based on the inputs to the function.
Chris: Again, through that kind of dynamic analysis of that flowed down through your code. So very sophisticated, very capable. So much so that in fact, even when I’m working in stricter languages like Elmore rust, sometimes I miss some of those incredibly rich, very dynamic capabilities that come out of typescript as a result.
Adam: Yeah, it seems very flexible and I can see the connection to the refinement types because you’re saying, you know, oh, type scripts is type annotations, you know, and refinement types of
Chris: a, at least liquid Haskell lives in these like kind of comments, right? Where you’d say like, Hey, this event has to be greater than zero. You know if typescript where like if you did like slash slash colon int, right. If you put all the types in right as comments, it would be kind of similar. Right? It’s a similar space. Yeah. It’s this extra layer on top of what the regular story for the language is there and it’s almost like, I mean it seems to overlap with linting a bit too. Like is typescript a language? Is it a really fancy linter? Right. That is an active debate in some of the communities I participate in and actually as one of the maintainers of this ember typescript integration, I make very clear to people that hear what my preferences are, but at the end of the day, if you just want to use it as a really fancy linter rather than doing what I described, borrowing the term from Edwin Brady who is the author of address and so on, this idea of type driven development where as much as possible I’m using the pipes to guide how I build and I ended up using a combination of types and tests which can be very, very powerful as a software kind of one two punch in engineering to get rigor on both the run time and the design space, both of them eliminating different classes of errors.
Chris: So you have done some sort of training on time scripts and I was looking through kind of your notes and I found this quote, maybe you could explain, it says types or just shapes. Exclamation maybe I need to say with emphasis types or shapes or just shapes. Yeah, so this is one of the other really interesting defining features of typescript. Most type systems that most people are used to including most notably in today’s space, Java, c sharp and c plus plus and for the most part swift with an important qualification around protocols. Certainly also rust, Haskell. Almost all of these have what we would call a nominal typing system and the idea there is that types are identified by their names. So if I have class person which has a, which is a string on it and then I have class human, which is a class which has a name, which is a string on it, those two are not substitutable for each other in any of the languages I just mentioned in typescript they are because typescript looks at those and says, oh that’s a shape and that shape is an object with the property name that is a string on it.
Chris: And so a lot of especially functional programming idioms, which often you really just want to say, hey, I only care about this one aspect of this, and if you give me something with that aspect, I can do something with it. And then hand you backs. That thing transformed in some way. Typescript lets you do just that. It lets you say, hey you hit me in an object with a name on it and I’ll hand you back the length of that name and I don’t care how rich or sophisticated the rest of that object is. I don’t have to know anything about the details or the internals of that object as long as you have to be an object. That among other things included a name that was a string. We’re good to go and that idea we call structural typing. All you care about is the structure of the thing you’re dealing with.
Chris: A couple of other languages do have this. Swift’s protocols are structural in nature, which is very different for me. I’ve been digging into swift over the last month or so, a bunch having spent the last almost four years playing almost entirely with Rustin. My spare time and swifts protocols and rusts traits look very similar that this way to describe a behavior that something can conform to like an interface in Java or c sharp but which you can apply to something after the time of definition. So in Java or c sharp you have to say class foo implements interface bar in both Rustin swift you can say this type implements this trade or protocol whether rust or specific or rust or swift. Well apart from the definition which was very powerful in rust you have to include the body of whatever it is you’re implementing. You have to define that there so if just perfectly happy to say, Oh you already the relevant properties and methods. Cool, you’re good so you can have body less implementations. Also elm has this notion of structural record types where again, I don’t care if your type is a super set of this as long as you hit me that you’re good to go and I believe oak camel’s notion of rope polymorphism fits into the same thing but don’t quote me on that because I haven’t done much o camp.
Adam: It’s funny because like I had an episode about pure script, which I believe it also has roe polymorphism as one of its unique features and I think it has something to do with Java script where like if you’re compiling something down to Java script, you’re like kind of really want this. Yeah,
Chris: that’s a good insight and I hadn’t thought of it before, but I think that’s exactly right. I will also say that by and large, a lot of the flame wars between dynamic and static typing seem to me to be fairly well dissolved by this. Not all of them. You have some zealots on both sides who are like, well, we live in a universe where things are not actually perfectly computable and so types are a lie and they’re always a lie. And you have people on the other side who say stupid things like if you’re not using types, you’re being unethical and irresponsible. And I think both of those are really stupid things to say and they’re just frankly, they’re intellectually folly because it is true that you can’t cover everything perfectly with types on that side, but you also can’t do that with tests. And most of the people who say that really like tests on the other hand, quite legitimate to say, look, for my use case here, I want maximum flexibility and I’m willing to take the trade off that comes with that of losing some of the things I might get out of types.
Chris: So a couple of friends of mine will make exactly that argument and we have friendly back and forth about whether untapped or structurally typed is good or these nominally types of languages over here are good and most of them would frankly admit that if you’re writing low level system software, you know that’s a tls implementation or something. Actually having rust in it’s types is probably really high value. Whereas in other systems, certain kinds of web systems where you’re just doing really loose flowing data transfer, something like closure or elixir or Erling which doesn’t have, those might actually be more productive for you in certain ways. And so I think smart people recognize that there are trade offs with these typescript and other things which embrace structural typing as at least one tool in the toolbox seem to me to somewhat bend that curve and make it easier for you to say, I’m mostly going to write this like it’s structurally typed.
Chris: Just sprinkle in some annotations on top and really be good to go. And in the case of something like elm, you’re getting that with a Henley Milner style type analysis. So you’re also getting this exhaustive whole program type checking with perfect inference. And of course you’re going to add some annotations in general because they’re handy for other humans. But in my experience, structural typing really is this incredibly sweet spot where it kind of feels like duck typed dynamically programming, but you’re getting all this help of the combiners saying, hey, this could be novel and you might want to check that here before you just call the function so that you don’t end up with bug snag or Reagan or whatever saying, Hey, undefined is not a function you just had for years. Those who couldn’t please orders because your function wasn’t defined here. No, not that I have deep and painful experience with this or anything.
Adam: That’s funny. Yeah. I remember I had an episode with Jim Blandy talking about Ross and I remember his like big complaint was like there’s like a million line Java script code base out there and if you make a typo then you just have to wait for somebody to hit that line. Yeah,
Chris: yeah. It really stinks and sometimes the way that you get to those combinations is just incredibly arcane. There was a bug I dealt with in my previous role where we knew that bug existed for two years and we could not reproduce it. We could never figure out the set of steps that users were going through to hit that flow. And so we would see it show up with a stack trace in Reagan and we would look at it and we would say, we would trace through every part of our code flow and we would just say, we can’t see how this is possible. And one day our product manager was clicking around to the app and said, Oh hey, this thing just happened. We were like, you found it. But it was a case of something into being possibly undefined. And even when we had written the typescript, typescript has a couple of these little escape hatches and one of them is you can write an exclamation point to say this thing will always be defined.
Chris: And we actually had a nice little comment on this block of code that says, here’s why this will always be defined spoilers. The comment was wrong. The compiler was correct. Now the problem wasn’t that spot. The comment was actually correct in the small, but in the large the system was wrong and it took two years. And finally our product manager just happened to be poking around one day and found the right combo that triggered it. We fixed it and it went away and it was a good feeling. But that example was one, one I listened to that episode that I resonated with very, very deeply how it was going. Yes, Jim. That’s exactly it.
Adam: Yeah, that is a crazy story. I, yeah, whenever you can get something out of comments and have it checked somehow. I remember like years ago working on this old code base and finding this method that I need to interact with that giant comment that said like, you know, this thing takes the following like seven arguments and this one should be this and this one should be that. And then looking at the method and it only took three arguments. They weren’t the same.
New Speaker: So rust versus typescript, which is better.
New Speaker: Oh Man. Do you remember how a minute ago I was saying that people say dumb things on these type four arguments?
Chris: For that reason, I just refuse to answer the question as stated because I think any answer I could give, what ended up being a dumb answer, I like rust better on a day to day using it level. For the last couple of months I’ve been working on a project called Volta, which we built out here at Linkedin, but it’s an open source project. It’s a node version manager tool chain which gives you nice reproducible environments so that you can make sure that all the developers in your team are using the same version of node and the same version of yarn or NPM in the same stack for any cli tools they’re using or things like that. And we wrote it in rust in part because the original author behind it, Dave Herman helped drive rust at Mozilla and he’s fantastic. If you ever get a chance to talk to him, you should. I look up to Dave a ton, but we’ve been using crossed and so I went from my previous role where I was writing typescript all day, every day to my current role where I’m doing a bit of typescript but mostly writing rust every day and that soundness and exhaust stiffness of it is just wonderful and a lot of the built in language constructs that you end up having to build yourself in typescript.
Chris: Things like rich enumerated types that Russ has where you can say not just this is a or B or c, but a or B or c can themselves be rich data. Not just an integer. So a can be a with a string wrapped inside it and B can basically be a struct definition which has all these fields on it and so on. You can build up those kinds of abstractions and check against them in typescript, but you have to do all the work yourself and the language just guides you through that with rust automatically and right out of the gate. And it is deeply joyful to me. But I also have to admit that because of weird things about my background, Russ just scratches an itch. That’s just right because the first two thirds ish of my career up to this point, I was writing c and c plus plus and times for Tran.
Chris: And so I’ve spent so much time in that kind of low level world that rust does this magic trick where I’m still writing that kind of extremely high performance memory controlled low level stuff. And I’m also getting all these niceties of a high level language. And so I like that enormously. And the net of it is that Russ just feels better to me, but I can’t say that either of them is a better language I think is more accurate to say that both of them are very carefully, thoughtfully designed languages that are targeting very different worlds and very different spaces and doing so very effectively. Rust has this goal of zero cost abstractions and being able to be as fast and sometimes amazingly faster than c or c plus plus and safe at the same time. And it’s doing that incredibly well and there is a cost to it.
Adam: It’s funny. It makes sense that you mentioned that you had kind of a sci background because in my mind I was thinking it is strange for somebody to be interested in, in both like amber and Russ like that seems like a very, those circles don’t intersect. Yeah. So like wrapping up on typescript, when should people not use typescript?
Chris: That’s a great question and I think there are a couple places where I would say don’t. One is if you just try it and try it, you know, legitimately not just this is new to me and I hate it, but legitimately go for it for a while and it just doesn’t pattern match right in your brain, for lack of a better word. I have, I mentioned earlier a number of friends for whom even with structural typing systems as often as they try to use them, they just bounce off. And these are people who know Haskell, they’re people who are really good, really top of their game engineers and it just doesn’t work at the end of the day. Like I said, I think the using types is an ethical constraint thing is just dumb. And the best programming languages research we have says you do find certain classes of bugs with types, that’s great.
Chris: It’s helpful. But those kinds of things are limited enough that we just don’t really have any grounds for those kinds of sweeping claims. And so if you and or your team bounce off of it, I think that’s okay. I think in certain cases people’s brains just work differently and I think that really is okay. My brain works in types. I’ve been trying to shove things like pattern matching and those kinds of rich data types into see since before I knew they existed in other languages, I was trying to make this kind of thing work with enms and unions and whatnot. Clearly my just runs that way. I want to write these kinds of constraints and other people don’t and that legitimately is okay. If you have a team that is just hostile to it, don’t try to force it. It’s not worth whatever gains you might get out of it.
Chris: I would also say that in certain sufficiently large code bases, if you don’t have a lot of will, it might not be worth it because you really do have to have the will to see the conversion through and it’s going to be long. It’s going to be an enormous amount of human hours and effort. Now I say this as someone who’s been working on planning out how to do this on an app that has over a million lines of Java script in it, so a glutton for punishment. I don’t know, something that way, but there are situations where it may just not be worth the investment to you and your organization. And I think that’s also legitimate because these are engineering tradeoffs. They’re not things where we can just snap our fingers and have the code base magically all type. If that were the case, I would say that almost everybody, unless you just can’t do types, and even then have you tried a system that has structural types, you might try it, it might be different, but with that exception, if we could all just snap our fingers and have fully typed typescript things.
Chris: And then soon everybody in the organization is using that script. Things have a tendency to grow life of their own. So you should probably be more skeptical of the idea that you’re really going to have a one off throw away script. But those kinds of things, like I said for me, I mean I write some of those in rust at this point, call me crazy. But I just, I like the feedback cycle. I get there and I enjoy using it and it works well for me. So obviously I don’t mind using types even for throw away one off script, but that would be a place where people might not find a value tradeoff high enough.
Adam: I just read an article, they had mentioned something about proof of concepts and I agree with the sentiment where it’s like everything that’s running in production with somebody like throw away proof of concept. They were like, there’s like the great vision that you want to build and you’d never get to. And the proof of concept that still lives on, right. Those are the two. Yup. And some of them are
Chris: nightmares, but they’re still going and it turns out that code that’s actually doing something is really valuable. So
Adam: delivering value. Right.
New Speaker: So when I started this podcast, one of my ideas was sort of to get down kind of in the weeds of coding, like an audio format. It turns out that that’s like super hard. So I don’t know if I’ve given up on that, but uh, like your podcast, you actually have like code samples and and walked through them. Where did you come up with this style and structure?
Chris: I wish I had a good answer for that. Mostly I think it was that I was too ignorant of how incredibly hard it would be and I thought I was surely one can do this, right? Maybe the reason no one has ever done this, that’s come across my radar or is I’ve just missed it. As far as I can tell, no people just recognize that this is really hard and you shouldn’t do it. I ended up starting neuro station when I did in part to help myself keep learning and then I found that teaching as that podcast was designed to do without actually talking code sometimes is really difficult. Sometimes you can get away with talking conceptually, but when you’re trying to teach something like a programming language, you really do just have to talk code sometimes because it’s a programming language. So what I ended up doing over the life of the show was figuring out how to boil down the examples to really, really minimal things that you could actually maybe say out loud and maybe listeners could parse out loud and then if they didn’t, you know, only have to re listen to it once to catch the parts that they missed.
Chris: There was also an art I discovered over time of figuring out how you pronounce those strings of characters, you know, a function, taking the name food, taking the arguments bar and Baz of type string and number and returning a new struct with these fields or something like that. Over time, learning how to actually say it because I was talking rust and saying fn foo open parentheses, which I did do in a couple episodes and it turns out you just can’t parse that because you’re trying to translate from audio into a visual representation of that. Whereas if you just think about what the actual semantics are that that syntax maps to, you can communicate that. You can say, here’s a function named Fu, which shakes bar being a string and Baz being a number and returns a new structure which has some embedded field in it.
Chris: I can say that and you can understand it because at some level when we read syntax, that’s what our brains are actually doing. We’re not thinking fun. When we CFN for function, we’re thinking I’m seeing a function definition and we get very accustomed to parsing those details and translating them into the semantics. They mean at least at a high enough level when we’re reading through code. So the trick for me was finding a way to figure out how can I do that parsing kind of ahead of time, do the pre parsing to turn it instead of into, you know, some byte code or something, some AST to turn it into something more like a syntax tree for English, which is what we call a sentence in English. But to of do that mapping into what are the actual semantics that we’re thinking about and whether I would recommend it to anybody else. Well, I don’t know. It was, it was really hard. A lot of times I would end up leaving myself notes in the script of how to pronounce a given definition or how to read a particular thing because otherwise I would get to it while recording and just say, oh no, oh no. And I would try it three times and have a whole bunch of editing to do to try to clean it up into something that was actually useful.
Adam: Yeah, I think it’s super tricky, but I think it’s great that you’ve made enough about it. Maybe we’ll get better, like maybe my rust is super rusty, if that makes any sense. Like I know almost no rust besides talking to people, but I have explained to people my challenges with the language by saying like if you have a variable x equals one and then like y equals x and then you print x, right?
Chris: Yep. Yes. That one sure confuses people at first.
Adam: So the punchline there is that will not compile and that may be confusing for you if you haven’t worked with recipe for it yet
Chris: though I think the specific example you just gave may compile because integers implement copy, so by default the compiler will just copy that for you rather than cloning it. But if you did it with an own string, it would behave exactly the way you just described. So if you said, let x equals string from hello world, let y equals x print x, boom, this doesn’t compile. You moved to y and you’re going to say what? What do you mean? What’s this? I’ve never seen anything like this.
Adam: Yeah. See, this is why I don’t do ad hoc a reading a code in the interview, so
New Speaker: I pulled this bio up. A view says a Chris’s, a husband and a dad, a theologian, a composer, a poet, an essayist, a software developer, a runner, triathlete. Podcasts are an all around nerd. Like what’s your secret? It sounds like you’ve maybe consume a lot of Info adamine
Chris: happily. No, I have a couple things going for me that way. One is that most nights I only need seven to seven and a half hours of sleep. And I’m not one of those people that ys to myself about how much sleep I need. So I went through a pretty bad season of burnout last year for a lot of complicated reasons, including things like moving across the country after getting a master’s degree and my dad having cancer brain cancer, which he came through well, he’s doing really well. But that plus job stuff, it just, I got burnout and those days I was sleeping nine, nine and a half hours a night. So I listened to my body very well. That is actually also part of it. I listened to my body well, but I only need seven to seven and a half hours of sleep tonight. And that extra time matters.
Chris: I work from home and don’t have a commute. And for a lot of people, that’s anywhere between one and three hours a day that if you’re riding a train, maybe you can get some of that back. But if you’re driving a car to get through la somewhere, I mean, good luck. You’re, maybe you’re listening to an audio book at best. So one thing I just always have to say to people when they ask this is I have a lot of extra time that adds up over the course of a year. You know, figure somebody takes four to six weeks off or whatever, you’re still talking (800) 900-1000 hours of time. So that makes an enormous difference and it’s actually one reason why I’m really, really bullish, I think is the right one on remote work and people being able to work from home and not just in our industry, but wherever we can enable those kinds of things.
Chris: I also get to spend way more time with my wife and my daughters and that’s massively important. I mean, I got to see them at lunch. I went upstairs and made lunch for all of us and those kinds of things. So for those reasons I have come to really value it. The other thing is I do keep a pretty rigorous schedule. I tend to get up and make breakfast and read my Bible and then do some writing time. And then I do my work day and my work day seven 30 to five 30 and no, I don’t work 10 hour days, but I block out that somewhere in there, depending on the weather or whatever, time of day is best. I live in Colorado, so whatever time of day is best varies enormously. I’ll be getting out for a run or something like that. And I just know that there’s going to be a couple hours in the middle of the day where I stop and run and I go, come back, take a shower, eat food, et cetera. And then I hang out with my family in the evening. And then there’s time after my kids go to bed where some nights I’m just hanging out with my wife. But some nights I’m writing podcast episodes or editing podcast episodes or whatever the case may be, working on reading some nerdy theology book, so on and so forth. So it’s mostly just having a good sense of the rhythms of my day and sticking to those. And then like I said, all that extra time that I get out of not having a commute, I’m needing less sleep.
Adam: Yeah, I think it’s harder than you’re making it sound. So I work from home too. The listeners can’t see, but there’s a chair behind me there and I think that I have dedicated some of the time you use for podcasting for sitting in that chair and playing angry birds on my phone. So
Chris: I also got rid of Twitter recently and I’ve been really aggressive about removing things like social media and that actually helps a ton too. But I mean I waste time sometimes. I also, this is huge, so I take a weekly day of rest and counterintuitively to a lot of people. I think that’s actually extremely helpful in this. So for over a decade now, Sundays a that’s the day I pay cause that’s what I’m going to church. It’s time I spend with family, et cetera. I don’t work on these things. Sometimes I’ll muck around with this Sunday I spend a little time mucking around with my website, which I’m in the middle of redesigning. But I did that because it felt restful and you read part of that bio, it included theologian. I’m a Christian and I actually, I look at this idea of Sabbath from the Old Testament, the Hebrew Bible, and it just seems deeply wise to me.
Chris: People sometimes get hung up on it as this kind of binding rule. I actually would just look at it very much as a gift. Humans need rest and especially in our industry, it can be this weird badge of honor to just say, no, I go all the time and I do stuff every day and I work 14 hour days and that’s nonsense. For one thing, you’re not working good 14 hour days, seven days a week. I just like to be effective with the time and the abilities I have such as they are and with my absurd drive to always be writing a blog post. So I try to use that. Well, I figured if I have it I might as well bless others and encourage and help others with it. But I also have to remind the people around me that just because I’m like this doesn’t mean it’s more valuable or more worthwhile.
Chris: It stresses the heck out of a lot of people I know and love to think about trying to do all the things I do and I say, no, it’s okay. I just really like doing things and I’m good at doing things. You don’t have to be as interested in doing things as I am. It’s okay to spend more of your time proportional to me reading novels, like I spend a couple of nights a week usually doing things that include things like reading novels or playing mass effect with my wife and then recording a podcast about it cause we’re nerds and that’s what we do. Check out mass affection.com if you want to hear that. It’s nerdy and hilarious because it’s basically us ranting about a video game and flirting. But I do these things because I loved them and I enjoy them and they seem to be an effective use of the way I’m wired and built.
Chris: But I don’t feel the need to define myself in terms of them or find my worth and doing them. So much of our sense of fatigue comes out of this notion of deep obligation that comes out of that sense of measuring ourselves and our worth out of our productivity rather than these being things that we can do freely and enjoy and by view because we’re made to be creative in the image of a god who is creative and made pretty spectacularly crazy, weird worlds out there. As I look out my window right here, it’s, it’s a wacky place. Have you noticed? It’s wild and so my worth doesn’t hang on that. So it really is. Okay,
Adam: well that’s a very healthy attitude and I have to think that some of your success relates to that. Like the fact that you explored rust not as an obligation, but as a joyful endeavor or whatever you want to call it. Yeah, I think that’s right. Well, I think we went through all my questions. Chris, where should people find you online if they want to learn more about you?
Chris: As I mentioned, no longer on Twitter, the only thing you’ll find on my Twitter account is a link to all these other places. My website is the main place, Chris criteo.com I blog a lot there. As I mentioned, you’ll find updates there multiple times a month, sometimes multiple times a week, rarely, multiple times a day. I try not to do that because it usually usually means I’m not doing something else. I should, but occasionally let myself get away with it. I also have a couple of newsletters, one at button-down dot email slash Chris Criteo where I’m doing some longterm thinking out loud about questions around culture and late modern individualists, liberalism and kind of these big structures societaly and a lot of cases just trying to funnel people toward people much smarter than me and much better read than me who are saying interesting things about them that I think are worth engaging with sometimes I disagree with, but that I think are worth engaging in thinking well on.
Chris: I also have a newsletter for a side project I’m working on at button-down e. Dot. Email slash rewrite where I’m trying to build the world’s best research writing application, which is probably the most absurdly ambitious thing I’ve ever done in my life and I have no idea whether it’ll succeed, but hey, it’ll be fun. While I try and perhaps most interestingly and related to some of these notes we’ve just kind of touched on, I have another podcast called winning slowly, which you can find it winning slowly.org where a friend of mine who’s a professor at Arizona State University and I try to talk through what it looks like from a usually implicitly Christian frame of like, how do we do ethics and technology and art and religion. He says that’s a way of bounding the subjects. I like to describe it as being our excuse to talk about literally the entirety of human existence because technology, religion, ethics and art kind of covers pretty much all of it. But this idea of trying to come at how does it shape us to use a smart phone every day? What are the implications for how we think about community of doing social media? What are ways that we can use or choose not to use social media well, and trying to think on those bigger, more structural levels, trying to rigorously engage those questions. And I think that’s pretty much it. So, yeah.
Adam: Well that is quite a few things, but I think that they’re all very interesting. So thank you so much Chris. This has been a lot of fun. It’s been my pleasure. We ran very long, so hopefully it is not too much for you and your listeners. Thank you so much for your time.
Speaker 5: [inaudible]
Adam: that was the interview. I hope you enjoyed it as much as I did. The last episode with Cory Doctorow sparked some interesting discussion on our slack channel and on Twitter and the Bob Nystrom interview about interpreters received a lot of attention as well. I’d like to thank everyone who mentioned the podcast on Twitter or elsewhere showing super long, so I don’t have time to list everybody’s names, but let’s do a couple Eagle Tabachnick, Jeff Martins, Sean O’Shea, Colin Fay, Matthew Staff, Dunkin, Ajay, Tom Mariotto, oh, Fad d and everyone else. Thank you. So let me know what you think of this episode. I love to hear from people who have discovered the podcasts and are listening through the back catalog, especially, you know, if you’d like to hear your name or Twitter handle or iTunes name mispronounced on the podcast. Until next time, thank you very much.