'TypeChat' Panel Discussion

Hello, all. I'm John Riley, you know me. Do you, would you like to describe yourself? So, I, let's, let me have a first crack at this, because I think, Nathan, you've been part of the, part of the TypeScript team for the longest time. Gabriella, I think you're a recent joiner, and Titian, you're not part of the touchscreen, you're part of Bloomberg, but you contributed to TypeScript. That's me sort of like mangling your intros. I wonder if you could try and introduce yourselves a little bit more in-depth, and also tell us, tell us your journey to TypeScript. Nathan Cheively Sanders You want me to start? Yeah, go for it, Nathan. So I'm Nathan Cheively Sanders, and I've been working on TypeScript, I think for six and a half years now. Yeah, six and a half years. And before that, I worked on another compiler at Microsoft. And before that, I studied linguistics in grad school. And so all told, between starting on the TypeScript compiler, it had been about a decade since I'd written any JavaScript at all. And I just was looking for a different compiler to work on, and TypeScript seemed really cool and I tried it and it turned out to be a lot of fun. Yeah, so that's me. Amazing, thank you. What was the compiler that you're working on before that? It was an internal thing which I think was briefly sold as USQL. It was like somewhat marketed as a successor to T-SQL, except it wasn't. And then it turned out nobody wanted to buy it so I don't think it was for sale for very long. But it's a SQL dialect, yeah. Nice, thank you Nathan.

Gabriella, could you tell us your story? Yes. Sorry, there's a very annoying fly here. Sorry about that. I have been working on the TypeScript team since last year, in July. So everything TypeScript is very new to me. And I got here because I did an internship at Microsoft, working on a front-end project. And that's how I got to know TypeScript. So I thought it was pretty cool to have types in JavaScript. And I emailed someone from the TypeScript team, and they did a few internships, and here I am now. Nice.

That's really cool. Tishan, tell us your story. Yeah, I'm originally a C Sharp developer. I actually didn't have much love for JavaScript, quite frankly. And when I first saw TypeScript version 0.8, and I saw the types, and I saw, I can just press dot, and I get accurate code completions and all of that productivity enhancements, I was like, yeah, now I can do JavaScript. That's what I want to do. And I've been a huge fan of it ever since. So rest is history, as they say. Yes, yeah.

First question. So when you think of TypeScripts, and the...it's an amazing thing, obviously. But you must have, as language implementers, people who've worked on languages, regrets and mistakes around it. Things that you might do differently, like knowing what you know now, if you were to go back five years. So I'm curious if there's any of those that you've got in mind that you could share. One thing that I wish we could improve, or maybe get rid of entirely, is enums. They seem like a feature that should be useful, but the way they're implemented in TypeScript just isn't very strict. Except when it is strict, and they're just really complicated without actually providing too much benefit. And if we were to do them today, we'd have a bunch of features like with unions. Enums actually predate unions. We tried to retrofit union semantics on top of them, and it didn't really succeed. That's one thing I would either get rid of or change. I'm not sure which one. I don't know if you all ever used unions.

That's one thing I would either get rid of or change. I'm not sure which one. I don't know if you all ever used unions. I remember enums being there pretty much from the beginning and not really using them. I didn't like the fact that they had a MIT aspect to them. And then union types, string-literal unions came out, and I want to say it was 1.7 or 1.8, something like that. And it was like, I don't need it anymore. The compiler does exactly what I need in that space, just using this. Instead, I can now forget that this ever existed. And that's how I've rolled with regards to enums since then. For us in Bloomberg, for example, we actually use a pattern of creating an object and using ASCONST on it and emulating a union rather than using actual enums. I think for us, the deal-breaker is their non-standard. And that's why we've steered away from them. But I think that speaks to a broader theme of most of the things that came into TypeScript before TypeScript adopted this strict philosophy of just JavaScript plus types. I think a lot of those are sort of, at least from my point of view, features that people will try to avoid at present. Anyway, for example, namespaces and other things like that.

Yeah, there's a weird corner of the language I'm embarrassed about. I think it was my first feature on the team was this parameter, where you can have a normal function and you can say this colon. And inside that function, it'll pretend like this has that type. So you can sort of use it to sort of write extension methods kind of thing, not really. Yeah. But, at the time, I didn't realize it. And sort of the last feature we put in, that's in expression space. In other words, it's valid JavaScript, except that TypeScript lets you write something that shouldn't be able to go there. Yeah, but that feature is actually very useful. I don't think you could take it out of TypeScript. No, you can't take it out. Perhaps another syntax for it, but it definitely would have to be there in some form. And I think the reason was I've been writing a lot of C sharp in the years beforehand, and it seemed like a natural place to put it. And everybody on the team was like, yeah, it seems good.

Except I think Ron pointed out that he's on the TC39 committee, pointed out the TC39 committee is not going to like this. But I didn't know at the time. And so I think that's probably the last thing we did that sort of takes over JavaScript expression space. Yeah. It's funny, I know that TypeScript doesn't do semantic versioning, everything can break with each version as new language features come along, and the compiler becomes stricter. That breaking changes thing is actually useful because you want your compiler to get better and better and find more and more errors and make your code more and more correct. But at the same time, I think nothing has been removed from the language since 1.0. Nothing's radically changed since then. And I've always wondered, given that there's already an understanding that breaking changes are a thing, and I think the TypeScript will do, removing parts of the language that were like reliably agreed, okay this is a thing that we don't want to have, like this creates problems. I always wonder if that that could ever happen. I think the answer is no, but I'm like could it? Could it? Maybe? I mean, so I would say as long as TypeScript is part of Microsoft, the Microsoft philosophy is supporting customers as long as possible. Yeah that's so the basically the answer is no. And specifically inside of Microsoft, we have some very old code bases that still in theory somebody from that maintains that code might come to us and say, hey I need your help with this, please make the types compilers stop crashing or run faster or work with this new feature all of a sudden. And we try to give the same guarantees to the people outside Microsoft too. If there were a TypeScript that was sort of outside Microsoft and untethered from the Microsoft philosophy, it's possible but I don't see that day coming because TypeScript is just so integrated in all of Microsoft's properties at this point that it's something that it's not going to go away fast at all. Yeah. Yeah, that's a really interesting question. Like what would a TypeScript successor do that started over today? But it's not one that the TypeScript team can really do anything with. I think it'd be very cool to see what other people would do. Who are you talking about? Gabriela, you've got more recent eyes to TypeScript given that you joined relatively recently. I wonder if there's, as you look at something with new eyes, you often form different perspectives than the people who've been looking at something for 10 years. Are there things that you look at and you're like, that bit there, I think that that thing there could be different or should be different at all? Yes. I think that has happened quite a few times since I started. Once you start working as a language implementer, there is a lot that you start taking for granted. And other people that are just users of TypeScript, they don't know the internal knowledge of the compiler. Sometimes they can't make sense of what's really going on when say there's a weird error message. I know Arthur was talking about this when on the last talk. And it has happened quite a few times that I see an error message. And I go up to the rest of the team, and ask, Hey, what is going on here? This doesn't make sense to me. And then someone from the team comes and explains it in terms of the compiler internals.

And so, in light of how the compiler works, it makes sense. But a user wouldn't know what is going on. And we then try to make that better. So that people can understand what's the problem with their code. Even if they don't know how the compiler is computing all the types.

Have you seen a TypeScript error translator experiment? Yes. I took a quick look. What did you think? I think it's very nice. I would love to see some work on making error messages more accessible, and it's a really tough problem, right? Because there are some cases where you can immediately tell. I mean, a compiler could immediately tell what is wrong, but sometimes that is not the case. Sometimes, it all comes down to the intention of the user, and the compiler can't really figure out the intention, right? As easily as a human could.

So, I feel like there is always this tension between the user, what the user means, and making sure the compiler can understand that, and it's not always possible. But I guess we're doing our best. Yes, definitely. I really like the shape of that solution. I think it would be pretty good if interactively VS Code could give you a link underneath an error that you click, and it takes you to some page like that. I really like the way ESLint rules have it. This is okay. This is an error. This is okay, this is an error. It just has lots and lots of code examples for every lint rule.