The Pragmatic Engineer - TypeScript, C# and Turbo Pascal with Anders Hejlsberg

Transcript

0:00 · Why was it called Turbo Pascal?

0:01 · Cuz it was fast. This was when Audi had their quattros and their turbos. And this thing was fast and super interactive.

0:07 · When you started out building C#, what were your design goals? We knew we wanted to build an object-oriented language. We wanted manage code or bite code so we could target different runtime environments. We wanted garbage collection and exception handling, but also things like a unified object system. What do you think made Typescript this popular?

0:26 · Absolutely.

0:26 · Because of the better tooling. We were totally right there that adding an erasable type system and then using that to enable great tooling is where the productivity boost is realized. What is your take on either modifying existing languages for AI usage or coming up with a language that is more suited for AI agents to use?

0:46 · Well, my flippant answer there is Anders Hellsburg is one of the biggest living legends in the tech industry. [music] He created Turop Pascal, Deli, C#, and TypeScript. The impact he has had on programming languages and developer tools is immense. Today with Anders, we discuss how C might have not been born if [music] it was not for the Sun versus Microsoft lawsuit over Java.

1:10 · The behind-the-scenes story of TypeScript and why open sourcing it was [music] a huge deal inside of Microsoft.

1:14 · What he's learned from 40 years of designing languages, including why IDs and programming languages go hand in hand, and [music] many more. If you want a behind-the-scenes look at how three of the most used programming languages in history got built and how AI might change our usage of programming languages, this episode [music] is for you. Before we start, I'd like to introduce our presenting sponsor for this season, anticys. A definite trend that I'm seeing across the industry is a lot more focused on testing, unsurprisingly, thanks to AI. We know that software is hard to test. And we also know that AI is making it worse thanks to producing increasingly more code and more complex code. The bottleneck is becoming reviewing the code, testing it, and trusting it. Or is it? We tend to think that code reviews are the bottleneck because you cannot scale human reviewers with token spend.

1:58 · But the problem actually goes beyond code review. Really, it's about verification. We know that AI cannot verify itself. To verify the correctness of AI generated software, we would need to catch issues that traditional tests miss, including issues that we did not even think of in a codebase that is changing at superhuman speed. Oh, and we need to do all of this before deploying to production. The only way to verify that software works is to run it with realistic faults. And this is exactly what antithesis does. You can bring the system you work on under test and verify that it works as it should. Teams at CD and Jane Street are doing just this. And I'm also starting to use antithesis to test real world systems. Over the season, I'll be sharing a lot more on how it works and how it can help verify that a system is buck free. In the meantime, check out antithesis.com/pragmatic to learn more. Anders, welcome to the podcast.

2:50 · Thank you.

2:51 · It's brilliant to to meet you. You've created so many widely used programming languages, including the one that I I learned first to program with Turbo Pascal. How did you get into programming? Well, I was lucky enough to attend a high school that this is back in Copenhagen, uh that offered students access to a computer. It was one of the first high schools in Denmark to do so.

3:14 · And we're talking, you know, mid to late '7s now. And I sort of got bitten by it then, you know, just this idea that you could program this machine and make it do things. And, you know, the wonder of figuring out how it was put together. Of course, it was like completely ancient by modern standards standards. It was like this HP 2100 with 32K of FID core memory. You could literally open it up and see the fite cores. I mean it was it was amazing you know paper tape uh reader and uh you know and then we got a 1 megabyte 14in hard drive and that was just stateofthe-art. The bootloadader was on paper tape cuz there was no ROM in the machine. So so it started up and knew nothing and so you had to type in the instruction sequence to load the bootloadader that would then load the OS um off of the the hard drive.

4:05 · And as as a kid what did you start to program on it? What captured your imag imagination? Well, this this was a Hula Packard. So, it had forrren, which I found to be very quirky. It had a very slow basic uh interpreter, but then it had alcohol, Hula Packard's version of alcohol, which was an interesting compiler implementation because it didn't support recursion uh which is kind of bizarre. you know the call instruction of that machine would store the return address in the first word of the sub routine and then just execute and then to return you would jump to that indirect through that word. So if you called yourself you'd just be gone forever you know so and of course there were no debuggers or anything to help you figure this out. So you just had to be real careful uh about which algorithms you used. But but it was it was compiled in machine code and they ran you know and it was like you could build games which is what we mostly did like lunar landers and what have you kind of thing right? So yeah it was fun.

5:02 · Back then things were so simple right you could see all the way to the bottom. I mean it it there was just no no layering and nothing. It was you right on top of the hardware. I guess you needed to you needed to see all the way to the bottom as well pretty much right back then.

5:17 · Well, I mean you you it was just so simple that you you could right and that was the beauty of of those early and that was true with the 8-bit micros and even you know the early PCs and whatever right and then we've just added more and more layers over time. We have a lot of layers right now. That's for sure.

5:34 · We do.

5:35 · And how did you go from building games to actually building your first ever compiler? And what was that compiler?

5:42 · I started in 79 at the uh Danish Technical University. At that time also, you know, this was right when 8-bit micros were starting to become available.

5:53 · 8 8 bit microprocessors, right?

5:55 · Yes.

5:55 · Exactly. And you and it was usually these kits that you bought that you had to solder together yourself and then of course they didn't work and then you have to figure out why they didn't work.

6:03 · So you you you learned a lot about the hardware too. and I bought uh a British Z80based kit computer called a NASCOM um and started learning assembly programming on on that one. And then I also met with some college buddies and we ended up founding a company and we had the first computer store in Copenhagen where you could walk in and buy a computer, one of these kid computers and later we sold Apple twos and big 20s and Commodore 64s and blah blah blah, you know, all all of those different ones, right? TRS80s. So I did a lot of programming on those and found that programming was really the thing that I enjoyed. And of course they all came with Microsoft's ROM basic um and which was slow but it allowed you to write programs. Um but I always like missed having a real programming language uh something like Algo Gol or that I had been taught right and then my my buddy the guy that I founded the company with he was like well there's this new thing called Pascal you ought to check it out and it's it's even supposed to be simpler than Algo which was which was actually true of every language we had created. they got increasingly simpler as time went on.

7:14 · And Pascal was not that hard to implement. And so I got interested in trying to do that. Um, and then wrote a little compiler that fit into a 12K ROM um, that would compile a subset of Pascal and you could then yank out the Microsoft ROM basic and stick in our ROM instead. And then when you booted your machine, you were in this little environment where you could type in Pascal programs and run them. And that was sort of the early precursor of of Turbo Pascal, if you will. Many years later, you joined uh Borland and I think it was in 1989. And there you created Turbo Pascal, the programming language, but also the IDE, right?

7:53 · Well, there there's a little more to that story. Uh in that company that we had back in them, I ended up writing eventually a a full implementation of Pascal for 8 8bit CPM80. And then we ended up doing a joint venture with Borland, which was also a Danish company was originally founded in Denmark. And we we made a royalty contract where they would sell our compiler uh on a royalty. And that's how I got involved in Borland. And we shipped that first product in 83, the first version of Turbo Pascal. Um and then that took off more than more than any of us had expected. And eventually that ended up being the thing that I did full-time.

8:36 · Why was it called Turbo Pascal? I understand you added things on top of Pascal that was there. Well, I mean it was it was called Turbo Pascal cuz it was fast back then. Turbo was like this was like when Audi had their quattros and their turbos and whatever, you know, turbo just meant fast, right? And this thing was fast uh and super interactive, right? And so so Turop Pascal it was when Turop Pascal became big was it big just because of the compiler or also there was an ID a dedicated ID for for Turopas Pascal right yes yes that was always the idea and that that goes back even to the predecessor of Turbo Pascal this idea that it's not just a compiler it's an experience right I mean you don't just compile your programs you also edit them you also run them you also debug them you also have a runtime library. It all has to like fit together. Do you know what I mean? And so Turbo Pascal was always about building that whole cycle and try to make it as interactive as as as basic was as an interpreted language, right? But giving you the performance of a compiled language and the better, you know, semantics and syntax of of of of Pascal versus Basic. And so that was sort of the the idea from from day one, you know, focus on the the whole cycle.

9:56 · And so when you were building the compiler, you were already thinking of ways that the IDE, for example, could make sense or could have helpful features for maybe that editing or debugging for example.

10:08 · Oh, absolutely. [laughter] You know, the the first versions of Turbo Pascal didn't have a debugger. you know, you you would just use writ statements and and uh and then then you just see what happened, right? But often if you had some error and and it blew up, you know, with a runtime error, we would print out the address of the runtime error, which is where where was the program counter at that that at that point. And then we had a mode in the compiler where we would say compile but stop at this address. And so the compiler was real simple. it would just produce object code and then once it hit that address it would just say well whatever I'm syntactically looking at right now that must have been around where the error was. So that was like how you could go to the line where the error had occurred. Do you know what I mean? It's it's not like we had like line maps or debuggers or any of that stuff. We just had the compiler and it was just easy to make it stop at a certain address, you know, in the in the object output and then show you where it was in the source code.

11:06 · Why do you think Turbo Pascal was so popular? I I remember back again, this was my first programming experience. It was at schools. It it was outside of schools for production software. And you you said yourself that it spread like wildfire. It was just better than all the competition. It was faster. It was smaller. Um it was more interactive. And it was also cheaper. So it was like 10 times better at a tenth of the price of the of the competition. Right? Compilers back then used to cost $500 and they were just compilers. And then you have to have an editor and blah blah blah.

11:39 · And it was like this whole long- winded cycle of inserting different discs with compiler pass one and two and what have you. And here was this thing that just like made it all go away. And you could get it for $49.95.

11:53 · And for $49.95, I mean, heck, that was worth it just to get the the manuals that came with it, right? I mean, so so there was very little piracy because it was so cheap. Although speaking of piracy, we always had the joke about the the Russian site license, how we sold one copy to Russia [laughter] and then that got copied everywhere. But after Turbo Pascal, you built Deli, which was an even bigger setup in many ways. This was this was now a integrated environment for for Windows development.

12:27 · How did you evolve ideas from Turop Pascal and Delphi? The big thing that happened there between Turbo Pascal and Deli was the advent of the graphical user interface, right? We switched from running DOSs in in text mode to running Windows in in in a guey and that meant a new kind of application, right? uh that you had to create. And at the same time, competitively, Microsoft had created Visual Basic, which was a very impressive product, but still had some of the very same flaws that we knew how to compete with, right? In terms of interpreted versus compiled and extensible versus not or not extensible versus ours that had classes and object orientation and blah blah blah. First we set out to build a visual basic competitor but then we also realized that well that's not really enough of an angle. And then there was this other phenomenon that was happening at the time which was called client server applications. Um and there were a whole bunch of 4GL application development tools for database connected client server apps. And so we set out to build a tool that was like as interactive and rapid application development as Visual Basic, but with a compiler behind it, targeted also at client server enterprise apps. That and that was what Deli sort of was about, right? It worked out really well. I mean that that was a that's that product to this day is still being used actively by a whole number of programmers. I was very surprised when I worked at Skype right after Microsoft bought it.

14:06 · I the Skype application, you probably know this, it was built in Deli.

14:12 · In 2012 or 2013, there was a plan to rewrite it and move it onto something else.

14:18 · That rewrite midway a year in stopped.

14:20 · So, I'm guessing that until the end of of that Skype application, which was decommissioned maybe a year ago.

14:26 · It's amazing, isn't it? I mean the Delpha was is was and is in in in in in some ways a wonderful way of building Windows desktop apps. I mean they had a great you know the the VCL the visual class library that allowed you to inherit components and install them on the pallet and make drag and drop work for your forms designers with components that you had built and whatever. It was it was pretty cool.

14:48 · Yeah.

14:48 · And we already heard the the Microsoft link with with Visual Basic.

14:51 · So you joined Microsoft in 1996. you worked on J++ and then later C. But can you take us back to that moment in time?

15:00 · What was the kind of programming environment like?

15:02 · Well, the environment particularly around the time where I joined Microsoft um the mid '90s, Java had happened. Uh well, the browser had happened first of all and JavaScript but JavaScript no one really paid attention to JavaScript because that was just this little whatever thingy that that was in the browser, you know, and it was slow and it was like ah no one uses that. Uh but then there was this Java thing that allowed you create applets. Oh my god, applet. Fantastic. And run everywhere.

15:30 · Yep. Yep. Ran in the browser and everywhere supposedly. And and and this language that was like simple yet had object orientation and bite codes and like like was platform independent. And I mean it was like everyone was running around with like with their heads cut off thinking this was the end of languages. uh you know, Java is going to flatten the the universe and then then we're all just going to be writing Java and Java applets and that that's the that's it, [laughter] you know, and and and I actually came to Microsoft ostensibly to to be the the architect of Microsoft's Java development tools and and worked on Visual J++ 60 was the the version that they had. Visual J++ 11 at the time I joined which was basically take Visual C++ yank out the C++ compilers dig in a Java compiler and call it good. Uh but it wasn't interactive. It wasn't rapid application development and whatever.

16:27 · And I came sort of with a whole host of knowledge of how to build interactive development tools. And that's what we set out to do with uh with Visual J++ 60. Uh, and we also, of course, knew that, hey, you know, I mean, people are going to be running on Windows and they're going to want to be able to build Windows desktop apps. And so, we built a class library that allowed you to do that. This was uh the precurs WFC, I think it was called, but it was the precursor of of Windforms uh you know, in in in some ways, how did the development of J++ go and and eventually how did it lead to the idea of like, okay, let's do something else, something completely different. Well, you know, development of of J++ went went great until the big Sun Microsoft lawsuit got in the way. Um, and and there was, you know, and that is like I mean, now we're talking like business and whatever. It had nothing to do with with with with with technical, but it effectively meant that Visual J++ was never going to be a product that companies would make a bet on because they full well knew that, you know, you you're not going to you're not going to write your app in a in a language that has been enjoined by a judge in San Jose, you know, or or whatever. And so we kind of realized at that point too that maybe it's not a great strategy to to place your your development platform bet on on technology that's licensed from a competitor and and that in turn along with the sort of dev situation at the time I mean Microsoft's main development products at the time were in two camps.

18:04 · There was visual basic rapid application development loved by everybody you know because it was so easy to build apps right but performance-wise had problems extensibility wise wasn't so great to write new components you had to write them in C++ and whatever and and then we had C++ with MFC and power and expressiveness but really what people wanted was both they wanted something that rolled both of those up right and then They also wanted like modern things like garbage collection that say Java had for example right and exception handling and a more object-oriented componentoriented way of building your apps and and and all of that was part of the genesis that led to tonet and to the C language. So which one was firstn net or car inside of of Microsoft? Well, they were simultaneous, I would say, because we knew we wanted to build a runtime that was language independent because we knew that we wanted to run Visual Basic on it and we wanted a way of running C++ on it and we wanted the ability for other languages to to host themselves on this runtime. But we also knew that we needed to build a language that would appeal to both Visual Basic and C++ users and give you sort of that golden thing in in in the middle, right? And to be frank, something that could compete with Java, right? And so so that's why we we started out building C. And then when you started out building C#, what were your design goals? You mentioned a few things with garbage collection or exception handling, but how did you come up with like, okay, what what will this language be?

19:51 · Well, like I said, I mean, the the overarching thing was this power and productivity of C++ with the ease of use of visual basic in a sense, right? But what it also meant was we we knew we wanted to build an object-oriented language. We wanted manage code or bite code so we could target different runtime environments. We wanted garbage collection um and exception handling but also things like a unified object system where and that's true in in in C like anything can be assigned to an object and if it's a value type we box it but and and it's a self-describing object.

20:27 · So reflection, you can ask an object, what are you? And you can get all of the facts about it at runtime and you can dynamically manipulate it in ways that are just don't exist in in a in a lot of other environments. And we we knew we wanted to go there with that. We wanted a language that made this new model of properties, methods, and events first class because that was how components were built as opposed to just sort of functions and procedures and and and even objects, right? And then we we actually also wanted to to create a language that was standardized. We wanted to give this language to a standardization committee um and try to, you know, level the playing field there.

21:10 · And all of those things were sort of like what was rolled up in in C.

21:14 · You you definitely did it. C# was my first professional language where I I I worked with it I think for about five years and I've I I've seen both the tooling the capabilities of language and I still think to this date in many ways that old version of C was ahead of some languages today in in some ways. So it's very interesting to see how rich that language was when it came out and of course the developer love that followed.

21:37 · But c can you take us back of what did it take to build a language like this just in a more again as software engineers people were listening they're used to building SAS apps backend services you know like like certain projects but we are not familiar with with what it takes to build a language especially something with such large ambitions inside Microsoft you knew millions developers ideally would be using it how did you get to this did you how did you come up with the road map how big or large or small team needs to work on this I think early on we decided that we want to have a team of people design this language not just one I was sort of the guy who ran the group of designers but we put together a a group of six people or so six seven people and we got in a room three times a week for two hours and just started the design you know like literally let's start from the top what is that we all knew what a I mean these were all people who had built or worked on programming languages before, right? And and had seen all of the things you're supposed to do and all the things you're not supposed to do.

22:42 · And quite honestly, language design is 90% the same and 10% new for for pretty much every language. Every language you build still has to have a compiler.

22:53 · Compiler is still built pretty much the same way. And of course, as time marched on, people demand more and more. you have to have idees, you have to have frameworks, you have to have blah blah blah blah blah, you know, and it's all there there's so there's a lot of experience you want to pull in and and there's a lot of work that you're doing that isn't really per se new. Um, but but but every time around you you try to fix the problems that you've been exposed to. This language design group worked together for years on end. And it was lovely to come in to work with a new idea and then immediately have five or six people that you could sit down and have a deep discussion with without first having to spend an hour level setting. Do do you know what I mean?

23:34 · Yeah.

23:34 · Yeah. Um and and and and that worked really really well because because we could just jump right in, you know, and and have two hours of technical discussion and everyone was cognizant of, okay, if someone comes up with a new idea, now it's our job to try to shoot it down. Well, what's wrong with this idea? Do do you know what I mean? And if it could go if it could stand the the test of of that, then it was probably a decent idea. And so so that was kind of how we we we ran the design. And then I I wrote the specification of the language in parallel with our design meetings. And then we had a group that was in parallel implementing the compiler in actually implementing it in C++ or rather C++ minus because we didn't use all of the C++ features, you know, in in that compiler implementation. But it wasn't we it wasn't until the Roslin project that we that we self-hosted the C compiler. and a Rustin meaning that uh the compiler is in C# right exactly yes that was the a project that came later to to build the compiler in itself and also early on you know this is you got to remember back then ID's were not really all that fancy you know I mean we have syntax colorization statement completion was kind of like well some IDs were starting to dabble in it but it wasn't really a norm so we built like in a sense a classic compiler, but then we also built this like mini language servicey thing that that sort of cut some corners and whatever, but could do some rudimentary statement completion and syntax coloring. But in a sense, we had two implementations that we had to evolve in parallel. And over time, that became quite a drag, right? because as we added generics and I added other features and link and whatever and it was like oh my god now now this is like we got to go implement all of these features twice in the in the real compiler and in the language service right and so that ultimately led us to this project called Roslin where we built a single compiler that really is both it's a compiler that can both function as a command line compiler and as an interactive service inside the IDE Typescript is built that same way also and there's a lot of learnings from from doing it that way that are still not being taught in school.

25:57 · There are many useful things not being taught in school even when they are useful to learn about. One of these really useful tools that I must mention is our seasonal sponsor Turbopuffer.

26:05 · Turbopuffer is a ridiculously scalable fast and cheap vector and full text search engine built by an engineering team that I really like. The first time I heard about them was when I was talking with one of Kurser's co-founders about how their vector database could not keep up with the number of code bases that they were adding. This was back in 2023. Cursor did something seemingly risky. They took a bet on what was a littleknown and relatively new product at the time, Turppuffer. But it paid off. Cursor moved their semantic search workload over and Turppuffer was indeed able to handle Cursor's massive everinccreasing load. The reason has everything to do with smart engineering.

26:39 · Turbo Puffer is built on top of object storage with smart caching on MVME SSDs.

26:43 · Cursor's active code bases get loaded into the cache so searches are fast and inactive code bases fade into object storage. Cursor has so many good things to say about Turbopuffer. They cut their semantic search cost by 95% when they switched. They think of Turbopuffer engineers as an immediate extension of their team in Slack. And Turppuffer is one of the few pieces of infrastructure that they have not had to worry about as they scaled. Today, Turbopuffer indexes over four trillion documents for vector and full text search and is used by the likes of Entrophic, Notion, Linear, RAMP, and many others. I'm getting to know the Turbopuffer team, and we'll share more about some of the cool things that they do behind the scenes throughout the season. If you need vector search or full text search at scale, think Turbopuffer. Check it out at turbopuffer.com/pragmatic.

27:27 · When it comes to useful tools, I need to also mention our season sponsor, Work OS. One theme of today's episode with Anders is how he has spent a time frame thinking about developer productivity on a scale that most of us do not. Decades, not months or quarters. Work takes the same kind of long-term view on enterprise infrastructure. SSO, SKIM, ARBback, audit logs, they've spent years getting these right, so you do not have to spend weeks implementing them. That's why the fastest growing AI companies trust work OS. Visit work.com to learn more. And with this, let's get back to building languages with anders. And when you're building a a language as as the your product was, I guess the the language itself, how did you get feedback? Of course, you had the the you already said the group criticized it.

28:11 · Did you have an internal beta testers because again for like a backend service, you would typically have dog fooding, alpha testing, beta testing, and then you go public at some point, but this is not your your average software as a service for sure.

28:24 · Yeah.

28:24 · I I mean luckily we had internal clients. The .NET framework very quickly started implementing in C. They had sort of used a hacked up version of C++ to to implement which was kind of odd because I mean it was like targeting byte codes but not really and so they switched to to uh to C and that helped a lot. Um and then we had other internal teams using it and so we we got a bunch of feedback that way and then we had you know the cycle was not that long right I mean I think we started in late 98 and by the PDC of 2000 uh we had we signed up I mean we basically gave away beta copies right and and got tons of of of of uh of users onto it. Now C# introduced a lot of new features that were net new I think to to programming languages. link is certainly one of them. But one thing that might have been maybe one of the most influential uh parts that other languages adopted as inspiration was the async await uh setup. Looking back, what do you think you got right with this design and and why did it become so copyable across languages like JavaScript, Python, Rust and others?

29:34 · Well, a lot of languages are are built around cooperative multitasking in the sense that they have an event loop that sits and dispatches events and then you know you handle the event and then you yield back to the event handler loop and it all runs in a single thread cooperatively. Right? The problem with that is if you then want to do some longunning work, how do I stop in the middle of this piece of longunning work and yield back to the event loop cooperatively, right? And then and then when my result is ready, then I can come back and continue executing here. Well, in order to do that in in an inverted architecture like that, you have to build a state machine. And state machines are notoriously hard for for people to implement because you got to move all of your state off of the stack into objects. You got to remember where and then you have this big case statement that envelopes your entire logic and it's it's like it's a nightmare to to figure out, right? But the transformation from serially executing code into a state machine that this this continuation processing style uh translation is actually one that you can do in a machine-based fashion. You can have the compiler write the state machine if you introduce syntax that allows you to indicate where you want to yield. And that's what a weight is. Await is basically I'm saying I want to yield here and then when and and I want to yield this promise and then when the promise completes I want you to come back here and continue executing and then the compiler writes a state machine around it and it actually turns it into this big switch statement you know and moves all of the state that survives across the await into something that's heap allocated so it can be brought back and doing all of that work is um is something that compilers are great at. And so that was sort of the idea that we have this new style of programming where where we're using promises or the equivalent of promises and and the ability to yield and then we have callbacks and but trying to write your program in that style that's that's also you know what what JavaScript suffer from a lot right it's like all this callback style stuff and with async await you get sort of the illusion that you're just writing normal sequential code and then the compiler does the the painful transformation for you and that turns out to be really useful. Um, now arguably an alternative way of doing this is to use threads in the OS. But the problem with threads is that they come with preemptiveness and the OS has the ability to preempt you at any point in time and that's not necessarily what you want and and and your UI now you have to be multi-threaded in your UI and all sorts of other problems come along with it. Plus threads are heavyweight and typically not well suited for lightweight tasks like like you could do with async functions. So there are pros and cons um you know like async await introduces this notion of function coloring which is unfortunate where you have two kinds of functions async functions and regular functions and oh the red functions can call the blue functions but the blue functions can't call the red functions and and so that means once you want you know a red function it now all everything above it has to be red and then then so if you want from a sync function to call something async well then you got to turn this function into an async function and its caller has to be etc etc Right. So that's unfortunate and that's why some environments like Go for example has has Go routines and green threads which are really language emulated lightweight threads that kind of do what I'm talking about but but at a much lower cost but you avoid the function coloring. So there is a bunch of different things but but you know but for an environment that already exists like JavaScript or like C and and the Windows event loop and and whatever this this was the right solution.

33:38 · Speaking of JavaScript as as C# was becoming really popular across startups, enterprises and so on. It was exploding in popular games as well. To this date it's very popular with with games development but JavaScript was starting to become more popular. Can you can you take us back to your observations on on how how JavaScript went from, you know, like the the mid90s to this script language no one really took seriously to just exploding in popularity.

34:08 · I think it was sort of a confluence of a number of things that happened in the early 2000s, right? First of all, the the the JavaScript platform execution platform matured a lot like Google did their excellent work on V8 and all of a sudden make JavaScript a fairly performant uh programming language. HTML 5 got ratified and and and we were getting to a point now where you could actually build real UIs in in JavaScript. And there was this device revolution that the iPhone set off and and and all of a sudden we have all of these different form factors. It's not just Windows PCs on the desktop anymore.

34:50 · It's all sorts of diverse devices. But lo and behold, they all run browsers with JavaScript in. Lo and behold, the real crossplatform language isn't Java.

35:00 · It's JavaScript. [laughter] Who would have thought?

35:03 · Exactly.

35:03 · And so the world started opening its eyes to that and and started building larger and larger applications in JavaScript. And we saw that externally but also internally and one of the trigger events was when the um the outlook.com team came to C the C team and asked us whether we would pretty please productize this thing called script sharp. And we go well what is what is script sharp? It's this cross compiler that allows you to cross-co compile C into JavaScript such that you can basically treat JavaScript as an instruction language and and run your C apps in a browser. And I'm like, well, why would anyone want to do that? Well, because then you can get a grownup programming language with grown-up tooling. You can use Visual Studio. You can you can have projects. you can do all of these wonderful things, you know, that you can't do with JavaScript because JavaScript is just this scripting language with with shitty tooling. And we were like, wow, really? Well, gosh. Well, perhaps a better approach would be to fix JavaScript. [laughter] I mean, surely you're not going to be best of breed in the JavaScript ecosystem by telling people to write in a different programming language.

36:22 · Although plenty of people were like remember coffecript and all of these other like languages that targeted JavaScript, right?

36:29 · Yes. So they were a programming language, right? Which generated JavaScript, but it wasn't JavaScript itself. Yes.

36:35 · Yes.

36:35 · They were super popular. I mean like so many different things did that. But JavaScript is actually a pretty decent little language. There are just some things missing. You got to give credit there to Brendan Ike. I mean he he understood functional programming.

36:48 · And Brendan Ike the the creator of JavaScript and he got functions as first class objects right in JavaScript which is godsend and and beautiful but it doesn't have a type system and we knew from experience that you cannot build good tooling without a type system. You can build decent tooling but it's never going to scale. It's never going to scale to large teams because you can't describe your intents in into the code. There's no way of formalizing any of this stuff and there's no way of analyzing it and there's no way of using it in an IDE to give you statement completion and refactoring and go to definition and find all references and blah blah blah blah all of that stuff right that germinated the idea of hey it's we can we could create a supererset of JavaScript that adds a type system and then we could just compile it away but then we have now we have the the foundation for great tooling and then we could build a create tooling on top and actually create a wonderful development experience, right? That was sort of like what we set out to do.

37:51 · When you set out to do this, you not only set out to do this, but you set out for some reason to do it as open source, which took everyone outside of Microsoft as a surprise because old Microsoft under Steve Balmer was notoriously perceived as anti-open source back then with Windows and and C back in the day.

38:10 · Of course, I'm talking about, you know, Microsoft was slowly waking up to the fact that open- source was not going to go away and open source was where developers wanted to be and they were voting with their feet. Yet, there's a collective DNA, you know, that has been trained to pull you in the other direction, right? And and and so that battle was we were right in the center of that and we we full well knew that there was absolutely zero chance that we would appeal to the JavaScript ecosystem with a proprietary programming language uh license from Microsoft. No, no one was going to come. It had to be open source. There was just no two ways about it, right? But getting that off the ground inside Microsoft, it took some uh some pulling.

39:00 · Um, and we paid some taxes. We we did eventually get the okay to do open source, uh, because we had two technical fellows, myself and Steve Lucco, uh, who was the the other co-inventor of of of of TypeScript, insisting that that was what we had to do. And so, okay, there people weren't going to debate that, but but of course, you have to pay the tax and be on Microsoft's open source repository called Codeplex, where exactly no one was. Um and and so we were there for the first 2 years. Um and it kind of was crickets, you know, and it wasn't until 2014 when we moved on to GitHub that things really started to get moving um with with adoption. And also honestly, it it it totally changed our workflow. You know, there's open source and there's open development and and and we were technically open source in the beginning, but it was not open development. we would sort of lop the source code out in this repository and scrape the issues off of that and put it into our internal issue tracker and then you you know but once we switched to GitHub the entire workflow moved to open development also and that I love that workflow and that's we've been there now for over a decade uh and it's been fantastic uh and it's what made the product uh as good as it is just over a decade later so the the language moved to GitHub in 2014. And in November 2025, the the GitHub Octoverse report revealed that TypeScript became the most popular language across GitHub. Outside of the type system, what do you think made Typescript this popular? And of course, we've had other languages, Python being the other very popular one. But what captures developers preferences this well? Well, I think, you know, it didn't just happen overnight, you know, and if you look back at at at that, you know, all of a sudden we we surfaced as number 10 and then we climbed slowly over the years up and and and sat next to JavaScript, right? And of course, if you added JavaScript and Typescript together, then we were already number one. It's just which syntax, were you using type annotations or not? And more and more people over time just decided to adopt that. I mean some it early on we're using JS Dock or or whatever you know and like these types in comments or or that we also supported but gradually I think people just realized hey this is this is the right way to do it and the reason they came I think is absolutely because of the the better tooling and I think we were totally right there that like adding an erasable type system and then using that to enable great tooling is really where the pro where the programmer productivity boost is realized.

41:44 · And I guess this is where we cannot like not mention VS Code which shipped that great tooling also as a free to use for for most people or at least initially for for most people which also made a big difference.

41:58 · Absolutely.

41:58 · Yeah, that's our our sister project which is written in Typescript and so they were one of our earliest adopters uh and that we work pretty closely with them um to this day. That whole interplay that in turn is also what led to the invention of uh of LSP, the language server protocol that now pretty much every tool vendor uses to enable interactive services in the IDE.

42:23 · Oddly, it isn't until this port to go now that we're switching to LSP. We had our own precursor of LSP because LSP didn't exist when we first integrated TypeScript into into Visual Studio Code.

42:35 · But there are a lot of learnings from from that. So it's it's been an incredibly symbiotic and and fulfilling uh experience to build these two projects in parallel in open source and I think it has totally changed people's view of Microsoft in in the developer ecosystem for us developers who again are not as familiar with uh compilers themselves.

42:57 · We of course like I I use TypeScript and I I'm aware that there's some compilation going. Could you give us a brief overview of what the types of compiler pipeline looks like in terms of parts and and what parts you specifically focus on more?

43:09 · Sure.

43:09 · It's in many ways a fairly typical compiler and in many ways not. Pretty much every compiler has you know what's known as a lexer or a scanner that takes text and turns it into tokens. And then typically on top of that you have a parser that takes the tokens, checks their sequencing and then makes abstract syntax trees which is a you know a tree that you can navigate that effectively is a map of of the source code you know but broken into syntactic primitives and checked that you know like syntactically everything is is or grammatically that everything is correct. So those are the first two stages of the pipeline. Um then we have well we have a a one extra pass that we call the binder which is you know once we have the parse trees then we bind symbol information to them where we find all of the all of the declarations of variables and whatever and build symbol tables and attach them to their function such that we can then later look up names effectively. And we also build in the binder we build a control flow graph and I can talk about what what that helps us do. And then we have the type checker which is the largest part of our pipeline. And that's the the thing that checks semantically that your program is correct. It's the thing that figures out types and checks that the types relate correctly and that you're assigning the right thing to the right thing and then that you know that you're calling something that actually exists and and and so forth. And then we have an an optional stage at the end called our emitter. And normally the emitter infrastructure in a compiler is also quite big because that's where you go from intermediate representation to machine code or bite code. Now in our case we just erase types if you will.

44:56 · Well we kind of do two things in in our compiler actually. Early on it was very much about a erasing the types but b also downleveling your your code. So we would take newer ECMAScript features that weren't yet supported by the runtimes for example classes and then we would downlevel them to constructor functions and whatever and so we would rewrite the code and that was a very popular feature early on. Now pretty much every browser is evergreen and you know like Eggmascript features are are are caught up and and so so that's not as important anymore. So our emitter is effectively, you know, a thing that just erases type annotations and spits out the JavaScript code that can run unanotated and also can spit out declaration files which are summaries of of your modules and and so forth. But those are sort of the stages. Now the thing that's interesting about the compiler though is that it's built in a manner that where it can function in a highly interactive mode which is what the ID uses. Normally you know command line compilers they just run through these stages and you know the output is just whatever gets emitted or some error messages right but in an IDE you know the compiler is a service and what we do in that service is we basically take a program that is perpetually broken because you're typing and yet we try to syntactically or semantically analyze it and because we need to know when you press dot here what could what could come next? Well, that means we need to know what is the type of the thing you dotted on. In order for to figure that out, we may have to resolve stuff. We may have to look at a over here and whatever. And all of that has to happen within 200 milliseconds or else people think the IDE is slow, right? Well, what if you have 500,000 lines of code? You can't compile all of those in 200 milliseconds. So, you got to be super super deferred and interactive. And so you got to do minimal amounts of work.

46:57 · And that's how our compiler is built is it tries to frontload like for example like you have 500,000 lines of code.

47:05 · Well let's say in 500 files well we could build the as for 499 of the files and just sit on them. We don't have to rebuild those because you're not editing in those files. We just have to update the a of the current file you're in. So that goes 500 times faster right than than if we had to do all of it. And then we don't actually have to figure out all of the types in here either. We can just start where you're at and then just resolve just enough to answer the question that you're that you're needing an answer for right now. And so everything is lazy and deferred and functional and reusable inside the compiler. And it's a very different way of writing compilers than than what the textbooks will traditionally teach you.

47:50 · Yeah.

47:50 · I guess I I guess this is now these are interactive compilers if you will, right? It sounds like it's it's it's more than a compiler or a lot more difficult problem to solve. The same engine is there but but you got to build it in a in a manner where it can be very interactive and that was not typically important for compilers, you know. And so Typescript is a supererset of JavaScript. What are some features you would try to add if only JavaScript would allow it or if you were able to influence JavaScript's road map? What what is something that you feel could make Typescript a lot better? But of course there's constraint there.

48:29 · We track the Eggmascript committee and and and you know new language features that get developed in Eggmascript we we implement once they reach uh stage three or four in the standardization committee and and then we've sort of been on that train ever ever since the beginning. So there is a pipeline that supplies new language features in a standardized manner. We sort of see it as our purview to define the type system on top. Right?

48:56 · So that is if you will our our playground. Now I still have things that I wish I could have in the language itself. I mean I like functional programming. I like functional programming languages and and key to them is that that everything is an expression. there's really no distinction between statements and expressions. And so one of the the features that JavaScript lacks in my in in my estimate is is the ability to give symbolic names to temporary results in expressions and then reuse them. This is the let let blah equals whatever in some expression that functional programming languages, you know, like camel and whatever all have. And it's nice because you could just stay in an expression context and you can just dot things together and and or whatever and sort of do this more fluent style of programming, but then all of a sudden you need a name for something you want to reuse and now you got to pop out and declare variable or turn it into state.

49:50 · Anyway, you know, that's one thing that I would like to fix. There's there's something called do expressions that may or may not happen at some point, but it's taking a long time. So anyway, but I mean generally speaking, I think JavaScript is a is a nice little language. it just has some issues, you know, and then and I think we're very good at teasing them out with our type checker, right? And so, so once you have a checker that can warn you, hey, you're about to do something stupid here, then it's not so bad. The thing that makes it interesting, I think, and and unlike pretty much any other programming language is the gradual typing. This this notion that you can have types, but you don't have to have types. Other languages force you to type everything, right? Um because they in turn use that information to generate machine code uh you know based on what the type is you know different instructions for float versus int versus whatever where in JavaScript the types or in Typescript the types are there purely for the development experience and the checking.

50:54 · When the program runs they're all gone. Now, of course, there are still types, but they're all dynamically computed.

51:00 · But that's kind of interesting because that means in the language, we don't necessarily have to prove 100% correctness. And a lot of language features that we have, we can't 100% prove correctness. Like in a structural type system with recursive types, there are just cases that you can't analyze because the types are infinitely recurring. the more you try to relate two types, the deeper you go and you're just staring into the the recursive abyss. Do you know what I mean? But you can kind of go, well, well, we've proven it to four levels. That's probably good enough. We're just going to say it's good enough and then, you know, if everything else works out, we're going to go, sure, that you can't do if if you were to go generate machine code that then would have indeterminate behavior, right? But if JavaScript has a runtime where everything is well defined already. So if we're checking 99% instead of 100% well heck that's better than the 0% that JavaScript checked, right? And it gives you like language features that no other languages can provide because they can't get to 100%.

52:06 · [laughter] It's interesting how constraints lead to innovation or even limitations can lead to more innovation.

52:12 · Speaking of innovation, one one of the biggest innovations that is everywhere is the AI agents, AI coding tools that us software engineers, most software engineers are using increasingly using AI agents as well as you're developing languages on on on a more I guess niche team. What kinds of u AI tools are you using or or how is AI helping your language development work? May that be TypeScript or C. Day-to-day I work on on TypeScript and I can certainly talk about how we've been in the process of moving TypeScript to native code for the last year and a half or so. In the beginning of that project, AI was nowhere near as capable as it is now and therefore we could not really use much of it in the beginning. At this point though, I'd say we're using we're using AI fairly well. Obviously, we're on GitHub. We use AI to code review pull requests. that in the beginning was not all that great but now it's actually getting a lot better. um we use uh AI to implement issues or or fix issues, simple issues, and then it succeeds some of the time um in this port that we're doing, you know, because we snapped a copy of the source code from a year and a half ago and then ported it. We have a backlog of PRs that need to be moved on to the new native compiler. And so we're using AI to help us move those pull requests. Um, and that's actually going fairly well at at this point. And then we use it for a bunch of grudgery drudgery work like, okay, here's this feature. Please write me some tests in the same style as these other tests, right? And kaboom. It's like no one likes writing tests. AI loves writing tests and it'll just pump out more tests and great, you know? So, so we're trying to use it to get rid of all the toil that otherwise we would spend our time on, right? But I would say we're not at a point where it absolves us from understanding what we're doing. [laughter] Not at all. No.

54:14 · Well, plus your level at the stack, if you will, because you're building a language, it might argue that someone really needs to understand at least one person. Ideally, the whole team needs to understand those fundamental parts, right? Oh, absolutely. I mean, and and it's language is interesting in the in the world of AI because AI like a lot of like this this conversation, we wouldn't have this conversation if it wasn't for languages because how would AI get to determinism without programming languages, right? I mean, AI is by design stochastic and indeterminate. It might give you a different answer the next time you ask it the same question.

54:55 · either just because random or because there's a new model or there's a whatever. It's non it's not it's there's no determinist yet we can't build applications if they're not if they have non-deterministic behavior. I mean what would a banking app look like if it like decided to hallucinate or or whatever, right? So you have to have something that where the rubber reads the road and where you can reason about and and where you can replicate the behavior every time you run the app. The same thing happens.

55:26 · Absolutely.

55:26 · I mean I even see it in a bunch I think almost all AI agents or tools these days when you ask get it something to do with data often times they will start writing a Python program because I think the AI designers figure it out that you at some point want to turn some non-deterministic into a deterministic and exactly what is exactly the thing that we know most efficient.

55:49 · Yeah. Don't ask it for the answer. Ask it to write a program that computes the answer. and and you will know that that that will be deterministic.

55:57 · Yes. Exactly. Yes. Yes.

55:59 · It's it's very interesting. But speaking of languages for for AI, a question that comes up of course because AI is everywhere is generating a lot more code. What is your take on either modifying existing languages for AI usage based on what you're seeing with the patterns or potentially coming up with would it make any sense to come up with a language that is more suited for AI agents to use? Well, my flippant answer there is, you know, that the language that's most suited for AI is the language that AI has seen the most of in its training set, right? And that's why you could argue AI does really well on JavaScript and TypeScript and Python because it's seen an awful lot of it and there's an awful lot of that still and then and and so and that just reinforces itself, right? and and and you could argue, well, the reason Typescript and JavaScript are are popular, well, that's mostly to do with the browser, not so much to do with AI, right? But it's interesting to look at why is AI targeting TypeScript versus just JavaScript. And there I think the types actually help guide the AI um to to producing better programs. And I think our combination of the ability to type something when there's no context, but also the our ability to infer it when there is context is just the right combination because if you were to force AI to write a type annotation on everything, then it would probably get it wrong more often because now it has to keep track of all these types and re and it and it has to just repeat itself over and over and over, right? And so types are important where there's no context, but inference is super important for for the dry or do not repeat yourself principle, right? And and and fewer tokens generally makes AI more efficient. And so so I think we have a very nice combo there in in how how you can just sort of type the outermost parameter and then everything flows from there on in. Right now, one one thing that AI is already resulting in again for the GitHub team share stats. So, this is also o open data that AI agents are just generating a lot more code. I mean, they're both quick to generate. They also like to be sometimes verbose. uh knowing that we are already seeing a lot more code pushed everywhere and and from at a project level at a at an aggregate level, what do you think language characteristics could be become more important in this world of of just a lot more code often times generated by machines?

58:34 · I mean, you could argue that we we're already past peak truth on the on the on the internet, right? And now there's there's just more and more garbage every every day. it gets harder and harder to sus out the stuff that you do want to include in the training set in order to actually make something more intelligent. So I think that that gradual I mean I'm sure people are working on it. I could see that as as as becoming problematic. Languages that are suitable for AI I I think like I talked about types and inference. I think both of those are important. I think also locality is is important.

59:11 · Locality. Well, what I mean by that is like don't have a bunch of global stuff where AI has to grock the entire pro.

59:20 · Oh, these pound include files that are oh my god. Well, who knows where they're in scope and and how do I put that in the context window or not? and then then do I burn like a gazillion tokens on on trying to include but but if you have good locality where you you're clearly stating what you're importing and whatever and and you can analyze just a single source file and from that extract its protocol to the outside world without having to to know anything deeper do you know what I mean? I think those are important aspects uh just simply to reduce the size of the of the of the context window and also make it easier to summarize each module in a program. Right? This is so fascinating because I remember this was probably 15 years ago where PHP was very much critiqued for its globals and early on I didn't understand as a young developer why that was a big deal. I was I was just hacking around in PHP until I had the issue of something was not working and turns out that something import global and suddenly you realize that when things are defined across the codebase a global could be anywhere and there's no way for you to to know when someone else is doing you're now back to the state problem which you just talked about. Original JavaScript suffered from this problem. There were no modules, right? everything was global and anyone could just like monkey patch anything else and it was impossible to know really what what what what am I sitting on top of here but now with eggmascript modules and whatever we're we're we're moving towards sanity and more and more the world is written that way in the JavaScript ecosystem and that's a good thing and I think that will help us down the line uh with uh with AI AI to it's just starting to to become aware of you know the existence of of of language services and agents today like to use GP and O and whatever, you know, to to find all the places where you reference a certain thing, but it's not semantic search, right? And so so if you have a a common name for this property like count or address or or whatever, right? Well, it's going to find a whole bunch of properties named address and then that that's not going to work so well because now you you don't know that you're renaming the right one, right? But this is where language services come in and and semantic search. Uh and I think that's going to increasingly become more important with AI. And really the these are services that are already provided by LSP implementations, but they may need some tweaking in order for them to be more accessible to AI. AI likes command line tools, you know, and they're not really command line tools.

1:01:58 · And I I also wonder if if for example performance will be interesting because we know that these things can can run faster. So faster feedback loops will clearly be helpful which we're now going back to one of the reasons the typescript was so popular. You said the 200 milliseconds of getting you feedback right but there are ways of you know where where you could imagine you know like a server keeping a project hot and and giving you LSP services you know that AI can ask semantic questions and and whatever and then once AI stops asking after 10 minutes the server just dumps it you know and and whatever.

1:02:32 · There there are ways of putting this together I think where we can make some progress on on because like the ability for AI to semantically validate the code that it's generating as it's generating it will increasingly become important.

1:02:47 · What about the the software craft?

1:02:49 · You've you've you've been in this industry for for many decades but it's hard to unsee that these tools are just coming to everyday use similar to how at some point graphical IDs came before that. uh I guess the higher level languages came knowing that AI agents and AI tools will be part of the craft.

1:03:08 · What do you think parts of software engineer craft will become less important and what might become more important?

1:03:13 · In a sense, we're all turning into project managers, right? Um and and we can have an army of junior programmers called agents that will just spit out reams of code, but someone's got to have the big picture and review all of that.

1:03:29 · And so increasingly our craft is going from one of writing the code to one of of reviewing the code and and building the architecture of the code and overseeing the work if if you will. It's a different kind of craft. It's a different kind of enjoyment. Uh I've always liked writing the code. You know, to me that was the fulfilling part, seeing it work. Do you know what I mean?

1:03:54 · and and and and it in in a in a way AI robs a little bit of that, right? I mean because I I I am less interested in reviewing code, but I think we could also make the process of review of reviewing code much more interesting than it is today, right? I mean, today you see a list of of diffs in alphabetical order and and now it's up to you to to make heads or tails of it.

1:04:17 · I mean, there are more pedagogical ways of of of of presenting that and and you could have commentary generated by the AI that tells you what the changes are and whatever and then tries to guide you along. Do you know what I mean? So, so that symbiotic relationship, I think we we need to work on that more and so sort of to to to keep the enjoyment in there.

1:04:38 · But I think it's foolish to think that AI will just eliminate programmers and then because ultimately that's great, you know, like like vibe coding is wonderful as long as it works. And then the minute it it goes off track, then you're like you have no idea what's going on and you can't convince the AI to fix it. And so what do you do? You can't absolve yourself from understanding what's going on. That that's not that's not programming. And ultimately also, you know, the responsibility for a program does not lie with the AI. It lies with the programmer. You you're not going to go back to the eye and say, "Shame on you.

1:05:15 · Uh, I'm going to fire you." [laughter] What does that even mean? Right? I mean, now you have nothing. you know it's no you need someone to have that that function of being responsible and so so that's you know so so ultimately AI is a tool to enable us to become more productive I think but it will change the way that we write our programs for sure I mean there's no point in in in in sitting there and typing in stuff that AI could type 100 times faster you know having created three very widely used programming languages what have you learned about developers about what they care about when it comes to programming languages and stuff that maybe they don't care too much about and don't even think about it, but you might have to think a lot about. You know, I think at the end of the day, developers care about being productive. They care about being in the zone where they feel like, "Oh yeah, this thing is just clicking for me. It's doing just the right thing and it's like answering me, but it's it's right there. It's an extension of my fingertips." Right? So, for me as a as a language designer, I'm never just looking at the language. It's you're looking you got to look at the whole picture, the whole experience because really what you're doing is you're creating an experience. An experience that programmers will spend the majority of their working life in which is why why programmers become so attached to their tools, you know, and their languages, right? I mean it's it's almost a religious thing which which language you're and which tool you're using and be because it's it's so ingrained in your workflow and and it so enables you to to be in the zone. Right.

1:06:49 · So that I think is the that's the key to focus on and that's what I've tried to do with with the with the the work that I've done over the years.

1:06:58 · And it sounds like this is why from the very beginning you also focus on the IDE the the tool where developers spend their time in.

1:07:06 · Yeah. You can't have one without the other. Well, you can, but but it's just not it's not nearly as effective.

1:07:12 · Yeah.

1:07:12 · One question we're starting to see, or it's more of a question mark, is well, how much are we going to be in the IDE all day versus these new interfaces, which might be agents where you can manage multiple things or command line, which is again just something where we found that agents can work asynchronously, but I think we're still figuring out as an industry of like what what will come next. Yeah, I don't know that we can see the steady state at this point because it's it's it's evolving so much, but I still believe that that programmers are going to be relevant in in in this equation, you know. I I I I fundamentally believe that.

1:07:48 · What about performance and efficiency?

1:07:50 · Early on in your career, you just mentioned that your first computer you had on how many kilobytes it had and how you you fit your compiler into 12 kilobytes, which these days I I cannot even create a text a text file that smaller than that. uh or it's very hard to do, right? But it seems in those in the you know like a few decades ago writing efficient programs was important and over time my perception is that it's becoming less of a focus. What is your take on that and do you think it's kind of fine for us developers to forget about efficiency or we're just allowed to do that because of we have more resources or maybe this will change?

1:08:28 · I think it's a case of it depends. There are certain classes of apps for which efficiency is absolutely key. I mean like the kind of program that my group works on like compilers tooling and whatever. Yeah, people do care. That's why we're we're spending a year and a half moving to native code inference in in the cloud on up against data. I mean oh my god, you know like financial fast trading uh whatever it's all about PF, right? I mean, and the speed of light and like trying to trying to move your trade faster than the other guys. I mean, so so there are lots of places where Perf is king. But there's increasingly also places where where Perf doesn't really matter because, you know, it's so fast anyway that if it even if it's 10 times slower, you still can't detect a difference. And so it's just not worth optimizing there anymore.

1:09:19 · It depends, I think, on on on the kind of app you're building. It's a good reminder that not all use cases are are born equal. I'm interested what is your personal development setup like these days. Well, I'm an old uh Windows guy. I still I still Windows is my desktop. I have a Lenovo uh P1, you know. I like I like just keeping everything portable.

1:09:40 · So, I don't have a big screen or whatever. I just but this is like you know what 15 16inch laptop with a nice OLED screen um and a nice keyboard and that's that's what I do my coding on you know pretty much exclusively and what what tools do you use in terms Oh V code VS code VS code all day every day VS Code and and GitHub all the time yes and and for for AI coding assistance it's mostly the GitHub and and VS Code stuff so which means you know I mean well you can you get to choose your your your LL LM there, right? I mean, but it's that workflow. I think generally speaking, it's limited how much we've been able to use LLMs in implementing our compiler and implementing new language features, it's like it just it's it's good at surfacy stuff, but when it comes to like getting the big picture and how do types and symbols and binding and parsing and all relate and where's what's the most efficient data structure here and and whatever.

1:10:41 · It's yeah it it's not quite to that level.

1:10:44 · I'm also wondering if the lower you go into the stack may that be very high performance code or or very concise code where all these things matter maybe the applicability starts to drop because again we know we we already see this with LLMs. They're amazing for green field work. When you have an existing large application it's it's useful don't get me wrong but it's not nearly as useful.

1:11:04 · Yeah.

1:11:04 · and and we are one big brown field uh [laughter] uh because you know we already have a huge code base right and it's got to it's got to fit in there plus I mean to be honest I mean there are only so many compilers in the training sets of of of AI where where there's a gazillion guey apps written in React and and whatever right so no wonder it's good at those right I was interested in reflecting a little bit on your career you've now been at Microsoft for for 30 years and you've been working on programming language which is for 40. That's even, you know, a lot to to say. But in this industry, it's pretty common for people to change jobs every 3 to 5 years or so. What has kept you at a company for for so long and also in in a similar area for even longer?

1:11:50 · Well, there's there's just something about developer tools that that is just what I love to do, you know, and and programming languages. And they're they're they're complex uh algorithmically complex problems to solve. And I I I for some reason like that they have fewer dependencies on other things. So you're you're you're building from the bottom yourself. Do you know what I mean? You don't have to like sit on top of someone else's framework and and and swear at them when it when it doesn't do what you want it to do, right? So So that kind of works for me, right? But but the thing is like doing programming languages, you come to realize it's a long play. I mean, if if you look back at the the the stuff I worked on, it it it goes in 10 years. cycles at least and Typescript didn't really for example or Cshar for that matter. I mean it took it it takes 10 years to get to you know version one is great but it has all sorts of issues and you got to do version two and then it's not until version three that it really starts to be great but then now you got to convince people to actually adopt it and and and it it's just it's a long play.

1:12:56 · You got to be willing to do the long play. Um, and I think look, having been at a at a company like Microsoft is is it's it's been great because to be put in a position where a company like Microsoft is putting their might behind your efforts on creating a programming lace, that's not an opportunity you get in a lot of places, right? And that has been fantastic. But also, you know, the fact that Microsoft is fundamentally a developer focused company and they they always have been. That's how they started.

1:13:22 · Developers matter. It's not it's not advertisers who are who are paying the bills. It's it's developers and enterprises that you know and and I like that like where you feel like you're doing an artist based work and people are paying you for it and it's it's good stuff you know as closing what what is a book that you would recommend and why I always recommend the same book which is Nick Viet programs plus data structures uh um equals algorithms it's actually like available online now it was written in the 70s but that was the book that it was a revelation for me to read this book this is how I how I learned about hash tables and the how to construct a small compiler and and whatever and it was it was just wonderful. It's very light on symbolism and very rich on examples and and and I was always an engineer and so that book just appealed to me and I think it's still in in in a lot of ways super relevant today.

1:14:18 · The basics have not changed have they too much.

1:14:21 · No. No. Well, I know certainly and and particularly when it when it comes to programming languages. Heck, it's it's a it's a wellestablished discipline quite honestly. Yeah, it's been around for 50 plus years.

1:14:32 · Well, Anders, thank you so much for this in-depth conversation. Oh, my pleasure. This was a lot of fun. I hope you enjoyed this rare conversation with Anders as much as I did. An interesting part I keep thinking back to is how Anders said that programming language design is a 10-year cycle at minimum.

1:14:47 · Version one has issues. Version [music] two fixes them. Version three is finally great. And then you have to convince people to actually adopt [music] it.

1:14:55 · Most of us devs are used to thinking in quarters and sprints. This is certainly a different time frame. I also found it surprising to hear how small the C# language design team was and [music] how lean that they worked. Six to seven people, three meetings per week, 2 hours each. All of them were people who had built languages before and they were criticizing each other's ideas and ideas that survived the criticism were the ones considered good enough to work.

1:15:17 · Which is a good reminder that standout technical work more often comes from small [music] teams than it does from committees. Finally, I really like how Andrew said that IDs are the language.

1:15:25 · From Turbo Pascal in the 1990s to Typescript and VS Code today, Andrew says that the compiler is not the product. The product is the whole edit, compile, run, debug cycle. This is a good reminder to any and all of us building software. [music] The product is the complete way that your customers use the product, not just the screens or parts that you are responsible for. If you'd like to go deeper on Microsoft's developer [music] tool roots and operating systems, check out the related the Pragmatic Engineer deep dives linked in the show notes below. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and [music] on YouTube.

1:15:56 · A special thank you if you also leave a rating on the show. Thanks and see you in the next