Introduction
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 Krycho. 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.
What Is TypeScript?
Adam: So what’s typescript?
Chris: Typescript is a typed superset. Technically speaking, that’s not true and I’ll talk about that a little bit more in a minute, but it’s effectively just a type superset of the Java script programming language. And what that means is you are able to add type annotations to Java script and then you have a compiler which can do two modes, one of which is just check that code and one of which is actually generate Java script from that code. And those two modes exists because most people have babble in their javascript pipelines these days. Anyway, it is a compiler that takes one version of Java script and compiles it down to earlier versions of Java script or that can include various feature proposals and the like. So a lot of places today we’ll use typescript just for the type checking and then use Babel to compile it so that everything’s a single pipeline.
Chris: But the big idea for typescript is to say that huge amounts of the web at point and huge amounts of all of our infrastructure is increasingly written in Java script and in Large Java script applications. And many developers find that with sufficiently large, sufficiently complicated applications, libraries and so on. Having a type system is a helpful tool, so the original pitch possibly still the pitch on the typescript website is javascript that scales and the idea is you can gradually layer in a layer of types on top of an existing Java script application or library or you can use them from the start of building a new one and start getting some of the benefits that types give you in particular refactor ability because you can know rather than you get just guests heuristically where a given item is actually being used throughout your code base and a certain degree of reliability.
Chris: For example, things like no checking. You can tell typescript to, hey, check me and make sure that if this thing can be no, I check it ahead of time. And that combination of giving you some much more sophisticated checks on what you’re doing and then giving you tools for refactoring means that at least in principle, typescript code can be much more scalable. Java script. In my experience now there are a lot of my fellow Java script nerds out there who are saying, ah, boom you and your types. But for me the experience when I actually started pulling typescript into apps and add ons, libraries that I was using was there were a bunch of places where I thought, Oh yes, I have exhaustively checked all the ways that this could possibly ever be no. And the compiler said you’re wrong. So the value proposition there is let’s take this very dynamically types language and give you the tools to describe the types of you’re working with and in very rich sophisticated ways that do actually capture the incredible dynamicism that javascript has.
Chris: And that’s probably what makes typescript particularly interesting from the perspective of type theory or something like that is javascript is a wildly, incredibly dynamic language, which you can do ridiculous, crazy things with at runtime and typescript can actually represent it’s type system, a very large and in ever increasing percentage of that. I hope that’s a good rough start to it. At least answering your question. Yeah, totally. So if I understand typescript, I like the short version. It’s types for javascript. So where did this come from? Microsoft started the project in the early 2010s 2012 2013 I think. And the lead contributor for it is unders. I’m going to pronounce his last name wrong. I’m so sorry. Helzberg l elds. Virg it’s, it’s a name I’ve never actually heard, just seen on the Internet. But this is the guy who was behind most of c sharp and before that was involved. And I think Turbo Pascal or Delphi or both think hose. Yeah, very, very important contributor to programming languages and I like to joke that for good and for ill occasionally, mostly for good but occasionally for ill typescript. Seems like unders is playground for interesting type theory ideas at scale. So came out of Microsoft, continues to be driven by Microsoft and is heavily integrated into visual studio and visual studio code. As a result, a lot of Microsoft’s own open source tooling is built with typescript at this point.
The Pragmatism of 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: And typescript has become much more that, but philosophically typescript is a deeply pragmatic language. And so the tooling and the type system around it are very much built on enabling and empowering working javascript developers, which is a goal I can really appreciate socially as someone who’s worked in it day to day for a number of years now. But there are definitely places where I want to be able to say, no, check me. I don’t trust myself. I’m an idealist. But what are the idealism here means is that I’m a total cynic about my own ability to actually get this right. So please check me exhaustively and vigorously here at typescript.
Meeting JavaScript Where Its At
Adam: So is it not, this is a super set of Javascript, so they’re trying to meet the javascript world where they’re at. Is that exactly, yeah,
Chris: and that notion of it being just a type superset with only one exception. Everything in typescript is just a type annotation which you can strip out and the only exception to that is the enumerated type it supplies, which is just like your basic, he knew him from Java or c or whatever else except that it can also have string values. But when you look at that, it just compiles straight into a simple javascript object with some key value look up. So even that one technically breaks the, everything is just the type annotation that you can strip out. It doesn’t really break it and so they really are just trying to say we’re not going to pull an elm or a reason ml with buckle script or something like that where we’re creating a whole new language for which javascript is the compile target. Instead they’re saying we’re going to add types as a layer of very rich static analysis and tooling integration via the language server on top of Javascript, but it’s still just Java script with those type annotations in place.
Using TypeScript
Adam: So like practically. Okay. Like I have some simple website and it has a bunch of client side javascript code and then I want to take that and turn it into typescript. Like what do I do?
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.
Chris: But in general, if you’re using a fairly standard layout for your file system, at that point you’re done. You can just start type checking if you want to integrate it into your build pipeline. Say you’re compiling from Java script, Super Fancy version. Next down to s five turn it on IEL 11 which hi, sadly still the story for many of us, Microsoft, please kill I 11 you’ll use either typescripts own tooling to do that. The Ts config data generates will by default target ESBL five and therefore be suitable for running. I think it targets cs five it’ll actually go all the way back to s three which runs on [inaudible]. I think most people don’t need that happily. You can either do it with typescript itself or you can just wire it into your babble pipeline and then you just start taking a file and saying, okay, instead of ending this file extension with dot Js, I’m going to end it with dot ts. Just change the file extension and by default that’s enough to start getting it type checked. It also actually has a comment style that you can throw at the top of the Java script file where you type a comment and then say am preset ts check and it’ll check the javascript file for you as well in sort of it’s elusive
Adam: mode. So I’m not super, I don’t know a lot of front end stuff, so I’m gonna try to break this down because like, okay, so babble is some sort of translation layer from magic new javascript to whatever I e support.
Chris: So let me take a step back. I live in this world everyday and I forget that it is not the world everyone lives in every day because we are targeting browsers in general. We have to deal with the lowest common denominator of whatever browser we’re targeting. And so while the javascript SPEC continues to move forward in, the language continues to move forward, unlike in a server environment where we can control exactly what version of a given language run time we’re running and can upgrade at our own pace. In the context of Javascript, we may have to be targeting 11 and Internet explorer 11 targets the ECMAScript five version of Java script and it doesn’t have any features later than that, so although that came out the better part of a decade ago and javascript has changed enormously since then. Whether that’s the inclusion of things like classes as Syntec sugar for the function prototype way that you might have done things in the past or the inclusion of constant light bindings which have local better scopes.
Chris: Unlike the old veer in javascript which gets hoisted and has weird scoping behavior that confuses people and breaks people all the time. Many new features like this generators, async, await syntax, et Cetera, can all be carefully compiled back to s five if like me, you work at Linkedin and we still support I e 11 and so we need our rich client side javascript to be able to run on 11 even though current versions of chrome and Firefox and safari and even edge before it shifted to being chromium could all run stuff that’s been part of the javascript Spec even as late as the last year or so. And so babble gives us this layer of being able to say, I’m going to write modern Java script with all of these language niceties and then compile it back to an earlier version of Java script. So you’ll often hear this referred to as transpiling because you’re doing it not from targeting one language to another in the traditional sense or a lowering sense, but from one language to another. Equally high level language, which in this case just happens to be the same high level language of eight years ago or whatever it was when [inaudible] came out. So Babel will do that. Typescript can do the same thing and target an earlier version of javascript or it can just target the latest version of javascript if you’re one of the lucky people who can get away with shipping javascript that only targets current versions of chrome and Firefox and safari.
Adam: So where does run Babel
Chris: will run as part of a build pipeline on your, whether that’s locally or an sci set up or whatever else. So most modern javascript rich applications in order to be able to take advantage of all this functionality that we’ve built up have a bills pipeline and that’s kind of weird in a lot of ways for people who are used to the old include a jquery script tag and be off to the races version of doing front end web development. And for that reason I’ll frankly acknowledge that it can be a lot harder to get started in some cases and it can feel a lot more intimidating because it’s a case of, wait, I have to run this builds tool so that I can do some interactivity in my html page. I don’t, and the answer is no, you don’t actually have to do that. You can still just drop a script tag on your page and be off to the races. But again, for those of us building these rich applications, in most cases we have command line tools integrated into that anyway because we want things like linting to be able to say, hey, here’s some static analysis output and to be able to run our test runner actively while we’re going and developing the app or to be able to do boiler plate generation of, Hey, just give me a new react component or a new view component in my conventional locations for this app or things like that. And so yeah,
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
Language Server Protocals
Adam: call a function. It’s I’m defined and every javascript developers least favorite, but most common error. Undefined is not a function. No. Typescript says, Hey, we can just layer on top of this existing stack of tools that most of you are using and add this nice layer of static analysis and tooling support and when I say the tooling support, the language server that they built around this is phenomenal. So whether you’re using it in vim or whether you’re using it in visual studio code, you get this really great experience for inline documentation and code completion and refactoring tooling all built on that language server and it’s the single language server which Microsoft actually introduced as part of building visual studio code and typescript support and integration back in probably 2013 or 2014 where they have this idea of instead of every editor having to rebuild its own tooling, you can define a common layer and then a common protocol for talking to that so that every editor can have a language server protocol implementation and just know how to talk to anything that speaks to that protocol for any given language.
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,
Chris: right? Because that cost of finding a tool that knows enough about and can introspect your code richly enough to do those kinds of refactorings and completions and all of that. And JetBrains is tools, intelligence and all of those have always done very well and been very good at that. In my use of rust for example, I ended up going back and forth because of the intelligent rust plugin and the vs code plugin. Each of them does certain things better than the other one or feels better than the other one. I liked this code better. It’s a little lighter weight feeling, but the intelligent plugin is really good and it’s a little faster and more stable than the rest language server. But that democratizing factor, I think you’re exactly right, ends up allowing new languages to be adopted much more quickly. So another example of that reason, ml is a syntax layer over o camel that is primarily used for compiling to javascript via a oh camel to javascript compiler. But they built a language server and I think it’s actually just a standard o camel language server that then can talk to vs code or talk to them or whatever else and it’s the same thing. All of a sudden all of that capability just exists for anybody that has a linguist server plugin and that’s a huge thing for somebody who wants to try using reason ml because the gap between that and whatever tools they’re already using is going to be so much lower than it would have previously.
Any vs Unknown
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: So anything goes here and you lose that. So in typescript three they introduced a different type called unknown, which is actually much more useful for the way I write. Javascript. And unknown is a type that says if you want to do anything with this, you have to check what the type is and that leads to the fact that typescripts type system is actually very sophisticated and does flow analysis. So if you say, I have an input to my function and I can define that input as being an anonymous union type where I can say this is a string or a number, it’s valid for you to pass me either of those as the argument to this function. Then within it you can, right. If type of this argument equals number within that if block it now knows that it’s a number and it’s legitimate to add it to other numbers and to divide by it and to do other things you would do with numbers and then you can put nails flock and it’ll know that well you checked in the if block, if it was a number, so this else block, it must be a string.
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.
Chris: And so unknown gives you this tool for describing that in a more robust way. Again, this is part of that trajectory I described. If typescript saying, how can we capture this thing that’s really useful, which we used to do in this more loosey Goosey way and give you a way to express it with much more strict and sound guarantees. So today if I’m converting a code base, there’s an ESBL lynch rule, which is a javascript linter that integrates with typescript where you can just say never allow any. And if I were converting a typescript or code based to typescript today, I would turn that on and say it’s legitimate for you to use unknown cause then you’ll have to check it. Y’All have to do whatever runtime checking. And sometimes you do have data that you don’t trust or types that you don’t trust coming in from the outside. But then you’re going to be safe when you’re using it.
Gradual Typing vs Type Inference
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: All the places where I could infer any, and I’m going to say no, you actually have to fill those in with a type. So mostly function arguments or class properties like that. So that’s the gradual typing site. You can add in types progressively. But then the other side of it is you might want to represent types that exist outside your library for an untapped Java script code you’re using. So for example, low dash is a very common utility library that many, many javascript developers reach for it. It’s not written in typescript and it doesn’t ship any types of its own as a result. But there’s a repository called definitely typed, which Microsoft maintains where there are third party community definitions where you can just write out a function signature that says underscore dot map, which is the low dash. And underscore there is a function and it has this type of signature and it doesn’t have any body, so I’m just giving it a declaration.
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: A lot of good typescript code, especially in apps tends to look a lot like the javascript code with little sprinklings of annotations. Like I said, kind of an API boundaries is probably the best way to describe it at functions or class signatures and otherwise very similar to what you would already be writing in the body of a function. You’re rarely going to write any type signatures because it does have good enough inference for that.
Runtime Types
I mentioned earlier, I work with ember js and typescript a lot and we maintain these open source community definitions for ember because ember itself is largely written in typescript at this point, but I mentioned earlier semantic versioning and typescript not doing it. Ember js is probably the most semantic versioning thing in the entire world. It’s very strict about backwards compatibility, so we’ve yet to define a good story there between the two because we really don’t want it to be, yeah, ember ships, its types now and oh you just upgraded from ember three 12 to three 13 and your build broke because the typescript version that we shipped broke or our type definitions broke. That wouldn’t affect anything at runtime cause it all gets stripped out. But it’s still a really bad experience for consumers of member and since typescript, three. Dot. Five might break versus three dot. Four in some small ways. We really appreciate that they’re doing that work because otherwise our lives would be much less pleasant in that space.
Adam: They’re trying, they are trying. You mentioned earlier something that surprised me. So my understanding is right, like typescript exists at compile time at execution time. It’s Javascript, right? But you mentioned looking at a type, so if the type is x then do y. So how does that work? Because I assume that runtime, you just have Java script types. Correct.
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: 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. And so it’s using that notion of I’m going to, and again this is not the same thing as refinement types in liquid Haskell, so please don’t email me dear listeners. I know, I know it’s not that, but there’s an analogy here where it’s taking the type and refining it, using that runtime flow analysis and it can do the same thing with switches. You know switch statement where you have a set of cases within it and stuff like that, so you can actually emulate exhaustive pattern matching against a tagged union. You have to do the work of building up the tagged union yourselves cause javascript doesn’t have those, and then you have to add in some machinery to say a certain that this thing will be never in the default slot, never as a type that if typescript sees that your runtime code ever actually hits it, it says, Hey, this is a type error.
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.
TypeScript Is a Fancy Linter
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: We’ll look at the end of the day, if you just want to write some pretty loose like loose Java style javascript, we’re going to enable you to do that, but over here is the happy path. Do it this way, man. It’s kind of my verbal strategy in those conversations as it were. Yeah. And you can, maybe you can gradually approach it, right? Put it in your build pipeline as like a linter and then you slowly, yeah, and I think that’s one of the reasons the typescript has been successful because people can use it that way and then say, oh, I also learned this thing from reading a little bit about rusty the other day. I wonder if I could do something like that over here. Oh I can. Cool. And that ability to gradually level up in your understanding of how to use types is very powerful. I think it doesn’t feel like jumping into the deep end for a new javascript developer the way that jumping into something like Elmore rust cam.
Structural Types and Shapes
Adam: 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 the vast majority of the time in dealing with Java script, that is exactly what you want because javascript is just dealing with objects as these blobs of data. And you might use the name as a signal to other developers, but for the most part, and this is a place where writing and typescript actually feels much closer to writing in a dynamic programming language, a dynamically typed programming language than most others. It sounds like duck type, it sounds just like duck typing. Yeah, it’s like duck typing that gets checked for you. You say, Hey, this function needs a thing, which is an object which has a name on it and it’s a string. And typescript says, cool, well I have all of these objects in my system which have that. And some of them also have an age on it and some of them also have this walk method on them, but all of them are totally compatible with that because they match that shape and because they match that shape, they’re good to go.
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.
JS Debugging Horror Stories
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.
Chris: Oh No. And I think that’s one of the places where typescript finds a niche is a lot of places, especially if you’re writing large scale applications, they’re writing these big javascript dot comments that are annotating the parameters for the types already. And so you actually end up with briefer smaller amounts of code by adding the type annotations in place of these js dot comments and then the compiler can check it for you. Your also has a super power where it’ll check your js dot comments, which is really cool. It’ll say, oh hey, this is a valid block of js doc and you’ve described this parameters a string, so now will actually check that. If you use that pragma that I described earlier where you can say ts check, which is really nice. Yeah, that’s crazy.
Rust vs TypeScript
Adam: So rust versus typescript, which is better.
Chris: Oh Man. Do you remember how a minute ago I was saying that people say dumb things on these type forums? 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 Rust 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, Rust 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 Rust 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.
Chris: I think the cost is a lot lower than some people sell it as being, but there is a cost to it. You have to think about things that you just don’t have to think about when you’re writing c sharp or javascript or python or anything like this. And by the same token, it’s not trying to be what typescript is trying to be. Typescript is, as you summarized it earlier, trying very hard to meet Java script developers where they are and to enable them to, whether it’s by way of a fancy linter or because they actually just really are in love with elm or pure script or something, but for good reasons or bad can’t write it in their job and all the times it’s good reasons. I mean I love Ellen but it was a running joke at my previous gig that I loved element. I would never pitch it because it just didn’t make sense for us in that context. And typescript made fabulous sense. So whatever end of that spectrum you’re on, typescript is meeting you there and enabling you to do those things and it just really doesn’t have to try to worry about memory management because it’s not shooting for that space.
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 Rust like that seems like a very, those circles don’t intersect. Yeah.
When Not to Use TypeScript
Adam: 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: So I’d say just do it, but most of us can’t. And there’s an engineering tradeoff there and it may not be worth it. It may not be worth whatever velocity it costs you in the meantime. I think it’ll probably pay for itself in the longterm, but I also think that gets at the other place. If you’re really just whipping up something that you intend to throw away and you really intend to throw it away, just doing javascript, if you’re comfortable with that and you don’t care. For me, I’m actually faster building those kinds of things with types. And I’ve also experienced that painful thing where you say, I’m just going to build this little thing to wrap around and execute this as sort of my own mini test configuration that nobody else will ever use, surely. So it doesn’t matter if it’s really well factored, it just has to be a little script that I can get the job done with.
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 delivering value. Right.
Coding on the Radio
Adam: 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.
Getting Things Done
Adam: Yeah. See, this is why I don’t do ad hoc a reading a code in the interview, so 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.
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.
Sticher
Overcast
Dec 02, 2024
42
min