Speaker 1: Hello everybody, and welcome to another episode of JavaScript Jabber.
Speaker 1: Today I'm flying solo both as host and panelist. Maybe
Speaker 1: some of our other hosts will join us later on
Speaker 1: we will see. Our guest today is Josh Goldberg. Hi, Josh, Hi,
Speaker 1: thanks for having me. You do know that when you wave,
Speaker 1: people who listening to our podcast don't actually hear anything.
Speaker 2: I was hoping the good vibes. Would you know m
Speaker 2: Nix from the podcast. That's a good one.
Speaker 1: Yeah. It reminds me that when my kids were really
Speaker 1: young and we would drive and they would be sitting
Speaker 1: in the back and I would ask them something while
Speaker 1: I'm driving and they would nod their heads.
Speaker 2: Yeah.
Speaker 1: So yeah. Anyway, so welcome back to a show. It's
Speaker 1: been a while, had you here before. We're actually going
Speaker 1: to be talking about similar topics to what we've spoken
Speaker 1: about in the past, but a lot of I guess
Speaker 1: has happened since then, so hopefully we can catch up.
Speaker 1: The topics are going to be tess Lint, which is
Speaker 1: a project you've been working on for a while now,
Speaker 1: and also your new conference what's it called squiggle.
Speaker 2: Coff squiggle comf Yes, named after the things that give
Speaker 2: you squigglies in your editor.
Speaker 1: Cool. Cool, cool. So what do we want to start with?
Speaker 2: Well, I'm a sucker for going in order ts s lint.
Speaker 1: Yeah okay, but you know what before then, since it
Speaker 1: has been a while, can you also, you know, provide
Speaker 1: a quick introduction about who you are, what you do,
Speaker 1: why it's exciting to have you.
Speaker 2: On with pleasure. Hi everyone, I'm Josh. I'm a full
Speaker 2: time independent open source maintainer. That means that instead of
Speaker 2: working for one specific company, I'm independent. I work on
Speaker 2: my own and I work on open source projects that
Speaker 2: benefit the ecosystem for me. Specifically, the main ones I
Speaker 2: work on are typescriptyestlint, which is the tool that lets
Speaker 2: your run standard JavaScript tools like Eslin's are prettier on
Speaker 2: types shop Code, as well as eslint itself, on the
Speaker 2: committed team, and Moca. So I'm just kind of generally
Speaker 2: happy to float around GitHub and try to make things
Speaker 2: better for everyone.
Speaker 1: It is not recall we've spoken about in the past,
Speaker 1: but I think it is worth bringing it up again.
Speaker 1: Is it really possible to make a living off of
Speaker 1: open source? You know, especially given that it's free?
Speaker 2: Yeah? Free as in it's a hard question. It is
Speaker 2: theoretically possible. Some projects are better suited for it than others.
Speaker 2: The ones I tend to work on tend to be
Speaker 2: not very well suited. But I do. I do make
Speaker 2: what is defined as a livable wage in my area,
Speaker 2: which is better than the even last year, which was
Speaker 2: minimum wage. But it's not anywhere near it was as
Speaker 2: it was in a full time salary position for me,
Speaker 2: So there's a good chance that'll eventually go back once
Speaker 2: I've made the impact I wanted to an open source.
Speaker 1: So you're what living off some of your savings? Is
Speaker 1: that what you're saying.
Speaker 2: I don't think I'm that negative right now, in large
Speaker 2: part because my fantastic wife, my spouse has a real
Speaker 2: job and health insurance, which is very important in the
Speaker 2: United States, as some may know.
Speaker 1: But I do.
Speaker 2: I do get income. I have community sponsorships on a
Speaker 2: lot of the projects that I'm on that I get
Speaker 2: a share for many of them. I've got book revenue
Speaker 2: from my learning types of good book go buy it today,
Speaker 2: And generally there are some people who sponsor me individually
Speaker 2: on get up sponsors, So I'm not hemorrhaging money. I'm
Speaker 2: just not making a.
Speaker 1: Lot of money, and if people who are listening to
Speaker 1: us do want to contribute to your efforts, what's the
Speaker 1: best way to go about it.
Speaker 2: Well, first of all, they should feel very good about
Speaker 2: themselves because that's very kind and noble of them. Thank you.
Speaker 2: If they want to support me specifically and the stuff
Speaker 2: that I'm specifically doing kithub dot com, slash sponsors, Slash
Speaker 2: Joshua K. Goldberg, or if you just google me or
Speaker 2: look me up my names on my site for any
Speaker 2: of the projects I work on, if that's particularly exciting
Speaker 2: to you, especially t sees link. They all have open
Speaker 2: collectives that you can sponsor, so there's definitely a way
Speaker 2: for you to give me money if you want to.
Speaker 1: And you mentioned your book on typescript. When did that
Speaker 1: come out.
Speaker 2: It's been a couple of years now, I belie twenty
Speaker 2: twenty two, mid late summer. It's through a Riley learning
Speaker 2: Typeescript and it has this beautiful yellow and colored bird
Speaker 2: on the cover.
Speaker 1: And given the name learning Typeescript, I gather that it's
Speaker 1: primarily for people who are not familiar with it and
Speaker 1: want to get into it, like newbies, effectively exactly.
Speaker 2: Yeah, the general flow of the book is that if
Speaker 2: you can start with roughly intermediate JOBASCRIPT knowledge, you should
Speaker 2: know how variables and closures and stuff like that work.
Speaker 2: You don't need to be super fancy advanced javascripts expert.
Speaker 2: You don't need to know you know, I don't know
Speaker 2: symbols and stuff like that. But you don't need any
Speaker 2: prior knowledge or experience with types through whatever, C Sharp,
Speaker 2: C plus plus Java Rust. None of that is necessary
Speaker 2: if you already know what great TYPESKIPT works a little differently,
Speaker 2: so you'd still learn stuff, but you can come in
Speaker 2: with just JavaScript and emerge a relatively competent typescript developer.
Speaker 1: You know. That brings up an interesting point. So a
Speaker 1: few weeks back, we recorded in an episode with the
Speaker 1: people talking about the lead code lead code tests that
Speaker 1: so many companies are using these days when filtering out applicants,
Speaker 1: and I wasn't actually able to participate on it, so
Speaker 1: I'm just listening to the recording like everybody else, And
Speaker 1: they brought up one of the things that they discussed
Speaker 1: was about which programming languages are supported by that platform.
Speaker 1: Turns out that many are. You can practically choose any
Speaker 1: which you want, and both JavaScript and typescript are supported
Speaker 1: as languages apparently that you can use for you know,
Speaker 1: solving the lead code challenge, and I, you know, I
Speaker 1: was thinking about it, and if I were to do
Speaker 1: it today, I would, you know, there's a good chance
Speaker 1: that I would choose to use JavaScript. But I'm like
Speaker 1: wondering why anybody would use typeescript as opposed to JavaScript
Speaker 1: when solving elite code challenge. What do you think about that?
Speaker 2: That's a good question. I don't know what i'd use, honestly,
Speaker 2: I haven't done lee code in a while. I think
Speaker 2: it's a fun little hobby that one can do, like
Speaker 2: a niche little area programming, and I detest how associated
Speaker 2: it's become with job interviews. That's just not a core
Speaker 2: competency that we use day to day as much as
Speaker 2: you know, debugging or pairing. But I digress. I don't know.
Speaker 2: It's the rule that I normally go through is the
Speaker 2: rule of three. If I'm using more than three files
Speaker 2: or working with three or more people in a project,
Speaker 2: I'll switch from JavaScript to type scripts. Leak code doesn't
Speaker 2: really satisfy that rule. So the overhead of typescripts needing
Speaker 2: to or trying to get you to define types for things,
Speaker 2: or being aggressive when you haven't defined it enough. Types
Speaker 2: oftentimes isn't worth it. It can be useful though, if
Speaker 2: you do, and if you have experience, and if you
Speaker 2: feel comfortable writing out types or just using any in
Speaker 2: a lot of places. So yeah, I can see the
Speaker 2: motivation for it. I wouldn't go for it myself.
Speaker 1: Yeah, me too. I'm thinking that probably the sweet spot
Speaker 1: for dynamic languages is rapid prototyping. And with lead code,
Speaker 1: you are that's essentially what you're doing. You're trying to
Speaker 1: hammer out a working solution as quickly as possible. You know,
Speaker 1: usually you're constrained in time. Writing anything that at the
Speaker 1: end of the day doesn't actually get translated into executable
Speaker 1: code seems like a waste of time in that context.
Speaker 1: So yeah, but you know, in any event, it's nice
Speaker 1: of them to support it. Is an option, you know. Interesting.
Speaker 1: I once, by the way, commented that my ideal development
Speaker 1: environment would be me writing JavaScript and everybody else writing typescript.
Speaker 1: That way, I don't have to mess around with types,
Speaker 1: but everything that I do is supported by types, and
Speaker 1: I get all the completion. And the only problem with
Speaker 1: that is that everybody else, includes me from about a
Speaker 1: week ago. So you know, I might be smiling now,
Speaker 1: but I'll be sad in a week if I write
Speaker 1: my stuff in JavaScript.
Speaker 2: I think the really baller move for interviews is to
Speaker 2: to use the types type system instead of the run.
Speaker 2: That's really where we shine.
Speaker 1: Yeah, using uh the type system itself as ah as
Speaker 1: a programming language. Uh yeah, I know some people who
Speaker 1: do that, who dabble in that sort of thing. I
Speaker 1: used to do that sort of crazy stuff when I
Speaker 1: back in the day with C plus plus because as sexually,
Speaker 1: any language which which supports a sufficiently sophisticated generics can
Speaker 1: be used as its own, you know, quote unquote type
Speaker 1: programming language. Because you get conditional you effectively can implement
Speaker 1: conditionals and loops uh via recursion. So so yeah, it's
Speaker 1: it's an interesting, interesting approach, but mm hmm yeah, mostly
Speaker 1: mostly a game and not something you want to do
Speaker 1: anywhere near production code. Yeah. By the way, one more
Speaker 1: interesting point about this whole thing about typescript and when
Speaker 1: it's appropriate. I have to confess that when Typescript initially
Speaker 1: came out, my initial attitude was kind of negative because
Speaker 1: all the original demos were around classes and enams, and
Speaker 1: stuff like that. And it might not be surprising given
Speaker 1: that it was created by the same Microsoft people that
Speaker 1: gave us c sharp, and you know, back at the
Speaker 1: time they kind of, I guess, didn't really know any better.
Speaker 1: But my feeling initially with looking at the original sample
Speaker 1: typescript code that they were you know, showcasing, was that
Speaker 1: this is kind of a poor man's Java. And since
Speaker 1: I much preferred JavaScript to Java, that feeling that Typescript
Speaker 1: was kind of pulling me back into the Java realm
Speaker 1: was something that you know, really rubbed me the wrong way. Uh,
Speaker 1: And I kind of like totally flipped on that. I
Speaker 1: did like a one eighty on that when I realized
Speaker 1: that you can do you know, function JavaScript functional style
Speaker 1: programming and get all the benefits of types with typescript.
Speaker 1: And now the typescript has come such a long way
Speaker 1: and you got so much inference going on and the
Speaker 1: cool things with generics and stuff like that, you can
Speaker 1: achieve very cool type safety and without having to use
Speaker 1: classes and interfaces at all in your code. So yeah,
Speaker 1: so that's my confession about typescript. Does it kind of
Speaker 1: match your own feelings about the topic?
Speaker 2: It does? Yeah, I think you really hit the nail
Speaker 2: on the head on the two big advancements in marketing
Speaker 2: the typescripts had. One is that at the beginning they
Speaker 2: were really appealing to people on the in large part
Speaker 2: on the premise of you can use these features you've
Speaker 2: been missing, which included both classes and the type system.
Speaker 2: Nowadays the marketing doesn't really mention classes, both because that's
Speaker 2: a core part of the language now over a decade later,
Speaker 2: and because we accidentally ended up with the misconception in
Speaker 2: the community that typescript is more for class oriented rather
Speaker 2: than say, functional approaches, which is now that you've hit
Speaker 2: the nail on the second point that typecript actually supports
Speaker 2: functional programming and really really non class but still type
Speaker 2: safe approach as well, that I would even say that
Speaker 2: that's a better way of using Typescript in many cases.
Speaker 2: So I think it's just really cool to see how
Speaker 2: marketing evolves over time as people learn better how to
Speaker 2: use and how to market a tool like typescript, for example.
Speaker 1: But is it just marketing or is it also how
Speaker 1: typescript itself has technically evolved.
Speaker 2: It's a good question. I would love to hear you
Speaker 2: interview every two to four years at the very rarest
Speaker 2: or at least common core folks from the Typescript team.
Speaker 2: To see how their answers to this evolve over time,
Speaker 2: I'm sure would be fascinating. I think that if you
Speaker 2: look back at how typescripts discussions, which are many which
Speaker 2: are public, like their meeting notes and their issue responses
Speaker 2: have been on GitHub, it's been pretty consistent that they
Speaker 2: don't try to specifically go for say, classes and OOP,
Speaker 2: It's just that that was one of the big things
Speaker 2: they had to implement early on for standardization, for marketing
Speaker 2: for by I don't say marketing and drug protum might
Speaker 2: just mean these are the things that people needed from typescript,
Speaker 2: but they've they've in virtually every discussion tried to pull
Speaker 2: the focus back from specific things like you know, supporting
Speaker 2: I don't know, injectable classes or supporting functional style insert
Speaker 2: paradigm here, and try to think, what are the common
Speaker 2: community needs for type safety. What are the ways of
Speaker 2: bending or describing or manipulating types that folks are commonly
Speaker 2: using across many different teams, organizations, paradigms, and how can
Speaker 2: we build that in an dignostic way in the type
Speaker 2: system such that anyone benefits, not just specifically say classes.
Speaker 1: I'm totally with you on that. I think that first
Speaker 1: of all, I have to say that in a lot
Speaker 1: of ways, the Typescript people like have a super hard job.
Speaker 1: I compare it to herding cats. Basically, you take the
Speaker 1: poster child for dynamic languages, a language that is dynamic
Speaker 1: but also has dynamic objects, like everything in job script
Speaker 1: is dynamic. Is it's dynamic as you can get, and
Speaker 1: then try to enforce the static type system on top
Speaker 1: of that. And my feeling is that, especially in recent years,
Speaker 1: and to be fair and honest, I'm not sufficiently knowledgeable
Speaker 1: about the history and evolution of typescript to tell you
Speaker 1: know which features came first and which features came in later,
Speaker 1: and you know what happened sooner or later. I'm more
Speaker 1: knowledgeable of JavaScript and Typescript in this regard. But what
Speaker 1: I see now is that in the past I had
Speaker 1: this kind of feeling that typescript is trying to force
Speaker 1: me to do things certain ways that sometimes I wanted
Speaker 1: to do. I had certain paradigms that I implemented in
Speaker 1: JavaScript in ways that I really liked, and I couldn't
Speaker 1: get them to work properly with typescript, and now I
Speaker 1: can now. It's difficult for me to say whether it's
Speaker 1: because typescript has evolved and improved or because my knowledge
Speaker 1: of typescript has evolved in proved might be probably it's both,
Speaker 1: But the feeling is that you can now be much
Speaker 1: more expressive in what you can achieve with typescript, and
Speaker 1: you don't necessarily have to forego, you know, mainstream JavaScript
Speaker 1: paradigms just to get the benefits of typescript.
Speaker 2: Yeah, I agreed. I think included in that second point
Speaker 2: of you're more happy with typescript or more typescript d yourself,
Speaker 2: part of that includes understanding intuitively what are the types
Speaker 2: of flows or types that typescript is easily able to represent.
Speaker 2: There are a lot of complex things you can represent
Speaker 2: with typescript with a lot of glue and comfoolery, but
Speaker 2: the stuff that's really clean and beautiful and sistinct people
Speaker 2: tend to gravitate towards the more they write typescripts, which
Speaker 2: I think is a really good thing because typescript types
Speaker 2: are how we generally represent JavaScript concepts and the way
Speaker 2: our data flows and code. So if something is difficult
Speaker 2: to represent in typescript. There's a very good chance that
Speaker 2: it's based on something that's not easy to explain to
Speaker 2: others or easy to represent in code. I think there's
Speaker 2: this kind of beautiful synergy there.
Speaker 1: By the way, Jay Larky comments that quote, I think
Speaker 1: JS got better, so they had to do less stuff
Speaker 1: on top of JS nowadays. I agree, but doesn't necessarily
Speaker 1: mean that the typescript people have less work, because you
Speaker 1: need to support in the type system all this new
Speaker 1: JS stuff as well, especially since a lot of the
Speaker 1: typescript sophistication comes from the ever growing ability to statically
Speaker 1: analyze the code and figure out stuff like type narrowing
Speaker 1: based on logic that you actually see in the code.
Speaker 1: So if you're doing like an if in the code
Speaker 1: and bail out a short circuit some condition, then it
Speaker 1: probably also narrows the types moving forward, because you've kind
Speaker 1: of ejected out that those aspects of the types that
Speaker 1: are no longer relevant. But by the way, speaking of
Speaker 1: all that and taking us finally to take it to
Speaker 1: ts s flint, it, you know, brings up an interesting point.
Speaker 1: You know, given all this sophistication and power in typescript itself,
Speaker 1: why do we actually need a linter for typescript? Isn't
Speaker 1: typescript itself enough? In that regard?
Speaker 2: I love it. There's so many good reasons why one
Speaker 2: would want a linter, and a few bad reasons, just
Speaker 2: for my emotional sake, If you don't mind, I'd like
Speaker 2: to start with the bad. A lot of folks to
Speaker 2: go for it, Yes, a lot of folks used to
Speaker 2: use eslint for a few things that, among others that
Speaker 2: we no longer recommend in the linting world. Formatting or
Speaker 2: silly stylistic rules would be the big one. Es slint
Speaker 2: is a linter, which means you it allows you to
Speaker 2: provide a bunch of individual rules, which are little pieces
Speaker 2: of code that yell at you if your code is
Speaker 2: not working the way it should or it doesn't look
Speaker 2: the way it should. And then that's separate from a
Speaker 2: formatter which reformats your code or a type checker which
Speaker 2: looks at all the types.
Speaker 1: In your code.
Speaker 2: Formatter winter type checker. A linter is structurally not very
Speaker 2: good at formatting. So if you're using es and for formatting,
Speaker 2: there are a lot of gaps, like there are a
Speaker 2: lot of little edge cases that aren't really covered by
Speaker 2: any one rule, or it's hard to write that type
Speaker 2: of logic in a linch role. It's much easier to
Speaker 2: do a big formatter sweep, like with prettier. So there are.
Speaker 1: Formatting is about just to make it clear to our
Speaker 1: audience about stuff like indentation, line lengths, line breaks, stuff
Speaker 1: like that.
Speaker 2: Yeah, yeah, semichel and you know white space type Yeah,
Speaker 2: so uh there are. There is a project, really good
Speaker 2: one called the Lent Stylistic for in four in formatting
Speaker 2: with d slint, but it's not part of Core anymore,
Speaker 2: and a lot of people associated, oh it's yelling about
Speaker 2: me doing at me about semi Collin's with linter. Then then
Speaker 2: just stop using linters altogether. It's not the right conclusion,
Speaker 2: but there are a lot of really good things you
Speaker 2: can do with them. Generally speaking, winters can apply logic
Speaker 2: in cases where it might be type safe. For example,
Speaker 2: you might be creating a promise which is type safe,
Speaker 2: but then you do something dangerous with it that's still
Speaker 2: type safe, such as not handling the rejection case of
Speaker 2: that promise, like if you forget to await it and
Speaker 2: then you console log it. That's all type safe, but
Speaker 2: that's probably not what you wanted to do, which means
Speaker 2: you still want a tool separate from your type checker
Speaker 2: to'll let you know about these probable mishaps.
Speaker 1: So can you give a couple of examples of some
Speaker 1: of the rules that DSCS lint enforces. I know we
Speaker 1: discussed those in the previous time that we had you
Speaker 1: on the show, but I think it's still worth reviewing.
Speaker 1: Also if you've got some new one since then, you know.
Speaker 2: Oh yeah. The classic example that we always jump to
Speaker 2: is promises like the you know you forgot to await
Speaker 2: type stuff, because that's that's a huge source of bugs,
Speaker 2: and we get a lot of reports from from people
Speaker 2: that that's the key thing they need from us, you know,
Speaker 2: having a having a function that returns a promise, particularly
Speaker 2: that in your code, and then passing it to something
Speaker 2: that doesn't know the function that's calling that you're passing
Speaker 2: returns a promise. So then the async logic just floats
Speaker 2: off in the distance somewhere that that type of weird
Speaker 2: edge case that is still type safe but not right.
Speaker 2: Another one would be for in array is the rule
Speaker 2: or no foreign array, where there are two common ways
Speaker 2: of looping over an object in jobs this four in
Speaker 2: and four of four in loops over the keys for
Speaker 2: of loops over the values of inodurable. So if you
Speaker 2: use four in on an array, you'll get the stringified
Speaker 2: array keys, which is technically type safe. That's technically something
Speaker 2: some people might want to do, but in practice, why
Speaker 2: the heck would you ever want to do that. That's
Speaker 2: that's a link rule yelling at you. Area of concern.
Speaker 1: Yeah, four in is one of those things that in
Speaker 1: the language it's legal, probably doesn't It doesn't do what
Speaker 1: you probably expect, and therefore you should probably not use it.
Speaker 1: Or put another way, if you're Kive Simpson, then you
Speaker 1: probably have a very good reason to use it, but
Speaker 1: otherwise you probably don't. Then don't and don't.
Speaker 2: Yeah, there's I think you touch on such an interesting
Speaker 2: point that there are a lot of people who are
Speaker 2: very very deeply experienced, knowledgeable, influential javascrip developers who do
Speaker 2: not see the value of linting, or at least do
Speaker 2: not themselves experience it because they instinctively, you know, they
Speaker 2: always handle their promises, they know what they're doing. They
Speaker 2: don't write four in on an array, they write for
Speaker 2: of but a lot of the value the winters for
Speaker 2: people who don't have, you know, twenty years of writing
Speaker 2: javascripts and then typescript people who are still new and learning.
Speaker 1: To be fair, there's a certain point in it, I'd
Speaker 1: say not seeing the value in linting is a bit harsh.
Speaker 1: I would say rather that they would disable certain rules
Speaker 1: that you probably want to keep enabled for most people.
Speaker 1: And but the reality is that usually like you don't
Speaker 1: work alone, and you want to conform to the race
Speaker 1: the rest of the codebase. So the example that I
Speaker 1: like to give, and I don't know if there's a
Speaker 1: linting or formatting rule for that, is that whole debate
Speaker 1: about whether when you're creating functions named functions, whether you
Speaker 1: should use the function keyword, or whether you should do
Speaker 1: something like const name equals in err. I see a
Speaker 1: lot of people using uh. Now. Now, obviously they're not identical.
Speaker 1: There are certain differences, and we can you know, touch
Speaker 1: on those, you know, but but to a great extent,
Speaker 1: it's an just an issue of personal preference. My personal
Speaker 1: preference is the function keyword, and I can explain why
Speaker 1: that is. But at the end of the day, is
Speaker 1: what I do is I conform with the project code base,
Speaker 1: Like if the project use it, does it prefers errow
Speaker 1: named errow functions. I will use named errow functions because
Speaker 1: if you start, you know, deviating in your own code,
Speaker 1: you're creating an unwanted and unnecessary cognitive overhead because people
Speaker 1: will look at that piece of code later and say, hey,
Speaker 1: this code looks different than the rest. Why is that?
Speaker 1: Is it doing something different? You know, and they have
Speaker 1: to start thinking about it, you know, start they don't
Speaker 1: trust their instincts around it anymore, and that's a bad thing.
Speaker 1: So consistency above everything else, and that that's another big
Speaker 1: benefit of linting, both stylistic linting and semantic linting. I
Speaker 1: agree that it generates consistency.
Speaker 2: Yeah, that's something a formatter can't do because, as you said,
Speaker 2: sometimes there is a subtle logical difference between different keywords
Speaker 2: or different types, and that's something a type checker won't
Speaker 2: do because well it's all type safe. That's exactly what
Speaker 2: one of the big use cases for winter is keeping on.
Speaker 1: So you said that some of the main benefit of
Speaker 1: linting is to highlight things that are correct, like using
Speaker 1: four in or not doing not putting a weight on
Speaker 1: your promises or maybe not putting a catch somewhere. So
Speaker 1: those are all things that are totally valid in terms
Speaker 1: of the code. Are probably something that things that you
Speaker 1: know are not right. That's put it is way you
Speaker 1: probably don't want to do. So it's it's it's a
Speaker 1: warning rather than an error. Would be the way that
Speaker 1: I would phrase it, and then you want and that's
Speaker 1: where the linter kind of steps in. Is that the
Speaker 1: way that you would phrase it as well?
Speaker 2: Yeah, it's a warning that in most cases you generally
Speaker 2: still want to fail the build down. Yes, yeah, for sure,
Speaker 2: there's a one more really good use case that it
Speaker 2: gets forgotten a lot. You can write custom Lynch rules.
Speaker 2: That's one of the big things that ESLNT became successful
Speaker 2: from being able to support early on. If you're on
Speaker 2: a team that, let's say, moving from one way of
Speaker 2: calling an API to another, you can write a Lynch
Speaker 2: role enforcing you know that people use the new way
Speaker 2: not the old way, and you can even write a
Speaker 2: fixer like an auto fixer in your Olynch role. So
Speaker 2: migrant code from the old way to the new way
Speaker 2: as a form of a code mob and having been
Speaker 2: on a web platform team. I can tell you that's
Speaker 2: incredibly helpful and useful.
Speaker 1: That is nice. So what is new in TSC slint.
Speaker 1: I gather that a new version is coming out, came
Speaker 1: out about to come out.
Speaker 2: Came out type ship yes, and V eight thank you
Speaker 2: for bringing it up.
Speaker 1: V eight is a special name.
Speaker 2: I know we've had a few people get confused about
Speaker 2: how it's not the Tomato juice and it's not the
Speaker 2: engine underlying you know, Chromium and JavaScript. But it's our
Speaker 2: newest major version. It has a lot of good things
Speaker 2: in it. Just the high level overview is every major
Speaker 2: version we improve and iterate on the list of recommended
Speaker 2: rule sets are little sharebok in things. This one has
Speaker 2: ESL and V nine support, which was unfortunately kind of
Speaker 2: delayed on our end. And it has this new thing
Speaker 2: called the Product Service, which makes typed rules the most
Speaker 2: powerful rules we offer a lot more we hope, easy, straightforward,
Speaker 2: understandable to configure. So we're really excited about it.
Speaker 1: So what's the thing that you're most excited about in
Speaker 1: the context of the new version?
Speaker 2: The Project Service. A lot of the lint rules that
Speaker 2: we just talked about and that are elsewhere mentioned about
Speaker 2: being awesome and powerful need type information. For example, we
Speaker 2: said no for in array, Well, how do you know
Speaker 2: what is an array? Or you know, properly calling a
Speaker 2: function that's a sync and make some promise, how do
Speaker 2: you know the function is a sync or re turns
Speaker 2: of promise. In general, you have to use a type
Speaker 2: checker for that because what if you import it from
Speaker 2: a file or some other MPM package or something, and
Speaker 2: in order to do that we have to then call
Speaker 2: into the Typescript APIs And there are not that many
Speaker 2: products that do at. So this is still kind of
Speaker 2: a new and exploratory area in the realm of JavaScript
Speaker 2: typescript doing so. The project service is this term for
Speaker 2: this new set of APIs that we're using from Typescript
Speaker 2: at align type checking to behave more like what you're
Speaker 2: using your editor, which means it's a little easier to
Speaker 2: set up. We can infer more stuff and it shouldn't
Speaker 2: have these weird differences where eslint understands something differently than
Speaker 2: what you see in vis code.
Speaker 1: Cool. So it's like effectively leveraging the language server to
Speaker 1: a greater extent.
Speaker 2: Yeah, yeah, a lot more code path sharing under the hood.
Speaker 2: We use what the typescript calls it, the project service,
Speaker 2: which is the set of functions provided by Typescript that
Speaker 2: you can pass a path to a file and we'll
Speaker 2: give you back here's how to describe type information for
Speaker 2: the file. Some APIs like that, which is really exciting
Speaker 2: because previously we were manually creating those things on our end,
Speaker 2: effectively doing what the project service does for us. And
Speaker 2: because we are not Typescripts, neither technically nor organizationally the
Speaker 2: people behind it, we weren't doing as good of a
Speaker 2: job as what the project service is able to do now.
Speaker 1: By the way, one more point that Jay Larky brought
Speaker 1: up in another comment is that some things are framework specific,
Speaker 1: like rules of hooks or solid lind for restructuring props. Yeah,
Speaker 1: that's absolutely true. I mean, you know, these days, most
Speaker 1: typescripts JavaScript developers work in the context of a framework
Speaker 1: and a meta framework, and there are let's call it,
Speaker 1: additional rules that are that are or paradigms that are
Speaker 1: more specific for whatever framework you choose. So things that
Speaker 1: again are totally legal in the context of you know,
Speaker 1: general purpose typescript or JavaScript might be things that you
Speaker 1: want to avoid in the context of framework, and indeed
Speaker 1: the structuring is probably in issues with the structuring in
Speaker 1: solid is probably a good example where you might unintentionally
Speaker 1: lose reactivity because of the structuring that's perfectly legal in
Speaker 1: JavaScript and typescript.
Speaker 2: Yeah, shout out j Larkie a great point.
Speaker 1: Yeah, by the way, it's an interesting In another context,
Speaker 1: we had the people from the Meta team a few
Speaker 1: what's it weeks months back talking about the new React compiler,
Speaker 1: and interestingly that compiler also has a linking aspect to it.
Speaker 1: They have like the rules of React, and they're looking
Speaker 1: at ways to enforce best practices of React using that compiler.
Speaker 1: So it'll be interesting to see how they flag things,
Speaker 1: whether it's the errors of warnings or whatnot. Like you said,
Speaker 1: even if it's warnings, there's a good chance you still
Speaker 1: want to break the build. But interesting. Yeah, it's interesting
Speaker 1: to see blinting making its way into so much stuff.
Speaker 2: Yeah, I'm really excited about it. I think it's a
Speaker 2: really really cool area and it's really useful. And now
Speaker 2: that folks respect it, you know, it's it's getting more
Speaker 2: and more stuff.
Speaker 1: Mm hmm. And I now that that's out, I imagine
Speaker 1: that your work you've started working on the next version, right.
Speaker 2: Yeah, we tend to reserve a few months even in
Speaker 2: a year or two at most, probably just up to
Speaker 2: a few months after each major version of just cleanups.
Speaker 2: You know, we released this big new thing, this project service,
Speaker 2: which is a different way of configuring type flinting. Well,
Speaker 2: now we have all the myriad different ways people were
Speaker 2: previously setting up type plinting coming in and telling us
Speaker 2: way as it does or doesn't work for them. So
Speaker 2: there's a lot of clean up there. Also, I think
Speaker 2: there's a lot of value in a project just spending
Speaker 2: time working on things that don't have a huge determined
Speaker 2: purpose like you know, paper cuts, cleanups, documentation improvements, which
Speaker 2: is I think the phase we're in right now.
Speaker 1: Hmm. Cool. So you're not yet thinking so much about
Speaker 1: V nine at this point in.
Speaker 2: Time, Yeah, not so much. I think long term, there
Speaker 2: is a new snazzy thing we want to start using more,
Speaker 2: which is there's an API that typescript used to not
Speaker 2: expose called the assignability API. Is type assignable too previously
Speaker 2: in type checking. APIs to the stuff that Lynch rules
Speaker 2: can use. You can you can get the type for something,
Speaker 2: you can say, get the type of this function, call
Speaker 2: the returns type and see if it's let's say, a
Speaker 2: promise or something with a dot. Then but you couldn't
Speaker 2: check two things and see if one is assignable to
Speaker 2: the other, like if this number is assignable to that
Speaker 2: string or something else. But now that that API is
Speaker 2: available to us, they marked it as stable and you
Speaker 2: can use it. We think there are a lot of
Speaker 2: really interesting Lynch rules you can do with it. For example,
Speaker 2: you could, instead of just saying no inferable types, don't
Speaker 2: at of type annotation that's triple legal to the same
Speaker 2: as whatever type something is, you could write a linter
Speaker 2: role that bans type annotations that are wider than the thing.
Speaker 2: Like if you say constant value colon string equals quotes,
Speaker 2: we can say, aha, that string is actually losing type information.
Speaker 2: Typescript by default would be able to infer that this
Speaker 2: is some string literal or union of literals rather than
Speaker 2: just the general string. So very exciting stuff.
Speaker 1: I know, Yeah, no, this is this is cool. Look,
Speaker 1: there is a challenge here, and it's it's an issue
Speaker 1: that's been brought up by people like THEO I think
Speaker 1: and others. Also Ryan Carniato about how like that typescript
Speaker 1: really has two target audiences in a way, there's the
Speaker 1: distinction that they may it was between application developers and
Speaker 1: library developers or library makers that application developers usually are
Speaker 1: able to use it at you know, without diving too
Speaker 1: deeply into sophisticated types, and library developers or people that
Speaker 1: create APIs are kind of forced to. I think the
Speaker 1: line is often drawn around generics, but you know, I'm
Speaker 1: it seems to me that generics is becoming more like,
Speaker 1: you know, public domain like it's it's no longer such
Speaker 1: black magic that as it used to be, I think.
Speaker 1: But you know, it's an interesting point and I'd love
Speaker 1: to hear from our audience about that what they think.
Speaker 1: So it used to be that, you know, if you
Speaker 1: were an application developer, you could use typescript without having
Speaker 1: to understand how generics work. But if you were a
Speaker 1: library developer, if you created APIs, you had to understand generics.
Speaker 1: It's interesting to think whether or not a tool like
Speaker 1: E like ts S SLINT can in a sense make it
Speaker 1: easier for people to up their typescript game, like to
Speaker 1: be more like library developers and not and being able
Speaker 1: to do it without getting too much in the weeds.
Speaker 1: Like The alternative, of course, is to use some sort
Speaker 1: of chat GPT like tool to write your typeescript for you.
Speaker 1: But I'm wondering whether something like eslint ts slint can
Speaker 1: also help in that context. What do you think?
Speaker 2: Oh, I have so many thoughts here, yes, strong degree.
Speaker 2: Another big benefit of interrules can be best practices, not
Speaker 2: just the you know, don't use four in on an array,
Speaker 2: but things like preferring you know, stylistic consistency and how
Speaker 2: you write your types. Types versus interfaces is one of
Speaker 2: the big debates in type scripts, where much like the
Speaker 2: functions you mentioned earlier, the answer is it doesn't matter,
Speaker 2: just be consistent. We do have quite a few rules
Speaker 2: though that that flag common bad practices that results from
Speaker 2: people not having that full deep understanding and then let
Speaker 2: you know, hey, this is why it's wrong. Here are
Speaker 2: the option or options to fix it. I think the
Speaker 2: two really exciting big ones that I can dive into
Speaker 2: if you want are empty types and the golden rule
Speaker 2: generics or unnecessary type parameters. Those are two big ones
Speaker 2: that a lot of people trip up on that we
Speaker 2: now have line rules to help people.
Speaker 1: Learn no, please do, please do awesome.
Speaker 2: So the empty object or the just curly boys object
Speaker 2: type in typeescript that describes any object any value other
Speaker 2: than null and undefined. So you can say let value
Speaker 2: colon curly brackets. Just empty object equals quote something. The
Speaker 2: string is a value in JavaScript and typescript. Therefore it's
Speaker 2: assignable to the empty object type. Same with number. The
Speaker 2: literal zero is allowed, which is horrifying and confusing to
Speaker 2: many people. So we have a win role that says, hey,
Speaker 2: don't use the empty object type except in certain situations
Speaker 2: where it's reasonable to. Instead, what you probably want is
Speaker 2: an insert list of common alternatives, such as unknown or non.
Speaker 1: So basically, just to clarify though, in typescript, when you
Speaker 1: use empty object as a type, not as a value,
Speaker 1: but as a type, it means anything which isn't null
Speaker 1: or undefined.
Speaker 2: Yes, I might be missing some nuance there, but that's
Speaker 2: roughly what it comes out to in production in practice.
Speaker 1: Okay. To be honest, I'm you know, I'm struggling to
Speaker 1: remember if I've ever used this. Probably not. I prefer
Speaker 1: my type to be a bit narrower, fantastic. It's not
Speaker 1: much better than in any. Let's put it this way.
Speaker 2: Yeah, it's it's like it's this weird kind of halfway
Speaker 2: between any and unknown, where a lot of things are
Speaker 2: assignable to it, but you can't really do anything with it.
Speaker 2: And honestly, some people just happen across the type and
Speaker 2: then use it instead of unknown. That's like a really
Speaker 2: common slip up there where they should have just used
Speaker 2: unknown or any.
Speaker 1: Yeah, that's what Jay Larki is saying as well.
Speaker 2: Hi j Larki.
Speaker 1: Yeah, so you you've got an S T S C slint.
Speaker 1: It's a problem. I start saying is lint, and then
Speaker 1: I remember to say ts. So you've got a T
Speaker 1: SC slint rule? That basic? What forbids it?
Speaker 2: We used to have. We used to have a rule
Speaker 2: called band types, which banned a list of problematic built
Speaker 2: in types such as that and uppercase en number as
Speaker 2: opposed to lowercase end numbers same as string and boolean.
Speaker 2: We split it up into several rules. So the specific
Speaker 2: rule we're talking about now I have to go to
Speaker 2: our website to look up the name because I can
Speaker 2: never remember is no empty object type that's specifically.
Speaker 1: For that one.
Speaker 2: And then we have a few other rules for other
Speaker 2: problematic built in types, like the uppercase built ins.
Speaker 1: So it's basically it's kind of like JavaScript in a sense.
Speaker 1: And it's not surprising that once type script adds stuff in,
Speaker 1: it's very difficult for them to take it out without
Speaker 1: you know, breaking an extinct code basis. But it's easier
Speaker 1: for you guys to add rules that forbid it.
Speaker 2: Yeah, and arguably in this case they made the right
Speaker 2: choice by having it as is. On my right, Let's
Speaker 2: say generic function that takes in a t a generic
Speaker 2: type that extends any object with length number as a property.
Speaker 2: So you could pass in strings arrays some object that
Speaker 2: happens to have length on it. That's all fine, intentionally,
Speaker 2: that type that squiggly brackets length number type allows a
Speaker 2: raise because the rays are objects that happen to have
Speaker 2: a length property. It would be weird and confusing if
Speaker 2: removing that length property from the object now meant a raise.
Speaker 2: Warrant allowed in this case. So there's no real right
Speaker 2: answer here. Either you have a weirdness in the type system,
Speaker 2: or you have a weirdness in the type system that
Speaker 2: also tips people up, sometimes in a different way than before.
Speaker 1: Interesting. Okay, So that was one interesting example. What will
Speaker 1: you had? The second one was it? What was it?
Speaker 2: I respect and appreciate that you remember that I'd forgotten
Speaker 2: about it. It's a new rule called no unnecessary type parameters.
Speaker 2: It's based on what's called the Golden Rule generics, which
Speaker 2: is actually comes from another types good book published by
Speaker 2: I Rightiley I'm authored by Dan Vandercamp, who then was
Speaker 2: a co author on the PR adding this lunch role.
Speaker 2: Shout out Dan Vandercamp. But the idea is people oftentimes
Speaker 2: write generic type parameters for functions that don't actually do
Speaker 2: anything or actively hide type errors inside. The most common
Speaker 2: one is they'll write wrappers around Jason dot stringify or
Speaker 2: some kind of parsing thing where they'll add in a
Speaker 2: generic type, saying, okay, the result of this function is
Speaker 2: whatever generic you pass me. Let's say Jason dot stringify
Speaker 2: my type turned Jason dot pars thingy as my type.
Speaker 2: The problem is there's nothing in the type system that
Speaker 2: actually verifies the value you return from that function is
Speaker 2: the type you said it was, and there's nothing at
Speaker 2: run time either, So this is unsafe. Someone could pass
Speaker 2: a totally invalid string and your type parameter usage made
Speaker 2: it look like the return of that function adheres to
Speaker 2: that type, even though the totally invalid string gave you
Speaker 2: some other garbage. So this is what's called the golden
Speaker 2: rule of generics. Only use type parameters if they are
Speaker 2: actively useful, if they're actually used to relate two types
Speaker 2: later on, or if they're somehow used repeatedly throughout your
Speaker 2: type signature. This rule is new, and I'm still not sure.
Speaker 2: I'm quite good at explaining it. Did that kind of
Speaker 2: make sense?
Speaker 1: Yeah, but I'm still thinking about it because but obviously,
Speaker 1: if there's a type that you pass in that you
Speaker 1: don't actually use, like an unused parameter, that's really easy
Speaker 1: to flag, but you are talking about something else.
Speaker 2: Yeah. Unused would be that it's declared once and never
Speaker 2: used again. Unnecessary in this context would be that it's
Speaker 2: declared once and used once, such as in the return.
Speaker 1: Of a function.
Speaker 2: The point of a type parameter is to relate two
Speaker 2: things to say, based on the input. The output is
Speaker 2: defend if you're.
Speaker 1: Yeah, if if you're just let's put it this way.
Speaker 1: If the type can never be inferred, then it's kind
Speaker 1: of and it's kind of pointless in a sense. I
Speaker 1: need to think about that though, like you might explicitly
Speaker 1: pass in a particular type. Let's put it this way.
Speaker 1: Whenever I'm whenever I'm using generics, and I find myself
Speaker 1: being required to explicitly specify the type rather than having
Speaker 1: it being inferred, then it kind of feels like a
Speaker 1: cold smell. Yeah.
Speaker 2: That's a great point, both on this context and just
Speaker 2: the general usability if you should stry sure you're you know, generic,
Speaker 2: such that people don't have to do weird explicit things.
Speaker 2: The I think a better example that I should have
Speaker 2: given to start would be let's say you're writing a
Speaker 2: generic log function. Log takes a typecharameter T and a
Speaker 2: single value of type T and returns void. So you
Speaker 2: could like log parentheses some strength, or log parentheses in
Speaker 2: a array or an object or whatnot. There's no point
Speaker 2: to that T, to that type parameter. You're not returning it.
Speaker 2: You could have said unknown for your values type and
Speaker 2: there would be no functional difference in your code or
Speaker 2: its types. So that T function log t parentheses value T.
Speaker 2: It's not unused because the value is still type T,
Speaker 2: but it's unnecessary. It doesn't change the return type. It
Speaker 2: doesn't relate anything. Does that make sense.
Speaker 1: Yes. Here's the thing though, because in in other programming
Speaker 1: languages statically typed programming languages where where the type system
Speaker 1: is part of the actual compile languages like C plus
Speaker 1: plus or Java or C sharp, then these case it
Speaker 1: is useful because that's for two reasons. First of all,
Speaker 1: that's how they make themselves more like JavaScript. And the
Speaker 1: second thing is that it allows them to have different
Speaker 1: implementations thanks to functional overloading. So they can have like
Speaker 1: a generic parameter like you said, t, and the type
Speaker 1: goes in, but then they have a different implementation if
Speaker 1: t is a string or t is a number, or
Speaker 1: t is an error or whatever. In JavaScript, those things
Speaker 1: are meaningless. First of all, you don't need to create
Speaker 1: dynamic on type of JavaScript because it is. And with Typescript,
Speaker 1: like you said, it's just any and you've got it.
Speaker 1: You've got the same dynamic capabilities that you had before,
Speaker 1: and you don't really have implementation overloading. So both of
Speaker 1: those benefits that you have in other programming languages are
Speaker 1: kind of meaningless in the context of Typescript. But like
Speaker 1: you said, it's too legal. So yeah, it's a place
Speaker 1: where the linter can kind of step in. But yeah,
Speaker 1: I think that's a really good example.
Speaker 2: Thanks what we've seen when people adopt the rule in
Speaker 2: larger code bases is still have the occasional little thing
Speaker 2: like the parts of the log function. It'll catch, you know,
Speaker 2: save them a few characters or some clarity here and there.
Speaker 2: But then deep in their utilities library, there will be
Speaker 2: this long trail of deleted code where there's this chain
Speaker 2: of whatever five things deeper. At the very bottom of
Speaker 2: the chain, there's an unnecessary type parameter. And because of
Speaker 2: that unnecessary type parameter existing, they previously had all sorts
Speaker 2: of places passing type parameters through piping it down to
Speaker 2: get there. And once we remove the unnecessary typearameter, we
Speaker 2: could delete a dozen different type parameters in their code,
Speaker 2: making it all simpler automatically or semi automatically with the rule,
Speaker 2: and it doesn't actually harm or remove anything that was useful.
Speaker 2: So this rule, I think is going to be more
Speaker 2: and more exciting to people as time goes on and
Speaker 2: we advertise it and learn about it more.
Speaker 1: Yeah, I've been thinking about another way to phrase it.
Speaker 1: At the end of the day, we have to remember
Speaker 1: that in typescript, ultimately all the types get stripped away.
Speaker 1: Types that you put in have zero impact on the
Speaker 1: code that gets generated. They're they're totally they're deleted in
Speaker 1: this context by the way. You know, it could have
Speaker 1: been a pick. But it's interesting, what then, what Node
Speaker 1: is now introducing with that ability to like with their
Speaker 1: support for typescript, which which literally just strips out all
Speaker 1: the types. And therefore, if if the types have zero
Speaker 1: impact on run time, they're value is that they assist
Speaker 1: you during the development time. But if they don't do that,
Speaker 1: then they're pointless.
Speaker 2: Yes, yeah, well, I mean I would say there is
Speaker 2: one point to them, which is some people feel very
Speaker 2: good when they put types in that are very complicated,
Speaker 2: and that honestly is a reason for a lot of
Speaker 2: the really complex types out there. And you know, sometimes
Speaker 2: it's worth it, sometimes it's not. I think a lot
Speaker 2: of developers go through a lot of growing pains adding types,
Speaker 2: getting excited about it, and then realizing, oh no, not
Speaker 2: all this was useful before they find that beautiful zen
Speaker 2: of only adding them where it's it's actually functional.
Speaker 1: Let's put it this way. You can have sophisticated types
Speaker 1: in your typescript if the end result is that the
Speaker 1: actual user of the API can avoid specifying any types.
Speaker 1: That's the true beauty of sophisticated types in typescript. Yeah,
Speaker 1: if you're the user of your API needs to specify
Speaker 1: types like in generic types, then then my argument is
Speaker 1: that it's a code smart you kind of failed.
Speaker 2: Yeah, it'd be cool to see if someone could enforce
Speaker 2: that with a Linch rule. You know, I don't know
Speaker 2: how that would work, but there whatever is the best practice.
Speaker 2: My instinct is to try to and codify it, even
Speaker 2: if it's not possible. You know, there are some best
Speaker 2: practices that are not really code capable.
Speaker 1: So, unless you've got more things that you want to
Speaker 1: say about typescript and types and linting, I think we
Speaker 1: want to talk a little bit about squiggle COMF, don't we.
Speaker 2: Yeah, let's do it. Squiggle COMF Conference for Excellent Web
Speaker 2: Dev twoing, Sparkle Emoji.
Speaker 1: It's it's one of those times where you actually want
Speaker 1: those automatic reactions that you get on the Mac where
Speaker 1: you do like something like that or balloons pop up.
Speaker 1: I can never get it to work when I wanted
Speaker 1: to work.
Speaker 2: Yeah, I think I disabled them at the OS level
Speaker 2: and then completely forgot about it. And I always get
Speaker 2: this point.
Speaker 1: So squiggle like I think you might have said that
Speaker 1: it's because of the squiggle lines that we get from
Speaker 1: developer tools that you know, want to highlight certain things
Speaker 1: or draw attention to certain things, so they put a
Speaker 1: squiggly line under it. I actually think that it came
Speaker 1: it was we had it first in things like word
Speaker 1: or office before it actually made its way to developer tooling.
Speaker 2: I think, yes, Like I also think that, but I'm
Speaker 2: not sure myself.
Speaker 1: Yeah, like spelling errors and then grammar errors and stuff
Speaker 1: like that and anyway, so that's the Moulti's that's where
Speaker 1: the name comes from. Right, It's because the topic of
Speaker 1: the conference is developer tooling, right.
Speaker 2: Yes, we're talking about I mean the catphrase is excellent
Speaker 2: web debt tooling. But in general, yeah, it's anything that you,
Speaker 2: as a person writing web such as without limited to JavaScript,
Speaker 2: typescript rust might want to learn about. So everything from
Speaker 2: typescript at scale at say how Bloomberg does things to
Speaker 2: the person who may know my Zisha's talking about the
Speaker 2: journey of that open source tooling and the lessons learned.
Speaker 1: So first of all, when and where.
Speaker 2: October third for talks and then morning workshops October fourth,
Speaker 2: that's a Thursday, twenty twenty four, so at time of
Speaker 2: recording in the month and a half.
Speaker 1: And it's like, is it online, is it physical? It is?
Speaker 2: It's physical. Will put the talks up for free videos
Speaker 2: after the conference. But the location, the venue is the
Speaker 2: attached theater at the Boston New England Aquarium, so we
Speaker 2: have got a bit of a fish theme. I will say,
Speaker 2: there's an excellent penguin exhibit next door at the aquarium itself,
Speaker 2: and we're on the pier, you know, like on the water,
Speaker 2: so I think it's going to be a lot of fun.
Speaker 2: Lunch is going to be at Feneral Hall that like
Speaker 2: really nice too of her Steam marketplace right next to
Speaker 2: the venue. And because it's a Thursday during the week,
Speaker 2: you have to be not so crowded.
Speaker 1: And it's so it's one day for the talks and
Speaker 1: the second day for workshops. That's the format.
Speaker 2: Yeah, morning workshops. We're trying to keep it a little smaller.
Speaker 2: I think our deal would have been two days of
Speaker 2: talks with some workshops, but it's our first time and
Speaker 2: we wanted to make sure we could get it right
Speaker 2: before really going thick.
Speaker 1: Can people still get tickets?
Speaker 2: They can, and I would encourage them to do so.
Speaker 2: Fun fact that a lot of conference organizers have told
Speaker 2: us we've seen also that most people wait until the
Speaker 2: last minute to buy tickets, which is horrible for two things.
Speaker 2: One it's well, you never know, maybe they'll sell out.
Speaker 2: Two it's very scary for US conference organizers.
Speaker 1: Yeah to see.
Speaker 2: Yeah, so please buy tickets. Discoidal the com We got
Speaker 2: both discount options on the website. We're happy to work
Speaker 2: with you if you need help getting it. We also
Speaker 2: have volunteering options if you can't afford a ticket.
Speaker 1: So let us know. So how many talks are you
Speaker 1: planning to have me?
Speaker 2: Get that schedule up right now? Currently our plan is
Speaker 2: nine full length talks and five lightning talks.
Speaker 1: Oh cool, that's really nice. Any any ones that you
Speaker 1: especially want to draw attention to, you.
Speaker 2: Know, I fear I fear responding to that to assertively,
Speaker 2: as I don't want to upset any speakers. But I'll
Speaker 2: say our launch speakers, as an arbitrary delineation are Dan
Speaker 2: Vandercamp whoever. Earlier he's talking about ASTs and source code
Speaker 2: and text like how source files actually work. Roselle Scarlett
Speaker 2: over at TVD talking about documentation as part of your
Speaker 2: tooling and processes, and Tishy and Cinacova dragon me are
Speaker 2: over at Bloomberg talking about Typescript at scale and the
Speaker 2: things they do to manage a gigantic amount of Typescript code.
Speaker 2: Also fun fact, they contributed some great features.
Speaker 1: Up to Typescript. Yeah, they're doing some really interesting stuff
Speaker 1: over at Bloomberg, that's for sure, So that is really cool. Also,
Speaker 1: Boston is obviously a beautiful city. Yeah, and October that
Speaker 1: means like fall, so it's like the trees will be
Speaker 1: all red and stuff.
Speaker 2: I hope, So, to be honest, I'd originally really wanted
Speaker 2: a Halloween conference, as that is my favorite holiday. By far,
Speaker 2: I was told rather bluntly that parents do not want
Speaker 2: a conference instead of trig or treating. It's not something
Speaker 2: that they can support. So yeah, I think we'll have
Speaker 2: a good fall thing going on. You're right. It's a
Speaker 2: beautiful city, beautiful area. And one of the things we
Speaker 2: intentionally did was have it on a Thursday with workshops
Speaker 2: next morning so that speakers can go with us on
Speaker 2: a ductor after and then we're going to try to
Speaker 2: get some kind of partnership with the aquarium to tell
Speaker 2: people explore that.
Speaker 1: Are you also still looking for sponsors and stuff like that.
Speaker 2: If someone wants to sponsor us, they certainly can reach out.
Speaker 2: It's on the website. But we've got a good set
Speaker 2: of sponsors so far. I can't now them all, but
Speaker 2: we're pretty happy with it. Yeah. No, if if you
Speaker 2: want to send us money, we're happy to work with you.
Speaker 1: That's really cool. It's it's really nice to see a
Speaker 1: new conference appearing. It's ever it seems like ever since COVID,
Speaker 1: you know, conferencing has been in a bit of a rut.
Speaker 1: Like we all hope that it would make a total
Speaker 1: comeback after COVID, but it seems to be fairly challenging,
Speaker 1: and I'm even seeing certain conferences like suspend operation and
Speaker 1: so seeing a new one come along, especially about such
Speaker 1: an important and exciting and interesting topic, seems like a
Speaker 1: great thing. And hopefully I can get my own employer
Speaker 1: to sponsor let's say next year or something, because we
Speaker 1: are also into developer stuff. You know, some of our
Speaker 1: stuff is and ready yet, so we're not ready to
Speaker 1: showcase it yet. Hopefully next year we will be. So
Speaker 1: we will say we will see. I'd love to talk
Speaker 1: at the confidence like that. Anything else before I put
Speaker 1: us in two picks.
Speaker 2: No, I appreciate actually, yeah, one thing. I appreciate you
Speaker 2: giving me the opportunity to like scriggle comp The reason
Speaker 2: why we chose to have it this year, you know,
Speaker 2: post COVID, neither neither of us two organizers actually live
Speaker 2: in Boston. I'm moving into August this year. Is we
Speaker 2: agree it there's a lot of benefit from conferences. You
Speaker 2: don't have to go to a conference, you know, to
Speaker 2: be whatever a great dev infortunate, et cetera. But there's
Speaker 2: a lot of benefit from the Hallway track, from just
Speaker 2: chatting with people. Oh yeah, for giving cocks. So we're
Speaker 2: really excited to be able to provide that, you know,
Speaker 2: to people, both generally in Boston and generally in web
Speaker 2: dep tooling, which doesn't have a lot of dedicated conferences
Speaker 2: for it specifically.
Speaker 1: Yeah, it seems like it should mean like developers are
Speaker 1: so into tooling. It feels like we are, like we
Speaker 1: definitely should have a conference about tooling. So it's it's
Speaker 1: great that finally we do.
Speaker 2: Yeah.
Speaker 1: But by the way, so this is I think, is
Speaker 1: it your first time as a conference organizer.
Speaker 2: Yeah, I've helped out with conferences before, like websites are
Speaker 2: helping with promotions, but nothing quite so in the weeds
Speaker 2: as being an actual organizer. And I gotta say it's
Speaker 2: a lot of work. They were right, all the people
Speaker 2: who told us it was a lot of work.
Speaker 1: Yeah, for sure, h happily I've I've yet to to
Speaker 1: to do it. I've I've spoken at conferences as have you,
Speaker 1: but organizing I don't know. I'd rather let somebody else
Speaker 1: do it. Okay, Then before we go going to picks,
Speaker 1: if people want to, you know, connect with you, be
Speaker 1: it about TSC S, flint, about linting in general, about
Speaker 1: open source, about squiggle conf what's the best way to
Speaker 1: reach out to you?
Speaker 2: Love the question for me. Joshua K. Goldberg on virtually
Speaker 2: every platform dot Com, GitHub, Twitch, YouTube, Twitter, Blue sky
Speaker 2: Mastered on Joshua K. Goldberg for my projects. Each of
Speaker 2: them have their own website. So tych it b a slint,
Speaker 2: be a slint moca. Yeslint time, but on the committer team.
Speaker 2: So please don't come at me yelling about flat configure
Speaker 2: or whatever pain you're going through. That's the team at
Speaker 2: holl but for all of the projects, we're always happy
Speaker 2: to hear your feedback and work with you.
Speaker 1: Cool. Okay, then I'll pull us now into picks. To
Speaker 1: be honest, if I don't have so much in the
Speaker 1: context of picks, I actually, you know what, I actually
Speaker 1: have two things. So my first pick is I might
Speaker 1: have mentioned this before. I recently started tweeting out my
Speaker 1: favorite stand alone fantasy novels. So one thing about fantasy
Speaker 1: books is that fantasy authors really love to write a
Speaker 1: series of books, usually trilogies, but not necessarily, and I
Speaker 1: sometimes want to just go for a single standalone books,
Speaker 1: something that you know, you can read on its own,
Speaker 1: finish it, and then kind of move on with your life.
Speaker 1: And that's especially the special benefit is that you don't
Speaker 1: have to worry about when the next book is ever
Speaker 1: going to come out, you know cough cough. You know
Speaker 1: uh George R. R. Martin and uh you know Game
Speaker 1: of Thrones and Tales of Ice and Fire, which seems
Speaker 1: to be to be honest, if he ever does come
Speaker 1: out with with the next book, which is I'm highly
Speaker 1: doubtful of, I probably won't read it now. It's it's
Speaker 1: the time. The time is coming gone anyway, So I
Speaker 1: I tweeted out the list. I actually have a couple
Speaker 1: of more books that I have to tweet out in
Speaker 1: this context, so you know, let me see if I
Speaker 1: can remember some of the examples that I gave. One
Speaker 1: of them would be Neil Gaiman's Never Where Have You
Speaker 1: Read It? No?
Speaker 2: But I know the author name.
Speaker 1: Yes, and uh. Another one is uh Zilasni's Lord of Light.
Speaker 1: Roger Zilasni was a very famous UH science fiction and
Speaker 1: fantasy author, very prolific, now deceased, so he wrote some
Speaker 1: very famous series of books. But I have a very
Speaker 1: special spot for the Lord of lightbook, which is a
Speaker 1: standalone book. And and you know, I'll basically i'll i'll
Speaker 1: post the link to that Twitter thread that I keep
Speaker 1: adding to in the show notes, so that would be
Speaker 1: my first pick. And by the way, if people have
Speaker 1: their own favorite books that they want to suggest, you know,
Speaker 1: feel free to send them to me. I love a
Speaker 1: good I love suggestions of good books. Another one, by
Speaker 1: the way, you know what, I'll give you another one
Speaker 1: or two. There's a Weave World by Clive Barker. Have
Speaker 1: you heard of Clive Barker?
Speaker 2: Vaguely familiar name.
Speaker 1: Yeah, he actually is more famous for writing horror related stuff,
Speaker 1: like the Pinhead character if You is from one of
Speaker 1: his books. And so he wrote this crazy book called
Speaker 1: weave World, which is a crazy combination of It's like
Speaker 1: part fantasy, part horror. It's very weird and it's very
Speaker 1: wonderful in my opinion. So that's another great standalone book.
Speaker 1: And another one would be Kigana by Guy Granville k.
Speaker 1: He's the guy that worked with Christopher Tolkien on releasing
Speaker 1: the Silmarillion. They basically went through Tolkien's notes and writings
Speaker 1: and and basically managed to make a book out of it.
Speaker 1: So he wrote some book on his own and his
Speaker 1: stand alone book is called tigan and it's also a
Speaker 1: great book. I think I actually picked that one. You
Speaker 1: our in the last episode that I participated on, sort
Speaker 1: mentioning it again the second. My second pick is I've
Speaker 1: been kind of down. This is this is not a
Speaker 1: good time for me. I mean, on a personal level,
Speaker 1: things are fine. I've got a new job that I'm
Speaker 1: happy with, Everybody in my family is healthy and whatnot.
Speaker 1: But my my mother in law passed away, and in
Speaker 1: Israel in general, it's a it's a bad time, and
Speaker 1: uh yeah, so I've been kind of down and I'm,
Speaker 1: you know, looking for things that can pick me up.
Speaker 1: And my wife and I happened on the Despicable Me
Speaker 1: Sash Minion movies and we kind of rewatched several of
Speaker 1: them and they're so great. They're so lighthearted, funny, pleasant
Speaker 1: to watch. The Minion characters are obviously wonderful, but not
Speaker 1: just the group character is great as well. So yeah,
Speaker 1: if you're looking for pick me up, I would definitely
Speaker 1: recommend these movies. And those would be my picks for today.
Speaker 1: Do you have any picks for us?
Speaker 2: Josh, I do plus one ted having some nice, lighthearted,
Speaker 2: high quality lightheartedness in today's world. I've been wanting to
Speaker 2: become more of a reader. I used to when as
Speaker 2: a teenager, read constantly, I know, exhoomed everything from the
Speaker 2: depths of the sci fi fantasy section of my local library,
Speaker 2: and I haven't done that as much recently, so I'm
Speaker 2: still kind of catching up. So recently I've led kind
Speaker 2: of the classics that a lot of people may know.
Speaker 2: Neuromancer is a great sci fi book. I think it's
Speaker 2: rather influence on the genre. I'm not cutting new ground here.
Speaker 2: I recently read through the Foundation series also, which was
Speaker 2: very good, really really changed over the course of the series. Yeah, yeah,
Speaker 2: a lot of respect for that.
Speaker 1: People should be aware that the book series is very
Speaker 1: different from the TV show. Both are actually pretty are good,
Speaker 1: but they're very different, both in terms of tone and
Speaker 1: the actual story. Yeah.
Speaker 2: Similar. On that note, Witcher loved the game, you know,
Speaker 2: Butcher three was the one I played. I've been meaning
Speaker 2: to play the others, and then I'm in a book
Speaker 2: club with some friends reading the series. Not a huge
Speaker 2: fan of the show, to be honest.
Speaker 1: Yeah, to me, to be honest as well, I wanted
Speaker 1: to say it. I tried to watch the show and
Speaker 1: I couldn't get into it.
Speaker 2: Yeah, there are a lot of great parts of it,
Speaker 2: especially Henry Cavill. Oh my gosh, but that one bathroom scene,
Speaker 2: but his acting is phenomenal, and just I couldn't get
Speaker 2: into the rest of.
Speaker 1: The show, you know. Yeah, yeah, this is what it is.
Speaker 2: It is what it is. Now. Otherwise, my wife and
Speaker 2: I we've been watching Monk, the old TV show. It's
Speaker 2: kind of hard.
Speaker 1: It's on Netflix, I believe.
Speaker 2: Yeah, yeah, midway through it. It's quite good. Highly recommend
Speaker 2: it's it's very nice. It's kind of the I think
Speaker 2: the epitome of that genre, that era of early two
Speaker 2: thousands episodic shows where people they had an appetite for
Speaker 2: actual good shows, but it wasn't you know, there's really
Speaker 2: deep intense stuff you get these days with these HBO
Speaker 2: mini series.
Speaker 1: Is so yeah, you could was just a single episode.
Speaker 1: Then it's totally self contained. It's not quite believable, like
Speaker 1: you know, it's it's funny to compare to a lot
Speaker 1: of the British TV shows of the same time or
Speaker 1: the same era, where in the American shows you had
Speaker 1: like that every episode was self contained. So I feel
Speaker 1: like it was a crime drama. The crime happened at
Speaker 1: the beginning, they solved it, there was a trial, the
Speaker 1: criminal got convicted done. It's like, you know, Law and
Speaker 1: Order I think was the epitome of that type of
Speaker 1: shows also and also CSI, whereas the British shows they
Speaker 1: kind of, you know, the entire season was just the
Speaker 1: one crime, and then the mini dramas of that you
Speaker 1: get on streaming today kind of emulate those those British
Speaker 1: shows where it's the entire season for that the one crime.
Speaker 2: Yeah, different that actually, by the way, reminds me I
Speaker 2: fell in love with the show Good Omens, the British one.
Speaker 2: I had never heard of it until it randomly popped
Speaker 2: up and read it or something. But it's fantastic. Highly recommend.
Speaker 2: It's this whimsical, I don't know, you know, biblical characters
Speaker 2: in the modern day. It's it has Michael Sheen and
Speaker 2: David Tennant. John Ham shows up in the later season.
Speaker 2: Really really good stuff. Highly recommend.
Speaker 1: Funnily, I read the book, but if not seen, not
Speaker 1: watch the TV show. The book, by the way, is
Speaker 1: by Neil Gaiman and Terry Pratchett.
Speaker 2: Yeah, it's hilarious. It's it's all sorts of lever. I'd say,
Speaker 2: it's I don't know how to describe these it's like
Speaker 2: very British humor, Like you know, it's it's these characters
Speaker 2: who driven by these odd quirks, just getting these ridiculous situations.
Speaker 2: But it's also this really compelling story about you know,
Speaker 2: good versus evil and the nuances and the inability to
Speaker 2: define those two concepts in a dynamic, people driven world.
Speaker 1: If that's your jam, then I would highly recommend that
Speaker 1: you read, not watch, read the Hitchhiker's Guide to the
Speaker 1: Galaxy series of books. The movies pretty bad. The books,
Speaker 1: on the other hand, are awesome. Okay, So so if
Speaker 1: that kind of sense of humor carry, Pratchett was very
Speaker 1: much inspired by Douglas Adams, let's put it this way. Yeah,
Speaker 1: So with that, I think i'll end our show. Thank
Speaker 1: you again for coming again onto our show and speaking
Speaker 1: both about tsslint and about squiggleconf and putting yourself out
Speaker 1: there and all the best with both endeavors and with
Speaker 1: the move to Boston.
Speaker 2: Thanks Dan. Yeah, I really appreciate you having me on here,
Speaker 2: letting me plug things, and also, you know, best of
Speaker 2: luck with the new job and getting them to sponsor
Speaker 2: school Comp twenty twenty five.
Speaker 1: Yeah, that's hope. That's hope. So okay, bye everybody, thank
Speaker 1: you for listening in. Bye bye.