Dan together with Josh Goldberg, a prominent open-source maintainer and author of "Learning TypeScript, dive into the world of TypeScript and JavaScript with a special focus on the upcoming Squiggleconf. In this episode, they'll detail the conference format, including its dedicated days for talks and workshops, and highlight the impressive lineup of speakers who will cover topics like ASTs, TypeScript at scale, and essential documentation practices.

Josh also shares insights into the evolution and practical application of TypeScript ESLint. Expect a deep dive into TypeScript's latest features, such as generics and specific lint rules that enhance code quality and developer experience.

Dan Shappir [00:00:05]:
Hello, everybody, and welcome to another episode of JavaScript Jabber. Today, I'm flying solo both as host and panelist. Maybe some of our other hosts will join us later on. We will see. Our guest today is Josh Goldberg. Hi, Josh.

Josh Goldberg [00:00:25]:
Hi. Thanks for having me.

Dan Shappir [00:00:28]:
You do know that when you wave, people who are listening to our podcast, don't actually hear anything.

Josh Goldberg [00:00:36]:
I was hoping the good vibes would, you know, emanate from the the podcast, but that's a good one.

Dan Shappir [00:00:42]:
Yeah. It reminds me that when my kids were really young and we would drive and they would be sitting in the back and I would ask them something while I'm driving and they would nod their heads. Yeah. So yeah. Anyway, so welcome back to our show. It's been a while. We've had you here before. We're actually going to be talking about similar topics to what we've spoken about in the past, but a lot of, I guess, has happened since then.

Dan Shappir [00:01:09]:
So, hopefully, we can catch up. The topics are gonna be TSES Lint, which is a project you've been working on for a while now, and also your new conference. What's it called? Squiggleconf? Squiggleconf.

Josh Goldberg [00:01:24]:
Yes. Named after the things that give you squigglies in your editor.

Dan Shappir [00:01:29]:
Cool. Cool. Cool. So what do we want to start with?

Josh Goldberg [00:01:34]:
Well, I'm a sucker for going in order. TypeScript ESLint.

Dan Shappir [00:01:40]:
Yeah. Okay. But you know what? Before then, since it has been a while, can you also, you know, provide a quick introduction about who you are, what you do, why it's exciting to have you on?

Josh Goldberg [00:01:53]:
With pleasure. Hi, everyone. I'm Josh. I'm a full time independent open source maintainer. That means that instead of working for one specific company, I'm independent. I work on my own, and I work on open source projects that benefit the ecosystem. For me specifically, the main ones I work on are TypeScript ESLint, which is the tooling that lets you run standard, JavaScript tools like ESLint and Prettier on TypeScript code, as well as ESLint itself on the Committer team and Mocha. So I'm just kinda generally happy to float around GitHub and try to make things better for everyone.

Josh Goldberg [00:02:25]:
I

Dan Shappir [00:02:25]:
as I recall, we've spoken about it in the past, but I think it is worth bringing it up again. Is it really possible to make a living off of open source, you know, especially given that it's free? Yeah.

Josh Goldberg [00:02:41]:
Free as in it's a hard question. It is theoretically possible. Some projects are better suited for it than others. The ones I tend to work on tend to be not very well suited. But I do I do make what is, defined as a livable wage in in my area, which is better than the achievement last year, which was minimum wage. But, it's not anywhere near it was as it was in, you know, a full time salary position for me. So there's a good chance that'll eventually go back once I've made the impact I wanted to in open source.

Dan Shappir [00:03:12]:
So you're what? Living off some of your savings? Is that what you're saying?

Josh Goldberg [00:03:17]:
I don't think I'm that negative right now, in large part because my fantastic wife, my spouse, has a real job and health insurance, which is very important in the United States as some may know. But I do I do get income. I have, community sponsorships on a lot of the projects that I'm on. I I get a share for many of them. I've got book revenue from my learning TypeScript book. Go buy it today. And, generally, there are some people who sponsor me individually on GitHub Sponsors. So I'm not hemorrhaging money.

Josh Goldberg [00:03:47]:
I'm just not making a lot of money.

Dan Shappir [00:03:49]:
And if people who are listening to us do want to contribute to your efforts, what's the best way to go about it?

Josh Goldberg [00:03:56]:
Well, first of all, they should feel very good about themselves because that's very kind and noble of them. Thank you. If they wanna support me specifically in the stuff that I'm specifically doing, github.com/sponsors/joshuakgoldberg, or if you just Google me or look me up, my name's on my site. For any of the projects I work on, if that's particularly exciting to you, especially TSCS Lynch, they all have open collectives that you can sponsor. So there's there's definitely a way for you to give me money if if you want to.

Dan Shappir [00:04:23]:
And you mentioned your book on TypeScript. When did that come out?

Josh Goldberg [00:04:28]:
It's been a couple years now. I believe 2022, mid late summer. Sue O'Reilly learning TypeScript, and it has this beautiful yellow and colored bird on the cover. And

Dan Shappir [00:04:40]:
given the name Learning TypeScript, I gather that it's primarily for people who are not familiar with it and want to get into it like newbies effectively.

Josh Goldberg [00:04:50]:
Exactly. Yeah. The the general flow of the book is that you can start with roughly intermediate JavaScript knowledge. You should know how variables and closures and stuff like that work. You don't need to be super fancy advanced JavaScript expert. You don't need to know, you know, I don't know, symbols and stuff like that, But you don't need any prior knowledge or experience with types through whatever, c sharp, c plus plus, Java, Rust. None of that is necessary. If you already know it, great.

Josh Goldberg [00:05:16]:
TypeScript works a little differently, so you'd still learn stuff. But you can come in with just JavaScript and emerge a relatively competent TypeScript developer.

Dan Shappir [00:05:24]:
You know, that brings up an interesting point. So, a few weeks back, we we recorded an episode with, people talking about the lead code lead code test that so many companies are using these days when filtering out applicants. And, I wasn't actually able to participate on it, so I'm just listening to the recording like everybody else. And they brought up, one of the things that they discussed was about which programming languages are supported by that platform. Turns out that many are. You can practically choose any language you want. And both JavaScript and TypeScript are supported as languages apparently that you can use, for, you know, solving the lead code challenge. And I, you know, I was thinking about it.

Dan Shappir [00:06:19]:
And if I were to do it today, I would you know, there's a good chance that I would choose to use JavaScript, but I'm, like, wondering why anybody would use TypeScript as opposed to JavaScript when solving a LeetCode challenge. What do you think about that?

Josh Goldberg [00:06:42]:
That's a good question. I don't know what I'd use, honestly. I haven't done LeetCode in a while. I've I think it's a fun little hobby that one can do, like a niche little area programming, and I detest how associated it's become with job interviews. That's just not a core competency, that we use day to day as much as, you know, debugging or pairing. But, I digress. I don't know. It's the rule that I normally go through is the rule of 3.

Josh Goldberg [00:07:09]:
If I'm using more than 3 files or working with 3 or more people in a project, I'll switch from JavaScript to TypeScript. Leetcode doesn't really satisfy that rule. So the overhead of TypeScript needing to or trying to get you to define types for things or being aggressive when you haven't defined enough types oftentimes isn't worth it. It can be useful, though, if you do and if you have experience and if you feel comfortable writing out types or just using any in a lot of places. So, yeah, I can see the the motivation for it, but I wouldn't go for it myself.

Dan Shappir [00:07:42]:
Yeah. Me too. I I'm thinking that probably the sweet spot for dynamic languages is pro rapid prototyping. And with Leetcode, you are that's essentially what you're doing. You're trying to hammer out a working solution as quickly as possible. You know, usually, you're constrained in time writing anything that at the end of the day doesn't actually get translated into executable code seems like a waste of time, in that context. So so yeah. Yeah.

Dan Shappir [00:08:19]:
But, you know, in any event, it's nice of them to support it as an option. You know? Interesting. I once, by the way, commented that my ideal development environment would be me writing JavaScript and everybody else writing TypeScript. That way I don't have to mess around with types, but everything that I do is supported by types, and I get all the completion. And and the the only problem with that is that everybody else includes me from about a week ago. So, you know, I might be smiling now, but I'll be sad in a week if I write my stuff in JavaScript.

Josh Goldberg [00:08:59]:
Yeah. I think the really baller move for interviews is to to use the TypeScript type system instead of the the runtime. That that's really where we shine. Yeah.

Dan Shappir [00:09:08]:
Yeah. Using, the type system itself as a as a programming language. Yeah. I know some people who do that, who dabble in that sort of thing. I used to do that sort of crazy stuff when I back in the day with c plus plus because, sexually, any language which which supports sufficiently sophisticated generics can be used as its own, you know, quote, unquote types, programming language because you you get condition you effectively can implement conditionals and loops, via recursion. So so, yeah, it's it's an interesting interesting approach, but, yeah, mostly mostly a game and not something you want to do anywhere near production code.

Josh Goldberg [00:09:59]:
Yeah.

Dan Shappir [00:10:01]:
By the way, one one more interesting point about this whole thing about TypeScript and when it's appropriate. I have to confess that when TypeScript initially came out, my initial attitude was kind of negative because all the original demos were, around classes and and enums and stuff like that. And it might not be surprising given that it was created by the same Microsoft people that gave us c sharp. And and, you know, back at the time, they kinda, I guess, didn't really know any better. But my feeling initially with looking at the original sample, TypeScript code that they were, you know, showcasing was that this is kind of a poor man's Java. And since I much prefer JavaScript to Java, that feeling that TypeScript was kind of pulling me back into the Java realm was something that, you know, really rubbed me the wrong way. And I kind of, like, totally flipped on that. I did it, like, a 180 on that when I realized that you can do, you know, function JavaScript functional style programming and get all the benefits of types with TypeScript.

Dan Shappir [00:11:30]:
And now the TypeScript has come such a long way, and you got so much inference going on and this the cool things with generics and stuff like that, you can achieve very cool type safety and without having to use classes and interfaces at all in your code. So yeah. So that's my confession about TypeScript. Does it kind of match your own feelings about the topic?

Josh Goldberg [00:11:59]:
It does. Yeah. I think you really hit the nail on the head on the 2 big advancements in marketing that TypeScript had. One is that at the beginning, they were really appealing to people on the in large part on the premise of you can use these features you've been missing, which included both classes and the type system. Nowadays, the marketing doesn't really mention classes, both because that's a core part of the language now over a decade later and because it act we accidentally ended up with the the misconception in the community that TypeScript is more for class oriented rather than, say, functional approaches, which is net now that you've hit the nail on the second point that TypeScript actually supports functional programming and really, really non class but still type safe approach as well, that I would even say that that's a better way of using TypeScript in many cases. So I think it's just really cool to see how marketing evolves over time as people learn better how to use and how to market a tool like TypeScript, for example.

Dan Shappir [00:12:57]:
But is it just, marketing, or is it also how TypeScript itself has technically evolved?

Josh Goldberg [00:13:05]:
It's a good question. I would love to hear you interview every 2 to 4 years at the very rarest or at least common, core folks in the TypeScript team to see how their answers to this evolve over time. I'm sure it'd be fascinating. I think that if you look back at how TypeScript's discussions, which are many of which are public, like their meeting notes and their issue responses have been on GitHub, it's been pretty consistent that they don't try to specifically go for, say, classes and it's just that that was one of the big things they had to implement early on for standardization, for marketing, for I don't say marketing a derogatory term. I just mean these are the things that people needed from TypeScript. But they've they've been virtually every discussion and tried to pull the the focus back from specific things like, you know, supporting, I don't know, injectable classes or supporting functional style insert paradigm here and really try to think what are the common community needs for type safety? What are the ways of bending or describing or manipulating types that folks are commonly using across many different teams, organizations, paradigms? And how can we build that in a diagnostic way in the type system such that anyone benefits, not just specifically, say, classes?

Dan Shappir [00:14:21]:
I'm totally with you on that. I think that first of all, I have to say that in a lot of ways, the TypeScript people, like, have a super hard job. I I compare it to herding cats. Basically, you take the the the poster child for dynamic languages, a language that is dynamic but also has dynamic objects. Like, everything in JavaScript is dynamic, is it's dynamic as you can get, and then try to enforce a static type system on top of that. And my feeling is that especially in recent years, and to be fair and honest, I I'm not sufficiently knowledgeable about the history and evolution of type script to tell you, you know, which features came first and which features came in later and, you know, what happened sooner or later. I'm I'm more knowledgeable of JavaScript and TypeScript in this regard. But, what I see now is that in in the past, I had this kind of feeling that TypeScript is trying to force me to do things certain ways that sometimes I wanted to do.

Dan Shappir [00:15:38]:
I had certain paradigms that I implemented in JavaScript in ways that I really liked, and I couldn't get them to work with properly with TypeScript. And now I can. Now it's it's difficult for me to say whether it's because TypeScript has evolved and improved or because my knowledge of TypeScript has evolved and improved. Might be probably it's both. But the the feeling is that you can now be much more expressive in what you can achieve with TypeScript, and you don't necessarily have to forego, you know, mainstream JavaScript paradigms just to get the benefits of TypeScript.

Josh Goldberg [00:16:23]:
Yeah. Agreed. I think included in that second point of you're you're more happy with TypeScript or more TypeScript yourself, part of that includes understanding intuitively what are the types of flows or types that TypeScript is easily able to represent. There are a lot of complex things you can represent with TypeScript with a lot of glue and confullery, but the stuff that's really clean and beautiful and succinct, people tend to gravitate towards the more they write TypeScript, which I think is a really good thing because TypeScript types are how we generally represent JavaScript concepts and and the way our data flows in code. So if something is difficult to represent in TypeScript, there's a very good chance that it's based on something that's not easy to explain to others or easy to represent in code. I think there's this kind of beautiful synergy there.

Dan Shappir [00:17:10]:
By the way, Jay Larky comments that, quote, I think JS got better, so they had to do less stuff on top of JS nowadays. Yeah. I I agree, but it's not doesn't necessarily mean that the TypeScript people have less work because you you need to support in the type system all this new JS stuff as well, especially since a lot of the TypeScript sophistication comes from, the the ever growing ability to statically analyze the code and figure out stuff like type narrowing based on logic that you actually see in the code. So if you do an like, an if in the code and bail out, like, short circuit in some condition, then it probably also narrows the the types moving forward because you've kind of ejected out that those aspects of the types that are no longer relevant. By the way, speaking of all of that and taking us finally to take it to t s e s lint, it it, you know, brings up an interesting point, you know, given all this sophistication and power in TypeScript itself, why do we actually need the linter for TypeScript? Isn't TypeScript itself enough in that regard?

Josh Goldberg [00:18:36]:
Oh, I love it. There's so many good reasons why one would want a linter, and a few bad reasons. Just for my emotional sake, if you don't mind, I'd like to start with the bad. A lot of folks Go for it. Yes. A lot of folks used to use ESLint for a few things that, among others, that we no longer recommend in the linting world. Formatting or silly stylistic rules would be the big ones. ESlint is a linter, which means you it allows you to provide a bunch of individual rules, which are little pieces of code that yell at you if your code is not working the way it should or doesn't look the way it should.

Josh Goldberg [00:19:13]:
And then that's separate from a formatter, which reformats your code, or a type checker, which looks at all the types in your code. So formatter, winter, type checker. A linter is structurally not very good at formatting. So if you're using ESL for formatting, there are a lot of gaps. Like, there are a lot of little edge cases that aren't really covered by any one rule, or it's hard to write that type of logic in a Lint rule. It's much easier to do a big format or sweep like with Prettier. So there are projects

Dan Shappir [00:19:38]:
that is about just to make it clear to our audience, about stuff like indentation, line lengths, line breaks, stuff like that.

Josh Goldberg [00:19:48]:
Yeah. Yeah. Semicolins, you know, white space type. Yeah. So, there are there is a project really good one called ESLint Stylistic for enforcing formatting with ESLint, but it's not part of core anymore. And a lot of people associated, oh, it's yelling about me, yelling at me about semicolons with Linters, and then just stop using Linters altogether.

Dan Shappir [00:20:09]:
It's

Josh Goldberg [00:20:10]:
not the not the right conclusion. But there are a lot of really good things you can do with them. Generally speaking, linters can apply logic in cases where it might be type safe. For example, you might be creating a promise, which is type safe, but then you do something dangerous with it that's still type safe, such as not handling the rejection case of that promise, like if you forget to await it and then you console log it. That's all type safe, but that's probably not what you wanted to do, which means you still want the tool separate from your type checker to let you know about these probable mishaps.

Dan Shappir [00:20:43]:
So can you give a couple of examples of some of the rules that TSCS Lint enforces? I know we discussed those in in the previous time that we had you on the show, but still, I think it's still worth reviewing. Also, if you've got some new ones since then, you know?

Josh Goldberg [00:21:01]:
Oh, yeah. The classic example that we always jump to is promises like the, you know, you forgot to await type stuff because that's that's a huge source of bugs. And we get a lot of reports from from people that that's the key thing they need from us. You know, having a having a function that returns a promise, declaring that in your code, and then passing it to something that doesn't know the function it's calling that you're passing returns a promise. So then the async logic just floats off in the distance somewhere. That that type of weird edge case that is still type safe, but not right. Another one would be for in array is the rule or no for in array, where there are 2 common ways of looping over an object in JavaScript. There's for in and for of.

Josh Goldberg [00:21:44]:
For in loops over the keys, for of loops over the values of an iterable. So if you use for in on an array, you'll get the stringified array keys, which is technically type safe. That's technically something some people might wanna do. But in practice, why the heck would you ever wanna do that? That's that's a lint rule yelling at you, area of concern.

Dan Shappir [00:22:02]:
Yeah. Forian is one of those things that's in the language. It's legal. It probably doesn't it doesn't do what you probably expect, and therefore, you should probably not use it. Or put another way, if you're Kyle Simpson, then you probably have a very good reason to use it. But otherwise, you probably don't and don't and don't.

Josh Goldberg [00:22:24]:
Yeah. There's I think you you touched on such an interesting point that there are a lot of people who are very, very deeply experienced, knowledgeable, influential JavaScript developers who do not see the value of linting or at least do not themselves experience it because they instinctively you know, they always handle their promises. They know what they're doing. They don't write for in, on an array. They write for of. But a lot of the value of the linters for people who don't have, you know, 20 years of writing JavaScript and then TypeScript. People who are still new and learning.

Dan Shappir [00:22:51]:
To be fair, there's a certain point in it. I I'd say not seeing the value in linting is a bit harsh. I would say rather that they would disable certain rules that you'd probably want to keep enabled for most people. And, but but the reality is that usually, like, you you don't work alone, and you want to conform to the race the rest of the code base. So the example that I like to give, and I don't know if there's a linting or formatting rule for that, is that whole debate about whether when you're creating functions named functions, whether you should use the function keyword or whether you should do something like a const name equals an array. I see a lot of people using, now now obviously, they're not identical. There are certain differences, and we can, you know, touch on those. You know? But but it to great extent, it's an it's just an issue of of personal preference.

Dan Shappir [00:24:07]:
My personal preference is the function keyword, and I can explain why that is. But at the end of the day is what I do is I conform with the with the project code base. Like, if the project use it does prefers, arrow named arrow functions, I will use named arrow functions. Because if you start, you know, deviating in your own code, you're creating an unwanted and unnecessary cognitive overhead because people will look at that piece of code later and say, hey. This code looks different than the rest. Why is that? Is it doing something different? You know, and they have to start thinking about it, you know, start they they they don't trust their instincts around it anymore, and that's a bad thing. So consistency above everything else. And that's another big benefit of linting, both stylistic linting and semantic linting.

Josh Goldberg [00:25:09]:
Strongly agree.

Dan Shappir [00:25:09]:
That that it generates consistency.

Josh Goldberg [00:25:14]:
Yeah. That's something a formatter can't do because, as you said, sometimes there is a subtle logical difference between different keywords or different types, and that's something a type checker won't do because, well, it's all type safe. That's exactly what one of the big use cases for linter is.

Dan Shappir [00:25:29]:
Keeping on. So you said that some of the the main benefit of linting is to highlight things that are correct, like using for in or not doing not putting a weight on your promises or maybe not putting a catch on or somewhere. So those are all things that are totally valid in terms of the code, but are probably something that things that, you know, are not right. Let's put it this way. You probably don't wanna do. So it's it's it's a warning rather than an error, would be the way that I would phrase it. And then you want and that's where the linter kind of steps in. Is that the way that you would phrase it as well?

Josh Goldberg [00:26:28]:
Yeah. It's a warning that in most cases, you generally still want to fail the build on. Yes.

Dan Shappir [00:26:33]:
Yeah. For sure.

Josh Goldberg [00:26:36]:
There's, one more really good use case that gets forgotten a lot. You can write custom Lint rules. That's one of the big things that ESlint became successful from being able to support early on. If you're on a team that, let's say, moving from one way of calling an API to another, you can write a lint rule enforcing, you know, that people use the new way, not the old way. And you can even write a fixer, like an auto fixer in your lint rule to migrate code from the old way to the new way as a form of a code mod. And having been on a web platform team, I can tell you that's incredibly helpful and useful.

Dan Shappir [00:27:07]:
Mhmm. That is nice. So what is new in t s c s lint? I gather that a new version is coming out, came out, about to come out.

Josh Goldberg [00:27:20]:
Came out. TypeScript ES on v eight. Thank you for bringing it up. We,

Dan Shappir [00:27:26]:
v eight is a special name.

Josh Goldberg [00:27:28]:
I know. We've had a few people get confused about how it's not the tomato juice and it's not the engine underlying, you know, Chromium and JavaScript, but it's it's our newest major version. It has a lot of good things in it. Just the high level overview is every major version we improve and iterate on the list of recommended rule sets, our little shareable configs. This one has ESMV 9 support, which was unfortunately kinda delayed on our end. And it has this new thing called the project service, which makes typed rules the most powerful controls. We offer a lot more, we hope, easy, straightforward, understandable to configure. So we're really excited about it.

Dan Shappir [00:28:07]:
So what's the thing that you're most excited about in the context of of the new version?

Josh Goldberg [00:28:17]:
The project service. A lot of the lint rules that we just talked about and that are elsewhere mentioned about being awesome and powerful need type information. For example, we said no for an array. Well, how do you know what is an array? Or, you know, properly calling a a function that's async and makes a promise. How do you know the function is async or returns a promise in general? You have to use a type checker for that because what if you import it from a file or some other NPM package or something? And in order to do that, we have to then call it to the TypeScript APIs. And there are not that many projects I do that. So this is still kind of a new and explored for area in the realm of JavaScript TypeScript tooling. So the project service is this term for this new set of APIs that we're using from TypeScript that align type checking to behave more like what you're using your editor, which means it's a little easier to set up.

Josh Goldberg [00:29:06]:
We can infer more stuff, and it shouldn't have these weird differences where ESLint understands something differently than what you see in Versus Code.

Dan Shappir [00:29:14]:
Cool. So it's like effectively leveraging the language server to a greater extent.

Josh Goldberg [00:29:22]:
Yeah. Yeah. A lot more code path sharing under the hood. We use what TypeScript calls it the project service, which is the set of functions provided by TypeScript that you can pass a path to a file, and it'll give you back, here's how to describe type information for the file, some APIs like that, which is really exciting because previously we were manually creating those things on our end, effectively doing what the project service does for us. And because we are not TypeScript, neither technically nor organizationally, the people behind it, we weren't doing as good of a job as what the project service is able to do now.

Dan Shappir [00:29:54]:
By the way, one more point that, Jay Larkey brought up in another comment is that, quote, some things are framework specific, like rules, of hooks or solid lane for, restructuring props. Yeah. Yeah. That's absolutely true. I mean, you know, you these days, most TypeScript slash JavaScript developers work in the context of a framework and a meta framework. And there are, let's call it, additional rules that are or, that are or paradigms that are more specific for whatever framework you choose. So things that, again, are totally legal in the context of, you know, general purpose TypeScript or JavaScript might be things that you want to avoid in the context of framework. And indeed, the structuring is probably in, and issues with the structuring in in, Solid is probably a a good example where where you might unintentionally lose reactivity because of the structuring that's perfectly legal in in JavaScript and TypeScript.

Josh Goldberg [00:31:05]:
Yeah. Shout out Jay Larky. Great point.

Dan Shappir [00:31:08]:
Yeah. By the way, it's an interesting in another context, we we had the people from the meta team a few, what's it, weeks, months back, talking about the new React compiler. And interestingly, that compiler also has a linting aspect to it. They have, like, the rules of React, and they're looking at ways to enforce best practices of React using that compiler. So it'll be interesting to see how they flag things, whether it's it's an errors or warnings or whatnot. Like you said, even if it's warnings, you there's a good chance you still wanna break the build. But, interesting. Yeah.

Dan Shappir [00:31:59]:
It's interesting to see linting making its way into so much stuff.

Josh Goldberg [00:32:04]:
Yeah. I'm really excited about it. I think it's a really, really cool area. It's really useful. And now that folks respect it, you know, it's it's getting more and more stuff.

Dan Shappir [00:32:13]:
Mhmm. And I now that that's out, I imagine that you work you've started working on the next version. Right?

Josh Goldberg [00:32:24]:
Yeah. We tend to reserve a few months, even a year or 2 at most, probably just up to a few months after each major version of just cleanups. You know, we we released this big new thing, this project service, which is a different way of configuring type planting. Well, now we have all the myriad different ways people were previously setting up type printing, coming in and telling us ways it does or doesn't work for them. So there's a lot of cleanup there. Also, I think there's a lot of value in a project. Just spending time working on things that don't have a huge determined purpose. Like, you know, paper cuts, cleanups, documentation improvements, which

Dan Shappir [00:32:58]:
is I

Josh Goldberg [00:32:58]:
think the phase we're in right now.

Dan Shappir [00:33:00]:
Cool. So you're not yet thinking so much about v 9 at this point in time?

Josh Goldberg [00:33:06]:
Yeah. Not so much. I think long term, there is a new snazzy thing we wanna start using more, which is there's an API that TypeScript used to not expose called the assignability API. Is type assignable to. Previously in in type checking APIs, to be the stuff that lint rules can use, you can you can get the type for something. You can say, get the type of this function call, the returns type, and see if it's, let's say, a promise or something with a dot then. But you couldn't check 2 things and see if one is assignable to the other, like if this number is assignable to that string or something else. But now that that API is available to us, they they marked it as stable and you can use it.

Josh Goldberg [00:33:50]:
We think there are a lot of really interesting lint rules you can do with it. Like, for example, you could instead of just saying no inferrable types, don't add a type annotation that's triple equal to the same as whatever type something is. You could write a Lint rule that bans type annotations that are wider than the thing. Like if you say const value colon string equals quotes, we can say that string is actually losing type information. TypeScript, by default, would be able to infer that this is some string literal or union of literals rather than just the general string. So very exciting stuff. I know.

Dan Shappir [00:34:27]:
Yeah. No. This is this is cool. Look. There there is a challenge here, and it's it's an issue that's been brought up by, people like, Theo, I think, and others, also Ryan Carniato, about, how the like, that TypeScript really has 2 target audiences in a way. There's the the the distinction that they made was between application developers and library developers or library makers. That application developers usually, are able to use it at at you know, without diving too deeply into sophisticated types. And library developers or people that create APIs are kind of forced to.

Dan Shappir [00:35:26]:
I think the the line is often drawn around generics, but, you know, I'm it seems to me that generics is becoming more, like, you know, public domain, like, in in it's it's no longer such black magic that as it used to be, I think. But, you know, it's, it's an interesting point, and I'd love to hear from our audience about that, what they think. So it used to be that, you know, if you were an application developer, you you could use type TypeScript without having to understand how generics work. But if you were a library developer, if you created APIs, you had to understand generics. It's interesting to think whether or not a tool like e like TSC SLint can, in a sense, make it easier for people to up their TypeScript game, like, to be more like library developers and not and and being able to do it without getting too much in the weeds. Like, the alternative, of course, is to use some sort of, chat GPT, like, tool to write your TypeScript for you. But, I'm wondering whether something like ESLint TSCSint can also help in that context. What do you think?

Josh Goldberg [00:36:53]:
Oh, I have so many thoughts here. Yes. Strong agree. Another big benefit of Lint rules can be best practices, not just the, you know, don't use for in on an array, but things like, preferring, you know, stylistic consistency in how you write your types. Types versus interfaces is one of the big debates in TypeScript where much like the functions you mentioned earlier, the answer is it doesn't matter. Just be consistent. We do have quite a few rules though that that flag common bad practices that results from people not having that full deep understanding and then let you know, hey. This is why it's wrong.

Josh Goldberg [00:37:30]:
Here are the option or options to fix it. I think the 2 really exciting big ones, that I can dive into if you want are empty types and, the golden rule of generics or unnecessary type parameters. Those are 2 big ones that a lot of people trip up on that we now have Lindt rules to help people

Dan Shappir [00:37:47]:
learn more. Please do. Please do.

Josh Goldberg [00:37:50]:
Awesome. So the empty object or the just curly boys object type in TypeScript that describes any object, any value other than null and undefined. So you can say let value colon, cur curly brackets, just empty object, equals quote something. The string is a value in JavaScript and TypeScript, therefore, it's assignable to the empty object type. Same with number. The literal zero is allowed, which is horrifying and confusing to many people. So we we have a lint rule that says, hey, don't use the empty object type, except in certain situations where it's reasonable to. Instead, what you probably want is an insert list of common alternatives such as unknown or unknown.

Dan Shappir [00:38:33]:
So, basically, just to clarify though, in in TypeScript, when you use empty object as a type, not as a value, but as a type, it means anything which isn't null or undefined.

Josh Goldberg [00:38:49]:
Yes. I might be missing some nuance there, but that's roughly what it comes out to in in production, in practice.

Dan Shappir [00:38:56]:
Okay. To be honest, I I'm, you know, I'm struggling to remember if I've ever used this. Probably not. I prefer my types to be a bit narrower.

Josh Goldberg [00:39:12]:
Fantastic.

Dan Shappir [00:39:13]:
It's not much better than an any. Let's put it this way.

Josh Goldberg [00:39:17]:
Yeah. It's it's like it's this weird kinda halfway between any and unknown where a lot of things are assignable to it, but you can't really do anything with it. And, honestly, some people just happen across the type and then use it instead of unknown. That's, like, a really common slip up there where they should've just used unknown or any.

Dan Shappir [00:39:39]:
Yeah. That's what Jay Larky is saying as well.

Josh Goldberg [00:39:43]:
Hi, Jay Larky.

Dan Shappir [00:39:45]:
Yeah. So you you've got an e s t s e s lint. It's a problem. I I start saying e s lint, and then I remember to say t s e s lint. So you've got a t s e s lint rule that basically, what, forbids it?

Josh Goldberg [00:40:02]:
We used to we used to have a rule called band types, which banned a list of problematic built in types such as that and uppercase and number, as opposed to lowercase and number, same as string and boolean. We split that up into several rules. So the the specific rule, we're talking about now, I have to go to our website to look up the name because I can never remember, is, no empty object type. That's specifically for that one. And then we have a few other rules for other problematic built in types like the yaw case built

Dan Shappir [00:40:32]:
ins. So it's basically it's kind of like JavaScript in a sense, and it's not surprising that once TypeScript adds stuff in, it's very difficult for them to take it out without, you know, breaking as existing code bases. But it's easier for you guys to add rules that forbid it.

Josh Goldberg [00:40:54]:
Yeah. And arguably, in this case, they made the right choice by having it as is. One might write, let's say, a generic function that takes in a t, a generic type that extends any object with length number as a property. So you could pass in strings, arrays, some object that happens to have length on it. That's all fine. Intentionally, that type, that squiggly brackets, length, number type allows arrays because arrays are objects that happen to have a length property. It would be weird and confusing if removing that length property from the object now meant arrays weren't allowed in this case. So there's no real right answer here.

Josh Goldberg [00:41:31]:
Either you have a weirdness in the type system or you have a weirdness in the type system that also trips people up sometimes in a different way than before.

Dan Shappir [00:41:40]:
Interesting. Okay. So that was one interest example. What you had the second one, was it? What was it?

Josh Goldberg [00:41:49]:
I respect and appreciate that you remember that. I'd forgotten about it. It's a new rule called no unnecessary type parameters. It's based on what's called the golden rule generics, which is actually comes from another TypeScript book published by O'Reilly and, authored by Dan Vanderkam, who then was a coauthor on the PR adding this link rule. Shout out, Dan Vander Cam. But the idea is, people oftentimes write generic type parameters for functions that don't actually do anything or actively hide type errors inside. The most common one is the write wrappers around JSON dot stringify or some kind of parsing thing where they'll add in a generic type saying, okay, the result of this function is whatever generic you pass me. Let's say, generic JSON dot stringify my type, return JSON dot parse thingy as my type.

Josh Goldberg [00:42:40]:
The problem is there's nothing in the type system that actually verifies the value you you returned from that function is the type you said it was, and there's nothing at runtime either. So this is unsafe. Someone could pass a totally invalid string and your type parameter usage made it look like the return of that function adheres to that type even though the totally invalid string gave you some other garbage. So this is what's called the golden rule of generics. Only use type parameters if they are actively useful, if they're actually used to relate to types later on, or if they're somehow used repeatedly throughout your type signature. This rule is new, and I'm still not sure I'm quite good at explaining it. Did that kinda make sense?

Dan Shappir [00:43:21]:
Yeah. But I'm still thinking about it because well, obviously, if there's a gen type that you pass in that you don't actually use, like an unused parameter, that's really easy to flag. But you are talking about something else.

Josh Goldberg [00:43:43]:
Yeah. Unused would be that it's declared once and never used again. Unnecessary in this context would be that it's declared once and used once, such as in the return of a function. The point of a type parameter is to relate 2 things, to say based on the input, the output is different. If you're not waiting for 2 things, what's the point?

Dan Shappir [00:44:03]:
Yeah. If if you're just, let's put it this way. If the type can never be inferred, then it's kind of and it's kind of pointless in a sense. Yeah. I need to think about that, though. Sure. Like, you might explicitly pass in a particular type. Let's put it this way.

Dan Shappir [00:44:34]:
Whenever I I'm whenever I'm using generics and I find myself being required to explicitly specify the type rather than having it being inferred, then it kind of feels like a code smell.

Josh Goldberg [00:44:54]:
Yeah. That's a great point. Both on this context and just the general usability of you should structure your, you know, generic such that people don't have to do weird explicit things. The I think a better example that I should have given to start would be, let's say you're writing a generic log function. Log takes a type parameter t and a single value of type t and returns void. So you could like log parenthesis some string or log parenthesis an array or an object or whatnot. There's no point to that t, to that type parameter. You're not returning it.

Josh Goldberg [00:45:23]:
You could have said unknown for your values type, and there would be no functional difference in your code or its types. So that t, function log t parenthesis value t, it's not unused because the value is still type t, but it's unnecessary. It doesn't change the return type. It doesn't relate anything. Does That make sense?

Dan Shappir [00:45:43]:
Yes. Here's the thing though. Because in other in other programming languages, statically typed programming languages where where the type system is part of the actual compiler, languages like c plus plus or Java or c sharp, then this case, it is useful Mhmm. Because that's for two reasons. First of all, that's how they make themselves more like JavaScript. And the second thing is that it allows them to have different implementations thanks to functional overloading. So they can have, like, a generic parameter, like you said, t, and the type goes in, but then they have a different implementation if t is a string or t is a number or t is an area or whatever. In JavaScript, those things are meaningless.

Dan Shappir [00:46:47]:
First of all, you don't need to create dynamic on type of JavaScript because it is. And with TypeScript, you'd like you said, it's just any and you've got it. You've got the same dynamic capabilities that you had before. And you don't really have implementation overloading. So so both of those benefits that you have in other programming languages are kind of meaningless in the context of of TypeScript. But like you said, it's it's still legal. So, yeah, it's it's a place where the linter can kind of step in. But, yeah, I think that's a really good example.

Josh Goldberg [00:47:27]:
Thanks. What we've seen when people adopt the rule and larger code bases is they'll have the occasional little thing like the parse or the log function. It'll catch, you know, save them a few characters or some clarity here and there. But then deep in their utilities library, there will be this long trail of deleted code where there's this chain of whatever 5 things deeper. At the very bottom of the chain, there is an unnecessary type parameter. And because of that unnecessary type parameter existing, they previously had all sorts of places passing type parameters through, piping it down to get there. And once we remove the necessary type parameter, we could delete a dozen different type parameters in their code, making it all simpler automatically or semi automatically with the rule, and it it doesn't actually harm or remove anything that was useful. So this rule, I think, is gonna be more and more exciting to people as time goes on and we advertise it and learn about it more.

Dan Shappir [00:48:20]:
Yeah. I've been thinking about another way to phrase it. At the end of the day, we have to remember that in TypeScript, ultimately, all the types gets stripped away. Types that you put in have zero impact on the code that gets generated. They're they're totally they're deleted. In this context, by the way, you know, it could have been a pick, but it's interesting what then what node is now introducing with that ability to like, with their support for TypeScript, which which literally just strips out all the types. And and therefore, if if the types have zero impact on runtime, their value is that they assist you during the development time. But if they don't do that, then they're pointless.

Dan Shappir [00:49:11]:
Yes.

Josh Goldberg [00:49:13]:
Yeah. Well, I mean, I would say there is one point to them, which is that some people feel very good when they put types in that are very complicated. And and that honestly is a reason for a lot of the really complex types out there. And, you know, sometimes it's worth it. Sometimes it's not. I think a lot of developers go through a lot of growing pains, adding types, getting excited about it, and then realizing, oh, no. Not all this was useful before they find that beautiful zen of only adding them where it's it's actually functional.

Dan Shappir [00:49:41]:
Let's put it this way. You can have sophisticated types in your type script if the end result is that the actual user of the API can avoid specifying any types. That's the true beauty of sophisticated types in in TypeScript.

Josh Goldberg [00:49:57]:
Yeah.

Dan Shappir [00:49:58]:
If if you if the user of your API needs to specify types, like in generic types, then then my argument is that it's it's a code spell. You kind of failed.

Josh Goldberg [00:50:10]:
Yeah. It'll be cool to

Dan Shappir [00:50:13]:
see

Josh Goldberg [00:50:13]:
if someone could enforce that with a lint rule. You know? I don't know how that would work, but there whenever it was a best practice, my instinct is to try to encodify it even if it's not possible. You know? There are some best practices that are not really code capable.

Dan Shappir [00:50:26]:
So unless you've got more things that you want to say about TypeScript and types and and linting, I think we want to talk a little bit about squiggleconf, don't we?

Josh Goldberg [00:50:35]:
Yeah. Let's do it. Squiggleconf, a conference for excellent web dev tooling. Sparkle emoji.

Dan Shappir [00:50:44]:
It's it's one of those times where you actually want those automatic reactions that you get on the Mac where you do, like, something like that or balloons pop up. I can never get it to work when I want it to work. Yeah.

Josh Goldberg [00:50:55]:
I think I disabled them at the OS level and then completely forgot about it, and I always get disappointed.

Dan Shappir [00:51:03]:
So squiggle, I like, I think you might have said that it's because of the squiggle lines that we get from developer tools that, you know, want to highlight certain things or draw attention to certain things, so they put a squiggly line under it. I actually think that it it came. It was we had it first in things like Word or Office before it actually made its way into the developer tooling, I think.

Josh Goldberg [00:51:31]:
Yes. Like, I also think that, but I'm not sure myself.

Dan Shappir [00:51:35]:
Yeah. Like spelling errors and then grammar errors and stuff like that. Anyway, so that's the multi that's that's where the name comes from. Right? It's because the the the topic of the conference is developer tooling. Right?

Josh Goldberg [00:51:51]:
Yes. We're talking about, I mean, the catchphrase is excellent web dev tooling, but in general, yeah, it's anything that you as a person writing web code, such as without limited to, JavaScript, TypeScript, Rust, might want to learn about. So everything from TypeScript at scale at, say, how Bloomberg does things to the person who made all my zeesh is talking about the journey of that open source tooling and the lessons learned.

Dan Shappir [00:52:15]:
So first of all, when and where?

Josh Goldberg [00:52:18]:
October 3rd for talks, and then morning workshops, October 4th, that's a Thursday, 2024. So at time of recording, in a month and a half.

Dan Shappir [00:52:27]:
And it's like is it online? Is it physical? Is it both?

Josh Goldberg [00:52:32]:
It's physical. We'll put the talks up, for free videos after the conference, but the location, the venue is, the attached theater at the Boston New England Aquarium. So we have got a bit of a fish theme. I will say there's an excellent penguin exhibit next door at the aquarium itself, and we're on the pier, you know, like, on on the water. So I think it's gonna be a lot of fun. Lunch is gonna be at Fenwell Hall, the, like, really nice 2 of our STEAM marketplace right next to the venue, and because it's a Thursday during the week, it's gonna be not too crowded.

Dan Shappir [00:53:05]:
And it's so it's one day for the talks and the second day for workshops. That's the format?

Josh Goldberg [00:53:11]:
Yeah. Morning workshops. We're trying to keep it a little smaller. I think our deal would have been 2 days of talks with some workshops, but it's our first time, and we wanted to make sure we could get it right before really going big.

Dan Shappir [00:53:22]:
Can people still get tickets?

Josh Goldberg [00:53:25]:
They can, and I would encourage them to do so. Fun fact that a lot of conference organizers have told us, we've seen also, that most people wait until the last minute to buy tickets, which is horrible for 2 things. 1, it's well, you never know. Maybe they'll sell out. 2, it's very scary for us conference organizers

Dan Shappir [00:53:41]:
to see stressful.

Josh Goldberg [00:53:43]:
Yeah. So please buy tickets to go to the conf. We've got bulk discount options on the website. We're, happy to work with you if you need help getting it. We also have volunteering, options if you can't afford a ticket. So let us know.

Dan Shappir [00:53:56]:
So how many talks are you planning to have?

Josh Goldberg [00:53:59]:
Let me get that scheduled up, right now. Currently, our plan is, 9 full length talks and 5 lightning talks.

Dan Shappir [00:54:09]:
Oh, cool. That's really nice. Any any ones that you especially want to draw attention to?

Josh Goldberg [00:54:17]:
You know, I I fear, fear responding to that too assertively as I don't wanna upset any speakers. But, I'll say our launch speakers as an arbitrary delineation are, Dan Vanderkam, who I referenced earlier. He's talking about ASTs and source codes and text, like how source files actually work. Rizelle Scarlett over at TBD talking about documentation as part of your tooling and processes, and, Tishan Sunakova at Dragomir over at Bloomberg talking about TypeScript at scale and the things they do to manage a gigantic amount of TypeScript code. Also, fun fact, they contributed, some great features up to TypeScript.

Dan Shappir [00:54:56]:
Yeah. They're doing some really interesting stuff over at Bloomberg. That's for sure. So that that is really cool. Also, Boston is obviously a a beautiful city. Yeah. And, October, that means, like, fall. So it's like, the trees will be all red and stuff.

Josh Goldberg [00:55:18]:
I hope so. To be honest, I had originally really wanted a Halloween conference as that is my favorite holiday by far. I was told rather bluntly that parents do not watch a conference instead of trick or treating. It's not something that they can support. So, yeah, I think we'll have a good fall thing going on. It you're right. It's a beautiful city, beautiful area. And one of the things we intentionally did was have it on a Thursday with, workshops the next morning so that speakers can go with us on a duck tour after, and then we're gonna try to get some kind of partnership with the aquarium to to help people explore that.

Dan Shappir [00:55:48]:
So you're also still looking for sponsors and stuff like that?

Josh Goldberg [00:55:53]:
If someone wants to sponsor us, they they certainly can reach out. It's on the website. But we've got a good set of sponsors so far. I can't announce them all, but I we're we're pretty happy with it. Yeah. No. If you wanna send us money, we're happy to work with you.

Dan Shappir [00:56:08]:
That's really cool. It's it's really nice to see a new conference appearing. It's ever it seems like ever since COVID, you know, conferencing has been in a bit of a rut. Like, we all hope that it would make a total comeback after COVID, but it seems to be fairly challenging. And, I'm even seeing certain conferences like suspend operation. And so seeing a new one come along, especially about such an important and exciting and interesting topic seems, like a a great thing. And, hopefully, I can get my own employer to sponsor, let's say, next year or something because we are also into developer stuff. You know, some of our stuff isn't ready yet, so we're not ready to showcase it yet.

Dan Shappir [00:57:02]:
Hopefully, next year, we will be. So we will see. We will see. I'd love to talk at the conference like that. Anything else before I put us into pics?

Josh Goldberg [00:57:18]:
No. I appreciate actually, yeah, one thing. I appreciate you giving me the opportunity to plug squiggle comp. The reason why we chose to have it this year, you know, post COVID, neither neither of us 2 organizers actually live in Boston. I'm moving end of August this year. Is we agree. I it there's a lot of benefit from conferences. You don't have to go to a conference, you know, to be a whatever great dev in Fortiva, etcetera.

Josh Goldberg [00:57:40]:
But there's a lot of benefit from the hallway track, from just chatting with people,

Dan Shappir [00:57:43]:
from Oh, yeah. For sure.

Josh Goldberg [00:57:45]:
Giving talks. So, we're really excited to be able to provide that, you know, to people both generally in Boston and generally in web dev tooling, which doesn't have a lot of dedicated conferences for it specifically.

Dan Shappir [00:57:57]:
Yeah. It seems like it should. I mean, like, developers are so into tooling. It it feels like we are like, we definitely should have a conference about tooling, so it's it's great that finally we do.

Josh Goldberg [00:58:14]:
Yay.

Dan Shappir [00:58:15]:
By by the way, so this is, I think is it your first time as a conference organizer?

Josh Goldberg [00:58:21]:
Yeah. I've I've helped out with, conferences before, like websites or helping with promotions, but nothing quite so in the weeds as as being an actual organizer. And I gotta say, it's a lot of work. They were right. All the people who told us it was a lot of work.

Dan Shappir [00:58:35]:
Yeah. For sure. Happily, I've I've yet to to to to do it. I've I've spoken at conferences as have you, but, organizing I don't know. I'd I'd rather let somebody else do it. Okay then. Before we go into PIX, if people want to, you know, connect with you, be it about TSCS Lint, about Linting in general, about open source, about squiggleconf, what's the best way to reach out to you?

Josh Goldberg [00:59:16]:
Love the question. For me, Joshua k Goldberg on virtually every platform. Dotcom, GitHub, Twitch, YouTube, Twitter, Blue Sky, Mastodon, Joshua k Goldberg. For my projects, each of them have their own website. So TypeScript, ESlint, ESlint, Mocha, ESlint. I'm butt on the committer team, so please don't come at me yelling about flat config or whatever pain you're going through. That's the team at hold. But for all of the projects, we're always happy to hear your feedback and work with you.

Dan Shappir [00:59:47]:
Cool. Okay then. I'll pull us now into PIX. To be honest, I've I don't have so much in the context of picks. I actually you know what? I actually have 2 things. So, my first pick is I might have mentioned this before. I recently started tweeting out, my favorite standalone fantasy novels. So, one thing about, fantasy books is that fantasy authors really love to write series of books, usually trilogies, but not necessarily.

Dan Shappir [01:00:28]:
And I sometimes want to just go for a single stand alone book, something that, you know, you can read on its own, finish it, and then kind of move on with your life. And that's especially the the egg the special benefit is that you don't have to worry about when the next book is ever going to come out, You know, cough cough, you know, George RR Martin and, you know, Game of Thrones and Tales of Ice and Fire, which see to be to be honest, if he ever does come out with with the next book, which is I'm highly doubtful of, I probably won't read it now. It's it's it's the time the time has come and gone. Anyway, so I I tweeted out, the, the list. I actually have a couple of more books that I have to tweet out in this context. So, you know, let me see if I can remember some of the examples that I gave. One of them would be Neil Gaiman's, Neverwhere. Have you read it?

Josh Goldberg [01:01:42]:
No. But I know the author name, so it's up

Dan Shappir [01:01:45]:
to you. And, another one is, Zelazny's lord of light. Roger Zelazny was a very famous science fiction and fantasy author, very prolific, now deceased. So he wrote some very famous series of books, but I have a very special spot for the lord of light book, which is a standalone book. And and, you know, I'll basically I'll I'll I'll post the link to that, Twitter thread that I keep adding to, in the show notes. So that would be my, first pick. And by the way, if people have, their own favorite books that they want to suggest, you know, feel free to send them to me. I love a good I love suggestions of good books.

Dan Shappir [01:02:40]:
Another one, by the way, you know what? I'll I'll I'll I'll give you, another one or 2. There's, Weave World by, Clive Barker. Have you heard of Clive Barker?

Josh Goldberg [01:02:53]:
That is vaguely familiar name, but no.

Dan Shappir [01:02:57]:
Yeah. He actually is more famous for writing horror related stuff, like, the the pinhead character, if you is from one of his books. And so he wrote this crazy book called Weave World, which is a crazy combination of it's like part fantasy, part horror. It's very weird, and it's very wonderful in my opinion. So that's another great standalone book. And, and another one would be Kigana by Guy Granville Kaye. He's the guy that worked with Christopher Tolkien on, releasing The Silmarillion. They basically went through, Tolkien's, notes and and writings and and basically managed to make a book out of it.

Dan Shappir [01:03:57]:
So he wrote some books on his own, and, his standalone book is called Tigana, and it's also a great book. I think I actually picked that one in our in the last episode that I participated on, so I'm mentioning it again. The second my second pick is I've been kind of down. This is this is not a good time for me. I mean, on a personal level, things are fine. I've got a new job that I'm happy with. Everybody in my family is healthy and whatnot. But my my mother-in-law passed away.

Dan Shappir [01:04:33]:
And in Israel in general, it's a it's a bad time. And, yeah. So I've been kind of down, and I'm, you know, looking for things that can pick me up. And my wife and I happened on the, Despicable Me slash Minion movies, and we kind of, rewatched several of them. And they're so great. They're so lighthearted, funny, pleasant to watch. The the minion characters are of obviously wonderful, but not just. The group character is great as well.

Dan Shappir [01:05:09]:
So so, yeah, if you're looking for a pick me up, I would definitely recommend these movies. And, those would be my picks for today. Do you have any picks for us, Josh?

Josh Goldberg [01:05:20]:
I do. Plus one to having some nice lighthearted high quality lightheartedness in today's world. I I've been wanting to become more of a reader. I used to, when I was a teenager, read constantly. I, you know, exhumed everything from the depths of the sci fi fantasy section of my local library, and I haven't done that as much recently. So I'm still kinda catching up. So recently, I've led kind of the classics that a lot of people may know. Neuromancer is a is a great sci fi book.

Dan Shappir [01:05:49]:
I think it

Josh Goldberg [01:05:50]:
was rather influential in the genre. I'm not cutting new ground here. I recently read through the Foundation series also, which was very good, really, really changed over the course of the series. Yeah, I've yeah. A lot of respect for that. It's hard to

Dan Shappir [01:06:04]:
It's people should be aware that the book series is very different from the TV show. Both are actually pretty are good, but they're very different both in in terms of tone and the actual story.

Josh Goldberg [01:06:16]:
Yeah. Similar on that note, Witcher, love the game. You know, Witcher 3 was the one I played. I've been meaning to play the others, and then I'm in a book club with some friends reading, the the series. Not a huge fan of the show, to be honest.

Dan Shappir [01:06:32]:
Yeah. To be to be honest as well, I I wanted to say it. I tried to watch the show, and I couldn't get into it.

Josh Goldberg [01:06:38]:
Yeah. There are a lot of great parts of it, especially Henry Cavill. Oh my gosh. But oh, that one bathroom scene. But the the his his acting is phenomenal and just I couldn't get into the rest of the show. You know?

Dan Shappir [01:06:50]:
Yeah. Yeah. It is what it is.

Josh Goldberg [01:06:53]:
It is what it is. No. Otherwise, my wife and I, we've been watching Monk, the old TV show. It's kind of our

Dan Shappir [01:07:01]:
Yeah. It's on Netflix, I believe.

Josh Goldberg [01:07:03]:
Yeah. Yeah.

Dan Shappir [01:07:05]:
We're,

Josh Goldberg [01:07:05]:
midway through it. It's quite good. Highly recommend. It's it's very nice. It's gonna be, I think, the epitome of that genre, that era of, you know, early 2000, episodic shows where people have worked. They had an appetite for actual good shows, but it wasn't, you know, this really deep intense stuff you get these days with these HBO miniseries. So

Dan Shappir [01:07:23]:
Yeah. You could watch just a single episode, then it's totally self contained. It's not quite believable. Like, you know, it's it's funny to compare to a lot of the British TV shows of the same time or the same era, where in in the American shows, you had, like, that every episode was self contained. So if you're like, it was a crime drama, the crime happened at the beginning, they solved it. There was a trial. The the the criminal got convicted. Done.

Dan Shappir [01:07:56]:
It's like, you know, Law and Order, I think was the epitome of that type of shows also in c also CSI. Whereas the British shows, they kind of, you know, the entire season was the the the one crime. And then, the mini dramas that you get on streaming today kind of emulate those those British shows where it's the entire season for that

Josh Goldberg [01:08:22]:
the one crime. Yeah. Different. That actually, by the way, reminds me, I fell in love with the show Good Omens, the British one. I I had never heard of it until it randomly popped up in my Reddit or something, but it's fantastic. Highly recommend. It's this whimsical I don't know, you know, biblical characters in the modern day. It's it has, Michael Sheen and David Tennant.

Josh Goldberg [01:08:53]:
Jon Hamm shows up in a later season. Really, really good stuff. Highly recommend.

Dan Shappir [01:08:58]:
Finally, I I read the book, but have not seen not watched the the TV show. The book, by the way, is by Neil Gaiman and Terry Pratchett.

Josh Goldberg [01:09:09]:
Yeah. It's hilarious. It's it's all sorts of clever, I'd say. It's I don't know how to describe these. It's like very British humor. Like, you know, it's it's these characters who driven by these odd quirks, just getting these ridiculous situations. But it's also this really compelling story about, you know, good versus evil and the nuances and the the inability to define those two concepts in in a dynamic people driven world. I don't know how to reconcile it.

Dan Shappir [01:09:35]:
If if that's your jam, then I would highly recommend that you read, not watch, read the Hitchhiker's Guide to the Galaxy series of books. The movie is pretty bad. The books, on the other hand, are awesome.

Josh Goldberg [01:09:52]:
Okay.

Dan Shappir [01:09:53]:
So so, yeah, if if if that kind of sense of humor Carrie Pratchett was very much inspired by Douglas Adams. Let's put it this way.

Josh Goldberg [01:10:01]:
Adam Delosse.

Dan Shappir [01:10:03]:
Yeah. So with that, I think I'll end our show. Thank you again for coming again onto our show and speaking both about TSCS Lint and about squiggleconf and, putting yourself out there, and all the best with both endeavors and with the move to Boston.

Josh Goldberg [01:10:20]:
Thanks, Dan. Yeah. I I really appreciate, you having me on here, letting me plug things. And, also, you know, best of luck with the new job and getting them to sponsor screw comp 2025.

Dan Shappir [01:10:30]:
Yeah. Let's hope. Let's hope. So okay. Bye, everybody. Thank you for listening in. Bye bye.