The Changelog: Software Development, Open Source - TypeScript and open source at Microsoft (Interview)

Episode Date: April 24, 2015

Anders Hejlsberg and Jonathan Turner from the TypeScript team at Microsoft joined the show to talk about TypeScript, a typed superset of JavaScript that compiles to plain JavaScript from Microsoft. We cover Microsoft's acceptance and support of open source, why they open sourced TypeScript, the language design, adoption, how to get started, and the future of the language.

Welcome back everyone. This is the change log. I'm your host Adams to Kovac. This is episode 152. And on today's show, Jared and I are talking to two awesome developers behind TypeScript at Microsoft, Jonathan Turner and Anders Hausberg. Jonathan is the program manager and Anders is the language architect. So we go deep, sit back and listen as Jared and I get schooled on this typed based superset of JavaScript. We have three awesome sponsors for the show today. CodeShip, TopTow and DigitalOcean. We'll tell you a bit more about TopTow and DigitalOcean later in the show, but our friends at CodeShip have this new feature, wildcard deployments. Now you can get more flexible deployment workflows with wildcard deployment pipelines that trigger if a branch starts with a certain prefix.

You can do this. It's super easy. Use one deployment configuration from multiple branches and automatically deploy your feature, your release, your QA, etc. branches to the corresponding environments. It's the perfect feature for allowing your team to be super flexible in how you want to work and how your workflows should work for you. As always, CodeShip is free to get started. Get started by trying out their free plan, which includes 100 builds a month and five private projects.

Use the offer code, TheChangeLogPodcast to get 20% off any plan you choose for three months. Head to CodeShip.com slash TheChangeLog to get started. And now,

on to the show. All right, everyone, we're back. We got Jonathan Turner on the line, Anders Hausberg. He's done some cool stuff. Anders, we'll let you tell a bit in here in a second or two. But we also have Jared on the call today talking about TypeScript. Jared, are you excited? I'm excited, man.

Second time we have Microsoft people on the changelog recently. It's blowing my mind. It's a new Microsoft, and we'll find more, I'm sure. Jonathan, let's start with you. Introduce yourself, if you don't mind. Talk about who you are at Microsoft, what you do, and then Angel will follow up with you after Jonathan. Sure thing. So my name is Jonathan Turner.

I'm the program manager at Microsoft on the TypeScript team. So a program manager is kind of like, I don't know, the glorious cat herder. So I kind of run the design. I know, right? I run the design meetings. I do a lot of connections out to clients and kind of try to gather all the requirements

and make sure we're on the right track. Anders, what about you? I'm Anders Hals about you? I'm Anders Halsberg, and I'm a technical fellow at Microsoft. These days, I'm working on TypeScript, but I've spent many years, over a decade, working on.NET and C Sharp.

Before that, I was at Borland for about 13 years and worked on Turbo Pascal and Delphi and lots of other things. Jared, in our pre-call, you had some pretty unique asks for Andrews. Anything in particular on Delphi? In the pre-call, we kind of determined it's not Delphi.

It depends on which side of the Atlantic you live on, if it's Delphi or Delphi. So what else? I'll just say I'm apparently a Brit at heart or something because Delphi just sounds right to me, always has. I've been corrected. I stand corrected. I'm going to try to say Delphi because Anders, if you say it's Delphi, I'll go with Delphi. Although to the guy who invented the GIF, I'm not going to relent on that one.

I'm not going to call it a GIF. Sorry, fella. But for you, Anders, I'll definitely go with Delphi. Yeah, I was wondering, with your history, and on the Wikipedia page for TypeScript, you're kind of named as,

I don't know, the inventor of TypeScript or at least the person who got it started inside of Microsoft. We're curious how that came about. If it was your idea,

if somebody approached you, if there was a core team at the beginning, maybe just give us a backstory of your role at Microsoft and how TypeScript has been involved in it. Yeah, no, I mean, TypeScript is obviously a team effort. And I would say I lead the team as sort of the architect for the language. And I also work actively on the compiler. The project probably, I probably trying to think well we went public in October of 2012. I remember that I was

trying to think back the other day when we started it was probably well it must have been sometime in 2011 probably late 2011 and we sort of had this on and off conversation about what are we going to do going forward for JavaScript? We saw increasingly that people were writing larger and larger applications in-house as well as externally in JavaScript, just because, you know, that's sort of like the only cross-platform game left in town. People were finding, certainly in-house, that it's hard to maintain these large apps. As they get beyond a certain size, it just becomes incredibly hard to keep it all in your head. And when you want to do refactorings or anything of a larger nature,

it's like playing with landmines to refactor a JavaScript code base because you can never really be certain that you have tests to cover everything. And if you pick the name for a property, like say text or whatever, then there's a million of things called text and how do you know that you're getting the right ones? And people basically were trying to solve this problem in a variety of different ways we saw like at google for example they have gwt or quit as they called it early on which was the idea there is you author in java and

then you cross compile it to javascript and that allows you to get the grown-up tooling of java and the java ecosystem but it allows you to run it in the browser. And we actually had a project in-house that was similar in nature called Scriptsharp that Office has used for a number of their large projects. And we were sort of toying with the idea, boy, should we productize that maybe? But then the more we thought about it, the more we felt that, hey, if you really want to do something in a community like JavaScript,

you really should aim to be best of breed. You know, you really should aim to solve the problems on the community's terms, not on your terms, so to speak. And so, you know, we try to put our JavaScript hat on and go, well, what is it that a JavaScript programmer would want here for their large apps? And it's clearly not to substitute a different language, but rather it's to remedy, you know, those things that are missing in

JavaScript. And at the time, you know, now before ECMAScript 6, that was things like classes and modules and interfaces, but also static typing, the ability to actually describe, hey, this function, yeah, it takes three parameters. But by the way, I could also tell you what the types of those parameters are supposed to be, and then maybe you could check it for me instead of just blowing up at runtime um and so so that was sort of the the genesis of typescript was really is there a way we could we could add all of those things to javascript without actually messing with its core value proposition you know which is that it runs everywhere and is there a way we could do it so that you can maximally leverage all of the goodness that already existed in the JavaScript ecosystem? You know, I mean, you guys know us as well as we, that there's just an enormous amount of effort being poured into JavaScript in the open source community around frameworks for JavaScript, right? I mean, the classic example

is jQuery, but then, you know, beyond that, it's just been astounding how many different frameworks there are. And so part of our design, sort of our key design goal was to make sure that we could leverage all of that or that you wouldn't have to give up all of that. And that, again, you know,

led us basically to design a superset of JavaScript that compiles to plain JavaScript. And then, I mean, I think from there on, it was really just sort of execution. I think that was sort of the core insight there was let's not try to make you code in JavaScript by having you coding something else, because that's just never going to leverage the knowledge that you already have. And TypeScript really is, it is just like coding in JavaScript.

I mean, if you look at your method bodies, they are exactly the same code, because mostly we can infer the types for you. It's really just the sort of surrounding fluff, like you can put type annotations on your parameters and whatever, and you can write declaration files for existing frameworks so we can pick up the static type information that way. So it was October 2012 when it first went public.

Like you said, it was probably one or two years before that that you guys were working on it internally. Did you have internal teams using it either in production or in research prior to that public launch? Yeah, it's been about three teams that were using it prior to it going public. One of those teams has now grown to become what's called Monaco. It's like an ID in the web browser. Part of Visual Studio Online. So that's been kind of cool to watch that. They've been dot-footing since long before it was public and have been tracking along with us. As we've grown, they've been growing as well.

Yeah, and then the F12 tools in Internet Explorer were written in TypeScript before we had gone public. And I think we have some Azure properties that also used us before we went out. So what would you say, just estimating the time span between ideation of, let's do this superset of JavaScript with type annotations, and having something working usable that your teams were using internally? We're talking six months, a year? How long did that take? Somewhere in that range, I would say.

We started there. You always get there in circuitous ways. In the beginning, the vision I just laid out wasn't actually that clear, you know, and we thought, well, maybe then also, you know, a key aspect is going to be having the VM use this type information to more efficiently execute the code. And that's still an interesting idea, but it turned out not to be the sort of design pivot that we maybe thought in the beginning. I mean, in a sense, becoming less ambitious

made us better able to focus. Once we started thinking tooling is the important part, write ES6 and make good tooling work on top of it, so error checking and navigating to your code. And I show some of this in the ng-conf talk, if you guys saw it. But you can just kind of quickly bounce around your code base

doing refactoring, renaming, and it's really, like Andrews was saying, you're still just playing with JavaScript with a little bit of extra help. I guess maybe the next question, Jared, might be a little bigger than that. So Microsoft's been changing quite a bit over the last, I'd say,

year at least that I can tell from the outside. Adopting open source, seeing and embracing open source a lot more, embracing the community, embracing pull requests on GitHub. And I'm wondering what role TypeScript plays in the future of Microsoft's direction, like being HTML, CSS, JavaScript focused in the operating system and on the phone and elsewhere.

How did top-down this come? Did it come from top-down? Did it come from bottom-up to see here's how we're solving solutions or solving these problems, but also sort of Microsoft's general direction for product. Yeah, it's funny. It's not that it came, it's neither top-down nor bottom-up. It sort of organically came from people who were more affinitized with areas that are in the open-source space. Do you know what I mean? It's like HTML, JavaScript, CSS, whatever, is very affinitized with open source, I would say, because it's cross-platform, it runs everywhere, that's sort of its bread and butter, right? And it's almost ridiculous to think about doing anything

in that space without doing it open source. But over time, that has gotten truer and truer for more and more areas, right? As, you know, it all sort of started with developers, started like very developer technologies. And now it's sort of spread into more and more, you know, throughout the software ecosystem, if you will. I think, I mean, we were early with, you know, on a Microsoft timescale, if you will, with open source. And a lot of our learnings, we have shared with other groups in the company. But now, certainly in the division, we sit in the developer division,

the default answer here is that it's open source unless you have good reasons why it shouldn't be and that's a big that's a big turnaround from where we were you know and that was certainly not the default when we started with typescript um but i will say i mean uniformly even at that time people sort of realized that we have to we have to do this it's more question of how you know because it's a big company with a lot of engineering culture that was just done differently, right? And you don't just change it overnight. And I would say even for us, you know, like we sort of stumbled into open source in the beginning a little bit. You know, we hosted on CodePlex because that was Microsoft's open source repository, right?

But that's not really where that community is. And you come to realize that and you come to realize. So they're sort of like doing open source and then there's doing open source the open source way. And the latter takes a while to learn, right? I mean, there's just a culture there like there is in any vibrant community. And then you sort of got to experience it in order to live it, right? Just to speak to your point about how early inside Microsoft y'all were as far as open sourcing, like you said, October 2012. Recently, we had on the.NET Core team, that's episode 134.

And that was like December 2014 is when that show aired. They had open source.NET announced the open sourcing of it sometime before that, but within six months. So there's 2014 versus 2012. You guys were definitely one of the earlier teams. Was there a decision to be made? Or was it just a fact of like, was there even a discussion like this is going to be open source? Or was that something that y'all had to come to? I think it was, you know, to the people that were part of that decision, I think it was clear to everyone that there's no way we're going to appeal to the JavaScript community if we're not open source.

I mean, we might appeal to a slice of the JavaScript community, i.e. the slice that uses Microsoft tooling, but that wasn't really the slice that we wanted to appeal to. We wanted to broadly appeal to the JavaScript community and really sort of deliver value in that community, right? And I think we all understood that that had to mean open source. It just had to. And does that speak to your sensibilities? Because languages that you've had parted in the past, Delphi, proprietary, at least the compiler is. I'm not sure.

Is the specification for Delphi open source? Or is that all proprietary stuff? I don't know that there was one. Well, there's your answer then. No, it was not open source. I mean, heck, open source hadn't been invented at the time. So there was just no way it could be. I mean, on open

source, it's... What year was that? Early 90s? Yeah, but Delphi goes all the way back to... Turbo Pascal was in 83, right? And then Delphi sort of grew out of that. But yeah, I... In the Microsoft ecosystem, there wasn't open source going on back then in the 90s when Delphi was having its heyday, right? I'm not sure. Because I wasn't here. Yeah, yeah, yeah.

Okay. But either way, you know, it's – I mean, the world has changed, right? I mean, and it's just, you know, back then, that was sort of how you bootstrapped yourself as a company, you know. And I will say that the one thing I think that Turbo Pascal and Delphi both did was they – I mean, Turbo Pascal at the time delivered a product that probably was an order of magnitude more efficient and cost an order of magnitude less than its competition, right? And so it maybe wasn't free, but it was pretty close to free. It was 50 bucks where the competition was 500 bucks. And it ran at least 10 times faster than the competition, right?

So it definitely changed things in other ways, right? Today, it's funny how we sell software and how open source is financed because, obviously, ultimately someone has to foot the bill, right? But that's a different discussion, right? But it's, yeah, yeah. Yeah, that's a discussion we have often on ChangeLog, because we're often talking to small startups who are trying to bootstrap a company

and do open source or do open source. And it's still something that people are trying to figure out, like, is this even viable to have a purely open source company? So yeah, huge discussions and interesting things. But let's reel it back in and get back to where you guys are at. Because in 2012, you announced when public. Recently, here we are in 2015, we've seen kind of a, I don't know if I'd call it a groundswell quite yet, but it's getting there where all of a sudden adoption is starting to really ramp up.

We have Angular 2 announcing it'll be TypeScript driven. Dojo 2, definitely others. What can you attribute that to? Is it just, it just takes time? How was it received? Let's stop there for a second. How was it received when you guys first went public? It was a mix of enthusiasm and suspicion.

I remember the first day when we went public, we were watching all the social media and the Twitter and, you know, whatever, the Twitter. And I'm watching a stream of just negative just one after another and then another stream of positive i'm like oh my gosh and you know this is what it's like to to jump right into the pool and and get feedback immediately and it was it was interesting to kind of see once people started playing with it there was definitely a trickle maybe a trickle at first of people playing with it saying i'm never going to use this but I'm going to try it for five minutes. And then after that going, oh, I get it.

I get why they did this. This is actually kind of cool. And I think it took time for people to get over, yes, it's Microsoft. Okay, get over that. Try it. And kind of move towards something of like, it's just a tool. It's just the tool for doing JavaScript and web programming and stuff. When you say that, it seems like there's a little bit of suspicion there. Maybe the initial reaction was like, why is Microsoft doing something open source in the vein of JavaScript?

Especially back in 2012 when we had no, there's no precedence of Microsoft doing, you know, large scale open source projects. No, and our track record in JavaScript perhaps wasn't the best at that time either. So, yeah, I mean, it's, you know, I always felt like you got to earn it, you know, and I was not surprised that we got the reaction that we did. I was actually fairly happy that we got as much positive reaction to it as we did. And I've always just believed that, hey, you know, we're just going to stick to it.

We're going to deliver some good product here. We're going to do some good engineering. We're going to try and solve the problem because I think we had the right idea for how to solve it. And then they'll come. Well, maybe they won't, but we're going to believe that they'll come. And now they're starting to come. But we've done a lot of hard work and we've tried to listen to the community. But we've also tried to have a point of view on how to solve this problem. We're not turning it into a kitchen sink, which is very easy to do in the JavaScript space, too, because there's a new technology or a new framework or a new

methodology born every day. You've got to stick to your guns on certain areas, but then still listen to the feedback. I think also one thing that I think we did right was to self-host and dog food from day one. A lot of these transpilers, well, now they're not, but in the beginning, you know, early on, like GWT and ScriptSharp, they target JavaScript, but they're not written in JavaScript. And they don't actually live and breathe the JavaScript community. Do you know what I mean? And I felt that we had to do that.

And the other thing I would say that I think was a guiding principle was that we're not just writing a compiler here. And then we're not really doing this. We're doing this because it ultimately enables us to build great tooling. And we're not just going to open source the compiler. We're going to open source the tooling because it's really the higher orbit here is the tooling. It's the fact that you can get safe refactoring, code navigation, find all references, go to definition, et cetera, et cetera. And these are just like productivity must-haves today on large projects, right? And they're all powered by this knowledge that the compiler has, but if you lock it up in a black box, you know,

that is just a command line tool, then you're not really solving the problem, right? So you got to actually make your compiler into an API, and you got to architect your compiler so that it can be super incremental and super lazy in how it does its work so that it can deliver answers in sub-100 millisecond time, even on a 200,000 line project, right? Which, you know, honestly, if you'd asked me five years or 10 years ago, I would have just said that is just never going to be possible in JavaScript. But it turns out it is. And so that was sort of a bet that we took

there on the technology and on our own ability to do it, but it's worked out. What's different? What didn't you expect five or ten years ago when you said that was not possible in JavaScript? Just the browser wars or the hardware has increased? Or what is it that makes that possible? I think the order of magnitude improvements in the VMs. I don't think we all saw that coming. And I'll give credit to the V8 team and Lars Bach and the work they did in Aarhus.

It's just amazing. And now we're all doing it, you know, but they really sort of pioneered something there that was quite impressive. Yeah, it's kind of a shining example of that rising tide, you know, brings all the ships up because once that competition got really kicked off and all parties got involved,

it would have been fun to watch from our side. And just, it is amazing what you can do in JavaScript now that even three or four years ago was just impossible and possibly slow. Yeah. To this day, I am still... I am still...

There are days where I go, wow. That's amazing. Well, let's pause there then. Let's dive into some amazing stuff. But before we do that, let's take a quick break and hear a word from one of our awesome sponsors. We'll be right back. You've heard me talk about TopTile several times on this podcast. And TopTile is by far the best place to work as a freelance software developer.

Well, they have this term elite engineer. And that defines the kind of software developer that works at TopTile. I had a chance to sit down and talk to Brendan Benesha, the co-founder and COO of TopTile, and I asked him, Brendan, what is an elite engineer? Take a listen. An elite engineer for us is somebody who satisfies

all the technical requirements that you would need in a great developer if you're working at like a Google or Facebook. But then at TopTel, you have to add this extra layer on top of it to make sure that people are mature enough and professional enough to be totally self-directed. And so making sure that they take a tremendous amount of pride in their work and that they're accountable and very, very communicative because in remote freelancing, that's sometimes just as important as being technically competent. All right.

If Brendan got you excited about being an elite engineer at TopTile, head to toptile.com slash developers. That's T-O-P-T-A-L dot com slash developers to learn more and tell them the cheese load sent you. All right. So we've been talking heavily, and as you got some deep subjects you took there, I almost wanted to vein off on several different directions,

but I think let's circle around language design of TypeScript. It's a superset of JavaScript. What else can you describe for TypeScript to sort of take us into the conversation around language design? I think, you know, I mean, so sort of the things maybe that are interesting to observe about it is that traditionally type systems have sort of been an on or an off thing. You know, you either had your dynamic language, which had no type system, or at least not an observable type system

and everything was just dynamic or you would be programming in a proper statically type programming language say like c sharp or java or c plus plus or c or whatever and everything would be statically typed so it was either you were either on or you were off on types i think the thing that's interesting about typescript is that that it is it is an optionally typed or a gradually typed system. We've turned the switch into a dial. You can dial up the types. The dial starts at zero, and that's just JavaScript. And you can literally rename all your JavaScript files to.ts and just run them through our compiler.

And you'll get a bunch of errors, but our errors aren't really errors. They're all warnings, right? Because the output we produce is indeed exactly the same files that came in because there were no type annotations to remove, right? So when the dial's at zero, we sort of function as a linter, if you will, that we do our best effort on inference, but in the absence of any type annotations, you know, there's only so much we can infer. But based on those inferences, we'll give you some errors, right? But then as you dial it up and you add type annotations, then more and more stuff comes alive.

But you can sort of leave the dial wherever you want, right? You can use jQuery or whatever, a whole bunch of JavaScript frameworks just as JavaScript. And then you can, on the side, provide the type information or not provide the type information. And if you provide the type information in a declaration file, then the tool can do more things for you, like statement completion and so forth. But it's perfectly happy for you to not do it, And then it's just dynamically typed. And that's sort of been an interesting world to navigate because no one had really done that before, you know, that I know of. It was all or nothing, right?

Like you had to jump into a tool or not. Yeah, exactly. Yeah. Yep. And so that was a super interesting design point. And I think we learned a lot from it. I think the other thing that I would say that has been interesting from a language design perspective is that TypeScript's type system isn't about

providing absolute waterproof guarantees that these types are correct. We're not provably correct. We're just correct enough. Because ultimately, when you start with a dynamic language where something can be of type any, then you have a Swiss cheese, right? And it's just about plugging as many of the holes as is feasible. It's not about plugging every hole, right? And traditionally, Java and C Sharp and a lot of other languages have been about plugging every hole and providing strict guarantees. And that's obviously useful, but it lands you in a different place, right? But if you think about it, for JavaScript, there's no way that we could ever land there, right? Because that decision has already been made.

The runtime system is dynamic. But it turns out that there's still a lot of goodness you can get from having types. A whole lot of goodness, right, in the tooling, even if the types are not provably correct. There's one other that I would probably add to that list that I like, which is the structural type. Yes. Traditionally in OO systems, you're what's called anomaly type. You've got the class name and you're like, all right, I'm going to subclass

this class name. Every time you're checking the types, you're checking that these names are matching. But in JavaScript, everything is very loosey-goosey. I can make an object literal and I can pass it in or I can instantiate a class as an object and pass that in. And for us, everything, we just look at the inside of the type.

It's the structures match. If it walks like a dog and quacks like a dog, that kind of thing. And that makes it so easy to extend existing systems and grow systems in a really flexible way that doesn't require these deep inheritance hierarchies. It's really lightweight and it's really nice. Yeah, it's much truer to the underlying truth of JavaScript, which is very dynamic, right? Right.

So first of all, I think making it a strict superset of JavaScript, as far as adoption is concerned, is kind of a brilliant move because now I can dip my toe in the water, right? And I can opt in when I want to, as opposed to a big rewrite or having to make a big decision up front to use TypeScript or plain old JavaScript. But when I opt in to those type annotations, it sounds like the biggest wins are in tooling, which are valid, nice wins, of course. Do you also have performance

wins or is it because the runtime itself is still dynamic? You can't do any compile time performance because it's not provably correct? Well, I mean, it's, it's, it's so, so you're right that you, you, you, I would say it's tooling, but it's, of course, also correctness, right? And, you know, sort of the notion that you can sleep better at night because some system actually, like, tried to validate your code here and told you about a bunch of problems that otherwise you would have found as you ran the app. One of the nice things on the TypeScript team is we had the creator of the Chakra runtime engine, the JavaScript engine for Internet Explorer. So he was helping us early on the code that the compiler generated. So the classes and whatnot, the corresponding code that they output, he was looking at that and saying, all right, for this to be optimized, we should do it slightly differently.

And so his input meant that if you're writing against the class syntax and whatnot in TypeScript, you're getting very performant JavaScript on the outside. The carry from that is that the V8 team took the TypeScript compiler and put it into their test suite. So it wasn't just IE. Now you have Google Chrome getting all the performance benefits from those patterns. Well, that's interesting for sure.

Beyond type annotations, obviously, that's your flagstone feature there. You know, the name TypeScript. It's all about type annotations. Are there any other big features that TypeScript adds to JavaScript that are nice to have? I think I would sum it up as we do two things. One is types and all of the great tooling and correctness proving that comes from that. And the other is delivering features from the future today. Basically, giving you the ability to run down level or compile to down level, right?

I mean, we started out with delivering a bunch of ES6 features, but allowing you to compile them down level to ES5 and ES3, like classes and arrow functions and so forth, right? And now, of course, now ECMAScript itself is catching up, and ES6 is almost ratified. It's going to happen in a month or two. And we are catching up also in that we now support pretty much the full ES6 language. But now we're also delivering features from the future again because we're starting to spike implementations of decorators and async await and some of the other features that are being considered for ECMAScript 7.

And it's really sort of a repeat N plus one of the same phenomenon, right? Because the truth is that even when a version of ECMAScript gets ratified, it takes years for that to actually permeate throughout the JavaScript ecosystem. In some places, it permeates quickly, like on the server, where you can arrange your own execution environment just by installing a new version of Node or whatever, right? Then you can pretty rapidly adopt. But in the browser, I mean, you don't really have control of that. And it takes three, four years before you can, I mean, even today,

you can't necessarily say that you require ECMAScript 5, right? I mean, we certainly, I mean, it's getting truer and truer, right? But look at when did ECMAScript 5 come out, right? I mean, we're talking about, what is it, what is it in 2009, right? I mean, I think that Enver just had their vote for IE support like a week or two ago to whether they should remove early versions of IE. So that's still the conversation that the long-term support guys are still having. So the reality probably is that it's going to be somewhere between three and five years before you can assume ECMAScript 6. And that means until then, you're going to need a transpiler or a down-leveler, right?

And TypeScript delivers both in one. And that's a pretty compelling combination. I mean, both that and the types, right? How do you guys decide on which features are going to go in, these early features? So let's talk ES7, which they're just now figuring some things out. Some are probably going to go in. Some aren't.

I'm just looking at a compatibility table. There's some features I've never even heard of. Reflect.realm, apparently that's a proposed feature for ES7. How do you decide when stuff goes in? Because you get in a situation where all of a sudden you add, let's say you add support for reflect.realm, and don't ask me what that means, but let's say you guys add that to TypeScript,

and then it doesn't get ratified, or none of the browsers actually are ever going to support it. Do you guys pull it? Do you just wait until you're sure something's going to go in? How do you deal with that? Yeah, so first of all, I think reflect.realm is actually probably a runtime library feature. So that one isn't that hard. And the runtime library features, generally speaking, you can just polyfill,

and it's a pretty established sort of scheme for how you deal with that. Other features like modules, for example, modules were late to land in ES6. You could argue that they haven't fully landed yet either because the standard doesn't actually include a spec for a module loader, which ultimately means you're going to be dependent on someone externally to provide that loader. Now, with those, well, sometimes we have to guess, right? I mean, in TypeScript, we realized early on that, hey, we're going to need some sort of module system. One of the biggest problems of JavaScript is the lack of modular compilation.

One of the things that was powering Node.js was the common JS modules and require.js in the browser and AMD modules, was sort of becoming the norm for large-scale JavaScript application development, which is where we wanted to go. So we had to have modules. So we had to sort of do a

best-guess effort of where modules were going to go, and try to make our syntactic footprint as small as possible and then just go with it and then let it ride out. And that's what we did. And it turns out we shot pretty close to the target, but it didn't land because the current proposal didn't even exist at the time.

So now we've aligned, and it turns out that we can support both. We're not going to take stuff away. I've always been a big believer in backwards compatibility. If you look at all of my work and all the languages I've worked on, they've pretty much always been backwards compatible. If you give up backwards compatibility, you also give up your community. Now the community can go shop around and maybe they'll come with you or maybe they won't. But listen, you've got to bring them along. And honestly, it's the responsible thing to do too. People have a huge

investment in their code. So we're going to continue to support what we previously supported, but then we're also supporting ECMAScript 6 modules and we expect people to continue to support what we previously supported, but then we're also supporting ECMAScript 6 modules, and we expect people to migrate to that fully over time. So it's doable. You end up with a little bit of baggage, and you can park it under a compiler switch or something, and it's fun. It was the right thing to do, I think. But we are definitely committed to tracking the standards. I should say that.

And you can certainly see that in our work, too. Even when you disagree with them? Yeah. Oh, yeah. Hey, some of the things in the module system today I may not necessarily agree with. But there it is. And that's water under the bridge, right? Right.

I mean, we participate in the standardization effort, too. So, you know, but it is, and that's water under the bridge, right? I mean, we participate in the standardization effort too. So, you know, but it's, yeah. So is there a canonical place to go for people to find, these are the features that TypeScript adds that may or may not be available in ES6 or in the browsers today? Do you guys have a place? Oh, like on top of the type system and on top of the JavaScript standard stuff,

the additional features? Yeah, or even features that have not quite been standardized yet or are in the process that you could perhaps use this in Chrome today, but you can use it in TypeScript and it'll handle everything. Well, I mean, all of the type system is, of course, a feature that we add, right? Sure, sure. And all of the notation for how you write down interface types and union types and tuple types and blah, blah, blah.

And how does type inference work and how do generics work? And all of that stuff is, of course, on top. And something that we spec in our language specification. If you're curious about ES7 features, on the GitHub site, there's the roadmap. And we kind of roughly sketch out, I mean, we don't know exactly which feature is going when, but we've got a rough idea for this version and the next version, so we kind of put that on the roadmap.

Yeah, there's a link to our roadmap on the TypeScript front page on GitHub. Oh, cool. Perfect. That's helpful, yeah. So let's talk a little bit about the compiler and the implementation of the compiler. One thing you said earlier, Anders, which kind of piqued my interest, is about the compiler's API and how important that was. Tell us about that, and then also tell us how it's implemented. Is it in TypeScript? I think you said it is.

But just give us some of the details of the compiler. Okay. It is in TypeScript, yes. I mean, like I said, we believe in dark booting, and we've actually had several versions of the compiler, but they were all written in TypeScript. I'm going to say probably 32,000 lines or thereabouts for the core compiler itself. And then another 15,000 to 20,000 lines for the language service. About 50,000 lines all up. Before Anders has a chance to be a little humble, he wrote most of the new version of the compiler. So he was just kind of brainstorming ways that we could be faster and lighter weight.

And in his free time was coming up with these ideas. I was like, guys, I think we should go this direction. And they're like, no, we don't need to rewrite it. We just released 1.0. And I was like, no, no, I think that's the way we should go. And sure enough, as it started coming together, it was like five times faster than the original 1.0 compiler. So he deserves a lot of credit for that.

And it was pretty much rewritten already by the time he had brought you guys the results. Was there a big effort after that or was it pretty much done? Well, I mean, it's actually kind of interesting because there are a couple of things, first of all, that I would say about how the compiler is currently implemented. One actually is sort of a general observation about compiler writing these days, which is there's sort of the way that the universities will teach you how to write compilers. And then there's the way that you have to write a compiler today for it to be relevant. And they're actually a little bit divergent right now

because universities tend to still teach you the classic way of writing a compiler with, you know, you have a scanner and a parser and you probably use some LALR generator, you know, to generate your parser and then you have your code generator and da-da-da-da-da. And then there's this thing called speed and performance that you don't get to. But even more importantly, there's this thing called incrementalness that is an absolute must for a compiler that you can build into an IDE.

In an IDE, when you're sitting there typing code, let's say you're in a 15,000 line JavaScript file that's part of a 50,000-line project, which so happens to be how, say, our compiler works, right? And I type foo dot. I want to see immediately what could I type here. And I'm not. If it takes more than 100 milliseconds, I'm going to get annoyed. Now, delivering meaningful, semantically correct answers in 100 milliseconds is simply impossible with the way schools teach you how to write compilers. You've got to go about it completely differently.

You've got to be much more incremental in your data structures. You've got to think about different problems. implemented in a very, very lazy manner that produces just the right amount of information on demand, as opposed to binding everything up front and then knowing the answer to everything, even though I actually only need the answer to this over here right now. So that's interesting. And there's a lot of learnings there that I think are interesting. With an editor, too, and this is kind of obvious once I say it, but as you're typing, most of your program isn't correct while you're typing.

So your language service has to be resilient to the fact that you're having errors left and right because everything's in transition, and then you stop because you've hit a stopping point. Right. Literally, a single character typed at the right place in your editor can profoundly and completely change the meaning of your program. Right? Now, most characters don't, but sometimes they do. You know, like you start a comment here and the rest of your file becomes a comment or this identifier becomes another name and now all of a sudden it doesn't shadow another identifier and 10,000 references bind to a different symbol. Do you know what I mean?

There's all these subtle things and it turns out that doing that incrementally, it's a challenging problem and you can very quickly go astray in oh, well, I'm going to keep all these tables that backlink to this, and then I'm going to try to incrementally update them. And then before you know it, you're generating so much information that is so subtle in the way that it interacts that you die a quick death, right? And you really have to be pretty, you have to think about this problem hard to get it to be fast, especially in JavaScript.

I never really thought about it like that. That sounds like a really hard problem. I've never had to solve that problem before. It's a fun problem. And I think we, I mean, I'm not going to say that we've solved all of it, but we're doing pretty well in our compiler right now. One of the things that Andrews was talking about before,

in addition to the compiler, we have this language service that's open source and people can play with. And we put that out a couple of years ago, and people started doing things like adding support to Eclipse. More recently, there's been a plugin for Atom. The TypeScript team has written one for Sublime. And it's kind of neat that this thing is kind of proving itself out in a way. We're sticking it in all these text editors and IDEs

and getting a nice, rich experience out of it. But so some of the stuff we do in the compiler is is we've actually learned a lot over the years from from say functional programming if you look at how our compilers is built internally it very much relies on immutable data structures and incremental updating of immutable data structures we also strangely in the compiler itself, we generally don't use classes. The compiler is just written as a whole bunch of nested functions and interface declarations. So in that sense, it sort of uses the other way of coding in JavaScript, where you write

functions and then functions return objects that contain function pointers and you make closure over local state and so forth. So our entire type checker is a single function. And that function just returns out a callback interface that you can ask questions on and then it'll lazily go about its work. But it's one single function closure. And if you want to have three type checkers, that's fine. You call the function three times. Now you have three separate type checkers that are maintaining their own separate state internally.

So it's interesting in that sense. But I will say, too, that when we talk about JavaScript, the good parts, that is one of the very good parts about JavaScript is that Brendan got it right when it came to functions and closures and sort of the functional aspects of the language. Then there are other things that are not so great, but that is a super great thing. And it really does work very, very well. And now with the VMs that have gotten good at optimizing that as well,

it is a remarkably productive way to go. I'm really enjoying it. I'm sitting here listening to your knowledge here, and I'm going to get a little bit upstream and perhaps a little bit meta because I'm thinking about our universities and the things that we're taught, how to write a compiler at university. And how there are very few people who have the skill set and experience

to retool a compiler in their free time and have a 5x speed improvement. And no doubt, Anders, that was based on years of your experience of writing compilers. How do we institutionalize some of this knowledge that few people have? How do we pass it down to the next group of people who need to be writing compilers 10 years

from now, 15 years from now? Have you put thought into that? Is it just too hard of a problem? Is there something else we can be doing? Well, I think that the best thing that we possibly could do is open source, right? I mean, and that's what we're doing. Yeah, good point.

Source build for this compiler, hey, you can have it right now. Just go clone the Git repository, and there it is. And it's not very – I mean, it's 50,000 lines. That's not – I mean, it's a lot of lines, but it's not that many lines. You can find your way around in it. You can see how it's done. I was just going to say the same thing. Reading code and talking through code with people that are knowledgeable,

you can't get away from that. And because it's open source and you have these communities, maybe we supplement the formal education with, go work on this open source project and contribute to it. Yeah, I think that's a very meaningful way to do it. Yeah, because that will force you to actually understand how it works such that you can contribute, right? Well, not only the technical side of that, too, but also the community side of that. Like you said earlier, it's a culture. You said there's open source and there's the real open source way. I think part of institutionalizing that, Jared,

as we're talking about in contributing to open source is not only getting the code right, but also interacting with the community of what the community needs from what you're producing. Yeah. Well said. Well said. Well, let's pause here for our sponsor break. We're going to get back to adoption and why we've had all of these large projects adopted. And then we'll talk European region in Frankfurt, Germany, the first in Germany. FRA1 is now open. The new region features their latest cloud spec and the full range of DigitalOcean features

including metadata, CoreOS, and IPv6. Something else that's cool is due to its placement on the German commercial internet exchange, which is the largest internet exchange point worldwide by peak performance, this region will serve Germany and its neighboring countries with unparalleled connectivity and speed. The story of the German startup community is tremendous, and DigitalOcean is hoping by launching this new region, they can play a part in supporting the innovation and awesomeness that's happening in Germany.

So definitely check out FRA1. For those subscribing to DigitalOcean for the first time, use our promo code CHANGELOGAPRIL or CHANGELOGMAY to get a $10 hosting credit when you sign up. Head to DigitalOcean.com to get started. And now back to the show. All right, we are back talking TypeScript. There has been a few large projects that have announced

that they will be TypeScript in their next major releases. The biggest one being Angular, which will be Angular 2, will be written in TypeScript. And then also Dojo 2 will be written in TypeScript. If you guys had to guess or if you had some insight into why now, and maybe even some insights into if you were involved at all in the Angular decision or if that was completely on their end. I'm interested to hear how it's taken a few years,

but maybe what's led to the increase in adoption lately. I can take that. I'll try to take a stab at that one. All right, so I think one of the things that we've seen in the last six months, now that ES6 is becoming close to ratified, is this excitement in the community around ES6. Like, it's at the point now where it's deafening, but six months ago, like the movers and shakers were looking at these projects

that could be done with ES6. You've got modules, you've got classes, you've got a new way of writing JavaScript that just wasn't possible before. So as a library author, when you're thinking, what is my API going to be like six months from now or two years from now? What is the new set of libraries that are going to be built look like?

And I think as a library author, you want always to be at that edge when you're showing that, yes, we've got all this stuff. There's no reason to go on to something new. We can do it here. So I would say that that's probably what started kicking off people thinking about what does the API look like now that ES6 is getting a lot of traction. there's a lot of interest in making sure that the APIs fit really well with that. As far as TypeScript, I mean, TypeScript has been there

kind of building up, like we've been saying since 2012, we've been slowly building momentum and beating on this drum of like ES6 is great and you can get that plus some good tooling. Last year when the Angular team announced AdScript at the NG Euro conference, they were talking about, yes, having ES6 is great, and having types is great. And then they also wanted this separation of concerns idea called annotations.

And after they announced that, we kind of reached out to them and said, well, that sounds great. Let's talk about that. So me and Anders and some of the engineers flew down and talked to them and said, you know, what can we do? Like, can we just take our ideas and kind of merge the philosophies and come up with a TypeScript that's even stronger and capable of working with these really rich libraries. We've been working with the Angular team for about six months now. It was great, actually. Getting in a room together, you very quickly discover you're all just engineers. You really all think about the problem the same way and that you have the same values.

For them, Ty types is very relevant. And ES6, for sure. We sort of had both. And there were some things we didn't have, like annotations. And so we worked with them on that and pulled in some other folks from the JavaScript community and came up or hitched on to the decorators proposal for ES7. I worked with Yehuda Katz who does Ember and Rob Eisenberg

that did Durandal and is working on a new project called Aurelia and tried to get everyone thinking along, okay, what does this separation of concerns feature look like? Some people are coming up from a metadata point of view, like annotations, some like Python point of view

or decorators. Can we make a single thing? So that's been an interesting challenge. It's nice to see everybody coming together. One of the things that I was really bullish on a few years ago was the WebKit project and just seeing people, I guess a political term, stepping across the aisle. Microsoft and just seeing, you know, people, I guess, a political term stepping across the aisle, you know,

Microsoft and Google here working together on TypeScript with Angular seems like a lot of good can come out of that. Yeah, no, I, I, I, I'm certainly hoping, I mean, so far, I think a lot already has come out of it. Yeah. But yeah, absolutely. It's been a great, it's good. It's good. It's a great team. come out of it. Yeah. But yeah, absolutely. It's been great. It's good. It's good. It's a great team.

They're fun to work with. They're super fun to work with. And it's been a lot of learning experience because we've been coming up from two different angles and can sit in a room and talk the same language. It's cool. I like the point you made there, Andrew, about just the fact that you're all engineers. You're all people in the end. And even going back to your comment earlier about the commitment to open source and doing it the right way that way,

I mean, when you take your flags down and you're talking about just open source and general to the world, you kind of have to be, like Jared said, stepping across the aisle. You can't let your badge sort of stop you from committing towards the future of what's good for the source code.

Yeah. It's kind of something that Yehuda said last episode, 151. In fact, you mentioned Yehuda Katz. We had him on last show. He was talking about Rust with Steve Klabnick. And I had mentioned that Rust is a Mozilla research project, and it is. And he made the point of saying it is a Mozilla research project, but Mozilla embraces the open source model

and they've done a really good job of making it a community effort. And it's not all about Mozilla. It's about an open source project that will forward the goals of Mozilla as well as the goals of perhaps their competitors. But the entire ecosystem, and we have to come together around these projects and everybody benefits from it.

There's also benefits from competition as well. So it kind of goes both ways. It's nice when people come together. It's also nice when they compete heavily. We can kind of win in both scenarios. So let's talk about getting started from a layman's perspective, not with the Angular team or the Dojo team, but let's just say I'm just writing my own JavaScript, I'm an application developer.

Maybe let's take it from the Microsoft camp as far as tooling goes, and then maybe in the Node camp as far as tooling goes. How do I get started with TypeScript? So if you're a Microsoft developer, probably the easiest way is just to install Visual Studio. So starting with Visual Studio 2013 update 2,

TypeScript has been in the box. So you start up an application and you can immediately start up a TypeScript application template and go from there. If you're coming at it from an open source point of view, you can npm install TypeScript

and use the TypeScript compiler straight from npm. Of course, it's all JavaScript. All this TypeScript is compiled away and we've got JavaScript. So you could, if you wanted, you could just clone the repo and run the TypeScript compiler straight

from the clone repo. You'll have the most bleeding, up repo and run the TypeScript compiler straight from the clone repo. And you'll have the most bleeding, up-to-date TypeScript. I will say, too, that one of the things, because we focused really hard on making the language services open source, we now have a number of really high high quality plugins for all of the popular editors out there. So if you're using, say, Sublime Text or Atom.io, then there are excellent plugins for those editors. There are plugins for Eclipse. JetBrains has very good support in WebStorm for TypeScript, and they're actually keeping up with all the evolution in the language.

And they offer a number of great refactoring tools in there as well. So by and large, I mean, there's remarkably good coverage for TypeScript across the board in development tools and IDEs. And build tools like Grunt and Gold. As you dig into whatever your favorite flavor is, you can find a growing number of TypeScript plugins for these various systems. We should mention, too, probably one of the biggest treasure troves of information for TypeScript is a GitHub repository called Definitely Typed. I don't know if you guys have looked at it, but

this is something that happened entirely organically in the OSS community, and it so warmed my heart to see it happening, too. People very quickly, after we shipped the first version of TypeScript realized that, wow, I can actually go write these declaration files for existing JavaScript frameworks and then get a much better experience when I'm using the framework in TypeScript. And we provided some rudimentary declaration files for jQuery and

Node and a few, I think, Backbone we had a little bit. But it wasn't a lot. And then, of course, we've written down all the type definitions for the JavaScript runtime library and the HTML DOM. But that was really all we had in the beginning. And now we have this repository that is, I think, now close to 1,000 frameworks. I kid you not, 1,000 different frameworks have pretty good coverage. And some of them have very, very high-quality definition files up there. And there are provisioning tools now like TSD that allows you to just say, hey, today I'm going to use jQuery with Ember and this one or that one, just like NPM. It'll provision your project with all the correct declaration files. And lo and behold, you get super high quality statement completion as you're authoring your code, you know, just magically.

And it's fantastic. And that's entirely a community effort. And I just think that is like that truly speaks to the power of open source. There is no way that a single entity could have done that. That is something that only a community can do. Having written the jQuery one, that took me weeks. Yeah, that's spectacular. We'll definitely link that up in the show notes.

And you said it well there, Anders, that this is the kind of stuff that happens in the open source community. You just couldn't have predicted it. You didn't have to ask for it. Somebody wanted it. It was a good idea. And everybody just starts pitching in into their little wheelhouse. If you're into Sammy.js or you're into Beatcry Crypt or whatever you happen to be into in such a huge JavaScript community. You just play your part and then you have this great community resource.

Spectacular. Exactly. So what about learning? So that's how you get technically started, but what if I don't have any idea what type annotations are or I want to learn how to write them? Where do I go for that? So there's a couple of resources on the website that you can use to get started.

We've got some samples. So if just staring at code is the easiest way for you to learn, you can go and there's a sample section on the website and you look through that. And each of them are fairly small examples of using Node or using jQuery, just enough to kind of get you started. There's also a handbook. The handbook tries in plain English, as best as I've been able to write plain English, to walk you through the various features and the 1.0 language. And we'll be kind of revising that here shortly to kind of pull it up to date with the later versions of the language. But if you read through that, there's tons of examples, tons of plain text to kind of understand.

Maybe to call it the spec, if you are the kind of person that really likes to dig into the details, there's the TypeScript spec and you can read that and really understand it in a deep, deep level. Speaking of the spec, I noticed that it was in a PDF. Is that spec ever going to be open source on GitHub, or is it already open source and this is compiled from a

repo or something? Well, it's available in three different ways, as a doc file, as a PDF file, and in Markdown. So it's on there. If you just go to the front page on our different ways, as a doc file, as a PDF file, and in Markdown. Hmm. So it's on there. If you just go to the front page on our GitHub site and then there's a link to the language specification, and that's a Markdown, a single

Markdown file. Okay, gotcha. I'll leave that up then. Yeah. So next up, let's talk about the future a little bit. You have a roadmap on the website that you told us about. Maybe you could kind of just verbalize the roadmap a little bit. You have a roadmap on the website that you told us about. Maybe you could kind of just verbalize the roadmap a little bit and tell us where TypeScript's at as far as, I think we are at a 1.4 release and 1.5 is in alpha or beta, and then kind of what you guys

see it going to next. Sure. So the 1.5 release is going to close a lot of the gaps that we had in ES6 compatibility. I think after 1.5, there's only a couple of features left, class expressions, generators, that we'll need to add to kind of finish up the ES6 compatibility. So that's kind of a nice milestone for us to actually be able to say, yes, we are a superset of JavaScript, and that superset is a superset of ES6. We're looking at ES7 features. Anders mentioned async await earlier. That's going to be fun for kind of the promise programming style to be able to have nice,

clean async await code. We've been talking more recently about things like JSX and exploring JSX support. There's a pull request now that people want to kind of hop on and help out and give us their feedback. We would love that. So definitely do that. And decorators is another one. Yeah, so basically we're like 1.4 is the version that's out there now. 1.5 is imminent, you know, within a month or two.

We plan to ship that. 1.6 will be the one that rounds out a few more of the missing features. And then finally, 2.0 will be done with ES6 and the ES7 things that we so far have on our roadmap. But then I'm sure by then we'll have dreamt up some more work. It just keeps on coming, it seems. I know that we're talking now about doing something around module bundling also to make it easier to consume ES6 modules in a browser environment, which today requires you to use an external module loader.

So there's a ton of stuff we can do. And we can, of course, always do more IDE features. And so there's no shortage. Yeah, exactly. I mean, one of the things with the JavaScript committee is that they're now on a one-year cadence. So every year, they're going to revise ECMAScript.

So ES7 is next, and ES8 is the following year. We're going to be busy just keeping up and being a superset with a nice, rich type system and tooling that builds on top of that. So is it fair to say the type system is pretty much done

and now it's just going to be in maintenance mode and now it's just keeping up? Or is there additional things that you can do to make the type system better over time as well? Oh, no, there are definitely things we can do to make the type system better. You can always make type systems better. I mean, we were talking with the Flow guys

about union types and they're like, great, if you have an if statement and then you check what the type is in the if statement, you know in the body of the if what the type is. And as we were brainstorming with them, we're like, well, that's a no-brainer. Let's throw that in there too. So as people do explorations, I think

the type system is just as organic as the JavaScript language. It's going to grow and kind of incorporate patterns and whatnot that we can. Yeah, we're sort of always on the lookout for because such a JavaScript language is going to grow and kind of incorporate patterns and whatnot. Yeah. Yeah, we're sort of always on the lookout for, you know, why did I have to put a typecast here? Why did I have to have this annotation?

Or, you know, is there a way we could get rid of that? You know, so is there a way you could capture this pattern or this idiom, you know, in the type system so we could better, you know, sort of understand it without you having to annotate anything. So that's going to be ongoing. Plus, you know, whenever a new feature is introduced in the language, we have to sort of work out the type theory behind that feature, right, and get that integrated into TypeScript. So there's always that angle to it as well. We've got 1.5. It's in alpha.

You just announced that about 20 days ago. You got your roadmap, which is, I love your roadmap too, by the way. It's great that how it's linking out to issues that have commentary from you all in the community sort of feeding back into this. I think that's a really great way to line out a, a road, not, not just a straight up text,

but when we're talking about the roadmap and future versions of TypeScript, what are we, let's have some fun and hypothesize each of you towards what the future of TypeScript might, might be. Where would we be at any year? What would we be talking about for TypeScript? Well, I mean, I, I, I mean, I'll be a little bit pedestrian. I still think we're going to be talking a lot about ES6, and we're going to be talking a lot about modules, because ES6 isn't quite done when it comes to modules.

You know, they've specced the language syntax, but they haven't actually specced the underlying runtime loader semantics. And so there's still a whole bunch of gyrating going on in the community around that right now. I think some of the new ES7 features we're going to be looking at, we're going to be looking at different development tools to integrate with, maybe deeper integration with build systems and sort of this whole cycle of I edit something and now I click on my browser and I want to see the result over there and shortening ephemeral as possible is something that we're going to keep iterating on for sure. Are there any particular adoptions of TypeScript that you're looking forward to? Is there anyone out there that is a perfect candidate for it that if they were listening to the show right now, you would put them on your radar essentially to say, y'all should adopt TypeScript. Well, I think, you know, anyone who has more than, say, 10 or 20,000 lines of JavaScript in their app really owe it to themselves to take a look at this because it really is a time saver. I will say, you know, like just, you know, the project that we work on daily,

which is the TypeScript compiler itself, but in a sense, it's just a large JavaScript app, right? It's a 50,000 line JavaScript app. I shudder to think what it would be like to write that without types. I don't, I can't even, I mean, I can't even imagine. I mean, because we refactor that so much, right? And that's what gives us our agility and the ability to keep up with all of these features and these new things that are happening. It's like that you can trust the system. You can go, okay, well, now I'm going to refactor this class or this interface or this function into these two things, and I'm going to rename these properties, and boom, boom, boom, done. And now I get all this time back that I can use to creatively think about the problem instead of doing the manual labor that it otherwise turns

into, right? And to me, that is just like, that's just bread and butter. I mean, you just got to do that if you want to stay competitive, you so yeah we have a few closing questions i share with you all via email that uh we got several but we're only going to do two today um and the first uh we could take turns and we could start with you but who is your programming hero yeah jonathan and i were actually we're talking about that at lunch. I think, you know, if I have to think back on my career and who had the sort of biggest impact and launched me into this whole thing, it's probably the inventor of Pascal, Niklaus Wirth, who I was fondly recounting. And Jonathan knows the book, too. His book called Algorithms Plus Data Structures Equals

Programs. One of my favorite computing books. I remember reading it cover to cover and understanding every word in there. It just made so much sense. It is so simple. That's how I learned about hash tables, which I didn't know about when I first wrote the first version of TurboCascal. And then I read about these things called hash tables. I'm like, wow, that, what, really? And then I went and implemented it out of a compiler, went twice as fast and I'm like, awesome. To me, that was good stuff. And his career has been amazing. He's had a huge impact on computer science

and on my career. Wow. What about you, Jonathan? See, he took my answer. Did I really? Oh, I'm sorry. No, it's fine. It's fine.

When we were talking at lunch, I was like, you know, Klaus Beard is like one of the guys that really stuck to his guns and said, look, simplicity is important. Programmer productivity is important. Don't complicate it. Put them as close to solving their problem as they can and let them rip. And that's why Pascal is so easy to implement as a language. So writing a compiler for it is really easy, but learning it is really easy.

And his thoughts, he never left that left that as he made each one like modular and over on he was still always all about trying to find the simplest way to solve the problems and i i you know whether or not his particular aesthetic is something that that really fits you know you like i just i just have to respect his philosophy and what he brought. Someone else that I like because he's entertaining is Simon Peyton Jones. One of the inventors of Pascal. He's really fun to listen to, really fun to get excited about what is possible in programming languages. I always fall back to him sometimes.

All right. We got our last question. Bringing it back to TypeScript here, I guess, is you either answer it together or individually, whatever makes sense, but it's pretty simple. But I guess we may have answered it to a degree, but how can the community listening in? So, Anders, you answered it. Anybody who's got 20,000 lines of JavaScript needs to look at TypeScript. But in other ways, how can the community step in and either take part, do something with it, or help out with TypeScript? How can the community begin to support and show support back to you all and move the mission forward?

Well, I invite anyone who cares to come join us on GitHub and put up poll requests and speak up on issues or post new issues or new requests for features. That's a great way. We are all up there. We live and breathe our daily programming lives on GitHub. So we're very easy to reach that way. And there's all these community stuff, like Andrew was just talking about, definitely types.

Get on there. If there's a library that you love that you don't see, or you know there's little errors that you can fix, I mean, it's going to be trivial to fix the DTS file. You just go in and say, oh, no, the type is actually this, not this. And you're going to help yourself and others, all the editors and whatnot, just using these tools and sending feedback

and making even better tools, I think. Anything in the roadmap that somebody can take part in? I know 1.5 is an alpha now, but you have things like expose a new editor interface to TS server. Is that something that is better served by the core team or better served by those that can... Are you looking for

adoption, support, growth? Where can people... I guess, is that a good place to look at? I think both. I mean, I think it is whatever strikes your fancy. If you have an editor that you're implementing and you have a plug-in model for it or you have a favorite editor and you know how to write plug-ins for that editor, maybe write a TypeScript plug-in and try to use our new

TS server infrastructure for that, which is what we used for the Sublime plug-in, for example. Or if you're interested in compilers or IDEs or whatever, come to the other side and help us out with your favorite feature. If you're interested in programming language design,

one of the things that we've done in the last year or so when we moved to GitHub was we put all this programming language design we were kind of doing behind closed doors. We're like, enough. All of it goes on GitHub. So all the language design is now done on issues in GitHub

and you can jump in and kind of give your two cents on if this feature fits with the kind of problem space or if there's little gotchas and you realize what the gotchas are and you can let us know. It's all kind of out there for people to comment. I noticed when I was looking at one of your, actually the TS server one that you mentioned, the issue out there,

you have a label of CLI or CLA not required. Is there a CLA required at some point? Yeah. So there's when you contribute code to the TypeScript code base, you sign a contributor license agreement, and there's a little robot behind the scenes that it's checking all the pull requests coming in. We're trying to make it a little less noisy than it being on every single

pull request. Something else we talked about, too, I believe it was with Go. When I was talking to Andrew Durand, he was talking about how they – let me go back to my notes on that one. They're using a particular external feature. It's called Garrett, G-E-R-R-I-T-T, I believe, or IT. And it's an external code review system that kind of builds into a CLA thing because they have a special CLA for contributors. So yeah, probably have similar problems.

You can look at that, listen to that show or talk to Andrew. Well, that's it for the closing questions. I think, you know, we zoom back out. TypeScript seems really neat because it's something you can begin using today without having to really fully adopt it and sort of inch your way in as you get more and more courageous into the TypeScript world.

So pretty exciting to have this conversation with you guys. Is there anything else that you want to mention before we tail out and close the show? No, can't think of anything. I think we covered a bunch of stuff here. I really appreciate the opportunity to be on the show here. I think this was... Are you guys on Twitter?

Where can people follow you at? Oh, yeah. No, we're both on Twitter. What's your handle? My handle is ahilesberg, A-H-E-J-L-S-B-E-R-G. And mine is at J-N-T-R-N-R. And there's also the TypeScript project has its own at TypeScript link. So feel free to follow those or ask us questions through Twitter.

Good deal. And one thing, actually, now that I have time to kind of ask your audience, if there are people in the audience that are big TypeScript fans or big TypeScript users. Recently, we just started putting little logos on the TypeScript website to kind of show off all the people that are TypeScript fans. The badge collection. Yeah. So we're trying to kind of show off, you know, here's our showcase. So if your project or if your company are big TypeScript users, let us, you know, let us put your logo up there and kind of show off that you're doing

all this TypeScript. Awesome. That's the friends of TypeScript. If I'm correct. Awesome. Well, definitely a fun having you guys on the show today. I know we had several conversations earlier to get this show on there and

I'm glad it finally worked out to get timing there. We had spring break and we had several things so finally got you guys on the call today. In the future for listeners of The Change Law we have a show planned to talk about 17 years of Curl with Daniel Stenberg and we're also going to

have that conversation on Roots and Bedrock. I was sick this week. You're listening to this in the future and I'm talking about it in the past but long story short i was sick so we we don't actually have a show that uh that we shipped for roots so there was a a break there and we had to touch for a show instead so uh thanks to the sponsors and thanks to all you for listening and uh with that fellas let's say goodbye goodbye goodbye bye you