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

Episode Date: May 13, 2026

Brought to You By:• Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages.• WorkOS – Everything you need to make your app enterprise ready.• turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable.—Anders Hejlsberg is a living legend and one of the most influential programming language designers of all time. He created Turbo Pascal, Delphi, C#, and also TypeScript. As well as that, he spent nearly a decade at the pioneering dev tools company, Borland, and is now in his 30th year of working at Microsoft, where he’s a Technical Fellow.In this episode, we discuss what it takes to build programming languages that developers love to use, and trace his career from writing his first compiler to creating Turbo Pascal and Delphi, and helping to pioneer modern software development through C# and TypeScript.Anders details how C# was designed by a small group of experienced language designers who met a few hours each week, and he explains why tooling was just as important as the language for TypeScript’s success, and what he has learned from building languages which stay relevant for decades.We also look into how Anders uses AI today, which language features suit AI-assisted development, and what he thinks is changing in the craft of software engineering as developers move further away from writing code line by line.—Timestamps(00:00) Intro(02:48) How Anders got into programming (05:40) Building his first compiler (07:44) Turbo Pascal(12:25) Delphi (14:53) Joining Microsoft(19:41) Building C# (29:11) Async/await(34:01) The rise of JavaScript(37:52) Building TypeScript(42:58) How the TypeScript compiler works (48:30) JavaScript’s strengths and weaknesses(52:18) How Anders uses AI (56:03) What language features work well with AI (1:02:49) How software craftsmanship is changing(1:07:49) Performance and efficiency (1:09:29) Anders’ tool stack (1:11:30) A 30-year career at Microsoft(1:13:40) Book recommendation—The Pragmatic Engineer deepdives relevant for this episode:• Microsoft’s developer tools roots• 50 Years of Microsoft and developer tools with Scott Guthrie• How Linux is built with Greg Kroah-Hartman• How will AI change operating systems? Part 1: Ubuntu and Linux• How Uber uses AI for development: inside look—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Anders Heelsberg is one of the biggest living legends in the tech industry. He created TurboPaskel, Delphi, C-sharp and TypeScript. The impact he has had on programming languages and developer tools is immense. Today with Anders we discuss how C-sharp might have not been born if it was not for the Sun versus Microsoft lawsuit over Java. The behind-the-scenes story of TypeScript and why open sourcing it was a huge deal inside of Microsoft. What he's learned from 40 years of designing languages, including why IDs and programming languages go hand in hand, and many more.

If you want to behind the scenes look at how three of the most used programming languages and how AI might change our usage of programming languages, this episode is for you. Before we start, I'd like to introduce our presenting sponsor for the season, and TzSys. A definite trend that I'm seeing across the industry is a lot more focus 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. 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 cache issues that traditional tests miss, including issues that we did not even think of,

in a code base 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 Antisys does. You can bring the system you work on under test and verify that it works as it should.

Teams at Edcd and Jane Street are doing justice, and I'm also starting to use Antisuses 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 slash pragmatic to learn more. Welcome to the podcast.

Thank you. It's brilliant to meet you. You've created so many widely used programming languages, including the one that I learned first to program with Triple Pascal. How did you get into programming? Well, I was lucky enough to attend a high school that this is back in Copenhagen, that offered students access to a computer. It was one of the first high schools in Denmark to do so. And we're talking, you know, mid to late 70s 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.

You know, the wonder of figuring out how it was put together. Of course, it was like completely ancient by modern standards. It was like this HP 2100 with 32K of ferrite core memory. You could literally open it up and see the ferrite cores. I mean, it was amazing, you know, paper tape reader and, you know, and then we got up one megabyte. 14 inch hard drive and that was just state of the art. The bootloader was on paper tape because there was no ROM in the machine. So it started up, it knew nothing.

And so you had to type in the instruction sequence to load the bootloader that would then load the OS off of the hard drive. And as a kid, what did you start to program on it? What captured your imagination? Well, this was a Hewlett Packard. So it had Fortrend, which I found to be very quirky. It had a very slow, basic interpreter, but then it had alcohol. Hewlett-Packard's version of alcohol, which was an interesting compiler implementation

because it didn't support recursion, which is kind of bizarre. The call instruction of that machine would store the return address in the first word of the subroutine 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. And of course, there were no debugger. or anything to help you figure this out. So you just had to be real careful about which algorithms you used.

But it was compiled to machine code and they brand, 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? And so, yeah, it was fun. Back then, things were so simple, right? You could see all the way to the bottom. I mean, there was just no, no layering and nothing. It was right on top of the hardware.

I guess you needed to see all the way to the bottom. bottom as well pretty much right back then well i mean you it was just so simple that you you could right and that was the beauty of those earlier that was true with the eight 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 you do and how did you go from building games to actually building your first ever compiler and what was that compiler i started in 79 at the uh danis technical university. At that time also, you know, this was right when 8-bit micros were starting to become available. Eight-bit microposistors, right? Yes, exactly. And you, and there 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. So you learned a lot about the hardware, too. And I bought a British Z-80-based kit computer called a NASCOM and started learning, assembly programming 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 Vic20s and Commodore 64s and blah, blah, blah, blah, you know, all of those different ones, right, TRS 80s. 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, which was slow, but it allowed you to write programs. But I always, like, missed having a real programming language, something like Al Gore or that I had been taught, right? And then my buddy, the guy that I founded the company, he was like, well, there's this new thing called Pascal. You ought to check it out. And it's even supposed to be simpler than Algo, which was actually true of every language we have created. They got increasingly simpler as time went on. Pascal was not that hard to implement. And so I got interested in trying to do that.

And then wrote a little compiler that fit into a 12k ROM 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 Turbo Pascal, if you will. Many years later, you joined Borland, and I think it was in 1989, and there you created Turbo Pascal, the programming language, but also the IDE, right? Well, there's a little more to that story. In that company that we had back in Denmark, I ended up writing eventually a full implementation of Pascal for 8-bit CPM 80.

And then we ended up doing a joint venture with Borland, which was also a Danish company, was originally founded in Denmark. And we made a royalty contract where they would sell our compiler 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.

And then that took off more than any of us had expected. And eventually that ended up being the thing that I did full time. Why was it called Turbo Pascal? I understand you added things on top of Pascal that was there. Well, I mean, it was called Turbo Pascal because it was fast.

Back then, Turbo was like, this was like when Audi had their Quatro's and their turbos and whatever, you know, and Turbo just meant fast, right? And this thing was fast and super interactive, right? And so Turbo Pascal it was. When Turbo Pascal became big, was it big just because of the compiler? Or also there was an ID, a dedicated ID for Turbo Pascal, right? Yes, yes. that was always the idea and 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, you know what I mean? And so Turbo Pascal was always about building that whole cycle and try to make it as interactive 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 a Pascal versus basic. And so that was sort of the idea from day one, you know, focus on the whole cycle. And so when you were building the compiler, you were already thinking of ways that the ID, for example, could make sense or could have helpful features for may that be editing or debugging, for example. Oh, absolutely. you know, the first versions of Turbo Pascal didn't have a debugger. You know, you would just use Ritalin statements and then you'd just see what happened, right?

But often if you had some error and it blew up, you know, with a runtime error, we would print out the address of the runtime error, which is where was the program counter 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. You know what I mean? 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 object output and then show you where it was in the source code. You think Turbo Pascal was so popular. I remember back again, this was my first programming experience.

It was at schools. It was outside of schools for production software. And you said yourself that has spread like wildfire. It was just better than all of the competition. It was faster. It was smaller. It was more interactive. And it was also cheaper.

So it was like 10 times better at a tenth of the price of the competition, right? Compilers back then used to cost $500. dollars and they were just compilers and then you had to have an editor and blah blah blah and it was like this whole long-winded cycle of inserting different disks 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 4995 and for 4995 i mean heck that was worth it just to get 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 Russian site license, how we sold one copy to Russia.

And then that got copied everywhere. But after TurboPascal, you built Delphi, which was an even bigger setup in many ways that this was now an integrated environment for Windows development. How did you evolve ideas from Turbo Pascal and Delphi? The big thing that happened there between Turbo Pascal and Delphi was the advent of the graphical user. interface, right? We switch from running DOS in text mode to running Windows in a GUI. And that meant a new kind of application, right, 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. 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, target it also at client server enterprise apps. And that was what Delphi sort of was about, right?

It worked out really well. I mean, 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. I know, yeah, yeah. The Skype application, you probably know this, it was built in Delphi. It was. In 2012 or 2013, there was a plan to rewrite it and move it onto something else. That rewrite midway a year in stopped.

So I'm guessing that until the end of that Skype application, which is decommissioned maybe a year ago. It's amazing, isn't it? I mean, the Delphor was and is in some ways, a wonderful way of building Windows desktop apps. I mean, they had a great, you know, the VCL, the Visual Class Library that allowed you to inherit components and install them on the palette and make drag and drop work for your forms designers with components that you had built and whatever. It was pretty cool. Yeah, and we already heard the Microsoft link with Visual Basics. So you joined Microsoft in 1996. You worked on J++.

and then later C-Sharp. But can you take us back to that moment in time? What was the kind of programming environment like? Well, the environment, particularly around the time where I joined Microsoft, the mid-90s, Java had happened. 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 was in the browser,

you know, and it was slow and it was like, eh, no one uses that. But then there was this Java thing that allowed you create applets. Oh my God, Apple's fantastic. And right on the browser. Right. Right. Yeah. Everywhere.

And in the browser and everywhere, supposedly. And this language that was like simple yet had object orientation and bike codes and like was platform independent. And I mean, it was like everyone was running around with like with their heads caught off thinking this was the end of languages. You know, Java is going to flatten the universe. And then we're all just going to be writing Java and Java applets and that's the, that's it. You know, and I actually came to Microsoft ostensibly to be the architect of Microsoft's Java development tool.

And worked on Visual J++-60 was the version that they had Visual J++1-1 at the time I joined, which was basically take Visual C++, yank out the C++ compiler, dig in a Java compiler and call it good. But it wasn't interactive. It wasn't rapid application development and whatever. 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 Visual J++-60. 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 the precursor, WFC, I think it was called, but it was the precursor of windform. you know, in some ways. How did the development of J++ go and eventually how did it lead to the idea of like, okay, let's do something else, completely different? Well, you know, development of J++ went great until the big Sun Microsoft lawsuit got in the way. 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 technical, but it effectively meant that. official J++ was never going to be a product that companies would make a bet on because they full well knew that, you know, you're not going to, you're not going to ride your app in a language that has been enjoined by a judge in San Jose, you know, or whatever. And so we kind of realized at that point, too, that maybe it's not a great strategy to place your, your development platform bet on on technology that's licensed from a competitor. And that, and that in terms of, 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. 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 then we had C-plus-plus 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, an exception handling and a more object-oriented component-oriented way of building your apps. And all of that was part of the genesis that led to dotnet and to the CCHART language. So which one was first? Dotnet or C Sharp inside 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 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 the middle, right? And to be frank, something that could compete with Java, right? And so, so that's why we started out building C sharp. And then when you started out building C sharp, 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 would this language be? Well, like I said, I mean, the The overarching thing was this power and productivity of C++ with the ease of use of visual basing in a sense, right? But what it also meant was we knew we wanted to build an object-oriented language, we wanted manage code or byte code so we could target different runtime environments, we wanted garbage collection and exception handling, but also things like a unified object system where, and that's true in C-sharp. like anything can be assigned to an object.

And if it's a value type, we box it, and it's a self-describing object. 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 a lot of other environments. And 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 even objects, right? And then we actually also wanted to create a language that was standardized. We wanted to give this language to a standardization committee and try to, you know, level the playing field there. And all of those things were sort of like what was rolled up in C-sharp. You definitely did it. C-sharp was my first professional language. where I worked for that, I think, for about five years.

And 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-Sharp was ahead of some languages today in some way. So it's very interesting to see how rich that language was when it came out. And of course, the developer love that followed. But can you take us back of what did it take to build a language like this? Just in the more, again, software engineers, people were listening to their use to building the SaaS apps,

backend services, you know, like certain projects, but we are not familiar with what it takes to build a language, especially something with such large ambitions inside Microsoft. You knew millions of developers ideal would be using it. How did you get to this? Did you, how did you come with the roadmap? 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

to sign this language, not just one. I was sort of the guy who ran, the group of designers, but we put together 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 the, we all knew what a, I mean, these were all people who had built or worked on programming languages before, right? And had seen all of the things you're supposed to do and all the things you're not

supposed to do. And quite honestly, language design is 90, percent the same and 10 percent new for for pretty much every language. Every language you built still has to have a compiler. 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 IDs, you have to have frameworks. You have to blah, blah, blah, blah, blah, blah.

You know, and it's all there's, so there's a lot of experience you want to pull in. And there's a lot of work that you're doing that isn't really per se new. But every time around, you try to fix the problems that you've been. 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 you know what I mean? Yeah. Yeah. And that worked really, really well because we could just jump right in, you know, 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. What's wrong with this idea?

Do you know what I mean? And if it could stand the test of that, then it was probably a decent idea. And so that was kind of how we ran the design. And then 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 plus minus because we didn't use all of the C++ features, you know, in that compiler. But it wasn't we, it wasn't until the Roslyn project that we, that we self-hosted the C-sharp compiler.

And Rosslin meaning that the compiler is in C-sharp, right? Exactly. Yes. 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, IDE'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 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 added other features and link and whatever,

and it was like, oh, my God, now this is like, we got to go implement all of these features twice 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 has built that same way also,

and there's a lot of learnings from doing it that way that are still not being taught in school. 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 season sponsor, Turbo Buffer. 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 Cursors' co-founders about how the vector database could not keep up with the number of codebases that they were adding. This was back in 2023. Cursor did something seemingly risky. They took a bet on what was a little known and rolled to the new product at the time, TurboPuffer. But it paid off.

Cursor moved their semantic search workload over, and TurboPuffer was indeed able to handle cursor's massive, ever-increasing load. The reason has everything to do with smart engineering. TurboPuffer is built on top of object storage with smart caching on MVME SSDs. 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 costs by 95% when they switched.

They think of TurboPuffer engineers as an immediate extension of their team in Slack, and TurboPuffer is one of the few pieces of infrastructure that they have not had to worry about as they scaled. Today, TurboPuffer indexes over 4 trillion documents for Vector and Fultex search, and is used by the likes of antrophic, 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 Fultex search at scale, think TurboPuffer. Check it out at turbopuffer.com slash pragmatic. When it comes to useful tools, I need to also mention our season sponsor, WorkOS.

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. WorkOS takes the same kind of long-term view on enterprise infrastructure. SSO, Skim, Rback, 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 WorkOS. Visit WorkOS.com to learn more.

And with this, let's get back to building languages with Anders. And when you're building a language, as your product was, I guess, the language itself, how did you get feedback? Like, of course, you already said the group criticized it. 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 average software service for sure. Yeah. I mean, luckily we had internal clients. The dot net framework very quickly started implementing in C Sharp. They had sort of used a hacked up version of C++ to implement, which was. kind of odd because, I mean, it was like targeting byte codes, but not really. And so they switched to C Sharp. And that helped a lot. And then we had other internal teams using it. And so 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, we had, we signed up, I mean, we basically gave away beta copies, right, and got tons of users onto it. Now, C-Sharp introduced a lot of new features that were neck new, I think, to programming languages. Link is certainly one of them. But one thing that might have been maybe one of the most influential parts that other languages adopted as inspiration was the Async await setup. Looking back, what do you think you got right with this design and why did it become so

copyable across languages like JavaScript, Python, Rust? and others. Well, a lot of languages 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 threat cooperatively, right? The problem with that is if you then want to do some long running work, how do I stop in the middle of this piece of long-running work and yield back to the event loop cooperatively, right? And then when my result is ready, then I can come back and continue executing here. Well, in order to do that in an inverted architecture like that, you have to build a state machine.

And state machines are notoriously hard for people to implement because you've got to move all of your state off of the stack into objects. You've got to remember where, and then you have this big case statement that envelopes your entire logic. and it's like it's a nightmare to figure out, right? But the transformation from serially executing code into a state machine, this continuation processing style translation, is actually one that you can do in a machine-based fashion.

You can have the compiler write a state machine. If you introduce syntax that allows you to indicate where you want to yield, and that's what a weight is. A weight is basically, I'm saying, I want to yield here and then when 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 something that compiler is a greater. And so that was sort of the idea that we have this new style of programming where we're using promises or the equivalent of promises and the ability to yield. And then we have callbacks. But trying to write your program in that style. That's also what JavaScript suffer from a lot, right? It's like all this callback style stuff.

And when they think of wait, you get sort of the illusion that you're just writing normal sequential code. And then the compiler does the painful transformation. for you. And that turns out to be really useful. 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 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 you can do with async functions.

So there are pros and cons. You know, like, async and weight introduces this notion of function coloring, which is unfortunate where you have two kinds of functions, async functions and regular functions. And all the red functions can call the blue functions, but the blue functions can't call the red functions. And so that means once you want, you know, a red function,

now everything above it has to be red. And so if you want from a sync function to call something async, well, then you've got to turn this function into. an async function and its caller has to be, et cetera, et cetera, right? So that's unfortunate and that's why some environments like Go, for example, has go routines and green threads, which are really language emulated lightweight threads that kind of do what I'm talking about, but at a much lower cost. But you avoid the function coloring.

So there is a bunch of different things, but for an environment that already exists like JavaScript or like C-sharp and the Windows event loop and whatever, this was the right solution. Speaking of JavaScript, as C-sharp was becoming really popular across startups, enterprises and so on, it was exploding popular games as well. To this day, it's very popular with games development. But JavaScript was starting to become more popular. Can you take us back to your observations on how JavaScript was.

went from, you know, like the mid-90s to this script language, no one really took seriously to just exploding a popularity. I think it was sort of a confluence of a number of things that happened in the early 2000s, right? First of all, 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 programming language. HTML5 got ratified and,

And we were getting to a point now where you could actually build real UIs in JavaScript. And there was this device revolution that the iPhone set off. And all of a sudden we have all of these different form factors. It's not just Windows PCs on the desktop anymore. It's all sorts of diverse devices. But lo and behold, they all run browsers with JavaScript in. Lo and behold, the real cross-platform language isn't Java. It's JavaScript.

Who would have found? Exactly. And so the world started opening its eyes to that 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 Outlook.com team came to the C-sharp team and asked us whether we would. Pretty please productize this thing called script sharp. And we go, well, what is script sharp?

It's this cross compiler that allows you to cross compile C sharp into JavaScript, such that you can basically treat JavaScript as an instruction language and run your C Sharp apps in a browser. And I'm like, well, why would anyone want to do that? Well, because then you can get a grown-up programming language with grown-up tooling. You can use Visual Studio, 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 the scripting language with shitty tooling. And we were like, wow, really? Well, gosh, well, perhaps a better approach would be to fix JavaScript.

I mean, surely you're not going to be best to breed in the JavaScript ecosystem by telling people to write in a different programming language. Although plenty of people were like, remember CoffeeScript and all of these other like languages that targeted JavaScript, right? Yes, so they were a programming language, right, which generated JavaScript, but it wasn't JavaScript itself, yes. Yes, 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 understood functional programming. And Brendan Ike, the creator of JavaScript. And he got functions as first class objects right in JavaScript, which is godsend 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 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, we could create a superset of JavaScript that adds a type system and then we could just compile it away. But then we have, now we have the foundation for great tooling and then we can build a great tooling on top and actually create a wonderful development experience, right? That was sort of like what we set out to do. 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 Ballmer was notoriously perceived as anti-open source back then with Windows and C-sharp back in the day, of course I'm talking about. You know, Microsoft were slowly waking up. 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 so that battle was, we were right in the center of that. And we full well knew that there was absolutely zero chance that we would appeal to the JavaScript ecosystem with a proprietary programming language 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 pulling. And we paid some taxes.

We did eventually get the okay to do open source because we had two technical fellows, myself and Steve Luko, who was the other co-inventor of, of Typescript insisting that that was what we had to do. And so, okay, people weren't going to debate that. But, of course, you have to pay the tax and be on Microsoft's open source repository called Codeplex, where exactly no one was. And so we were there for the first two years. 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 with adoption. And also, honestly, it totally changed our work. You know, there's open source and there's open development. 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 its repository and scrape the issues off of that and put it into our internal issue tracker and then, you know. But once we switch 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. And it's been fantastic. And it's what made the product as good as it is. Just over a decade later, so the language moves to GitHub in 2014. And in November 2025, the GitHub Octover's 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 capture developers' preferences this well? Well, I think, you know, it didn't just happen overnight. You know, and if you look back at that, you know, all of a sudden we surfaced as number 10, and then we climbed slowly over the years up 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 early on were using JS Doc or whatever, you know, like these types in comments or that we also support it. 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 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 programmer productivity boost is realized. And I guess this is where we cannot not mention VS code, which shipped that great tooling also as a free to use for most people, or at least initially for most people, which also made a big difference.

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

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 Visual Studio code. But there are a lot of learnings from that. So it's been an incredibly symbiotic and fulfilling experience to build these two projects in parallel in open source.

And I think it has totally changed people's view of Microsoft in the developer ecosystem. For us, developers who, again, are not as familiar with compilers themselves. Of course, I use TypeScript and 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 what parts you specifically focus on more? Sure. 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 the source code, you know, but broken into syntactic primitives and checked that, you know, like syntactically everything is, or grammatically that everything is correct. So those are the first two stages of the pipeline. Then we have, well, we have a one extra pass that we called a 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 functions 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 that helps us do. And then we have the type checker, which is the largest part of our pipeline. And that's 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 so forth. And then we have 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 bytecode. Now, in our case, we just erase types, if you will. Well, we kind of do two things in our compiler. Actually, early on, it was very much about, A, erasing the types, but B, also down-leveling your code.

So we would take newer ECMAScript features that weren't yet supported by the runtime, for example, classes. And then we would down-level them to construct a 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 like ECM-Script features are caught up. And 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 unannotated and also can spit out declaration files, which are summaries of your modules 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 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 you, what could come next? Well, that means we need to know what is the type of the thing you dotted on in order

to figure that out, we may have to resolve stuff. We may have to look at ASTs 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've got to be super, super deferred and interactive. And so you've got to do minimal amounts of work.

And that's how our compiler is built. is it tries to front load, like, for example, like you have 500,000 lines of code. Well, let's say in 500 files. Well, we can build the ASTs 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 AST of the current file you're in. So that goes 500 times faster, right, 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 what the textbooks will traditionally teach you. Yeah, because I guess this is now, these are interactive compilers, if you will, right? It sounds like it's more than a compiler or a lot more difficult problem to solve. The same engine is there, but you got to build it in a manner where it can be very interactive. That was not typically important for compilers, you know. And so TypeScript is a superset 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 role map?

What is something that you feel could make TypeScript a lot better? but of course there's a constraint there. We track the ECMAScript committee and new language features that get developed in ECMRACrip. We implement once they reach stage three or four in the standardization committee and then we've sort of been on that train

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? So that is, if you will, 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 key to them is that everything is an expression. There's really no distinction between statements and expressions. And so one of the features that JavaScript lacks in my estimate 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 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've got to pop out and declare variable or turn it into state, anyway, you know, that's one thing that I would like to fix. There's something called do express. that may or may not happen at some point, but it's taken a long time. So anyway, but I mean, generally speaking, I think JavaScript 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 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 unlike pretty much any other programming language,

is the gradual typing, this notion that you can have types, but you don't have to have types. Other languages force you to type everything, right? Because they in turn use that information to generate machine code, you know, based on what the type is, you know, different instructions for float versus in versus whatever, where in JavaScript, the types or in TypeScript, the types are there purely for the development experience and the checking.

When the program runs, they're all gone. Now, of course, there are still types, but they're all dynamically computed. 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 to types, the deeper you go and you're just staring into the recursive abyss.

You know what I mean? But you can kind of go, 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 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% the JavaScript checked, right? And it gives you language features that no other languages can provide because they can't get to 100%. It's interesting how constraints lead to innovation or even limitations can lead to more innovation. Speaking of innovation, 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 a more, I guess, niche team, what kinds of AI tools are you using or how is

AI helping your language development work? May that be TypeScript or C-sharp? Day to day, I work 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 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. We use AI to implement issues or fix issues, simple issues. And it succeeds some of the time in this port that we're doing, 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. And that's actually going fairly well at this point. And then we use it for a bunch of 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 they'll just pump out more tests and great.

So we're trying to use it to get rid of all the toil that otherwise we would spend our time on. But I would say we're not a point where it absolves from understanding what we're doing. Not at all, no. 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 it's language is interesting in the world of AI because AI, like a lot of,

like 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, either just because random or because there's a new model or there's a whatever. It's not, 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 reeks the road and where you can reason about and and where you can replicate the behavior. Every time you're on the app, the same thing happens. Absolutely. I mean, I even see it in a bunch, I think almost all AI agents or tools these days when you ask

something to do with data. Oftentimes they will start writing a Python program because I think the AI designers figured out that you at some point want to turn some non-deterministic into a deterministic. Exactly. What is the thing that we know most efficient? Don't ask it for the answer.

Ask it to write a program that computes the answer. And you will know that that will be deterministic. Yes, exactly. Yes. It's very interesting. But speaking of languages 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 motivational,

identifying existing languages for AI usage based on what you're seeing of 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, 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 so, and that just reinforces itself, right? And you can argue, well, the reason TypeScript and JavaScript are popular, well, that's mostly to do with a browser and 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

to producing better programs. And I think our combination of the ability to type something when there's no context, but also 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 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 the dry or do not repeat yourself principle, right? And fewer tokens generally makes AI more efficient.

And so I think we have a very nice combo there in how you can just sort of type the outermost parameter and then everything flows from there on in. Right. Now, one thing that AI is already revolting in, again, for the GitHub team share stats. So this is also open data that AI agents are generating a lot more code. I mean, they're both quick to generate. They also like to be sometimes verbose. Knowing that we are already seeing a lot more code pushed everywhere and at a project level, at an aggregate level, what do you think language characteristics could become more

important in this world of just a lot more code? oftentimes generated by machines. I mean, you could argue that we were already past peak truth on the internet, right? And now there's just more and more garbage every day. It gets harder and harder to suss 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 gradual, I mean, I'm sure people are working on it. I could see that as becoming problematic.

Languages that are suitable for AI, I think like I talked about types and inference. I think both of those are important. I think also locality is important. Locality? Well, what I mean by that is like don't have a bunch of global stuff where AI has to grok the entire product. Oh, these pounding glue files that are, oh my God, well, who knows where they're in scope and how, do I put that in the context window or not?

and then do I burn like a gazillion tokens on trying to include. But if you have good locality where you're clearly stating what you're importing and whatever, and you can analyze just a single source file and from that extract its protocol to the outside world without having to know anything deeper, do you know what I mean? I think those are important aspects, just simply to reduce the size 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 just hacking around in PHP until I had the issue of something was not working and turns out that something imported over with a global and suddenly you realize that when things are defined across the code base, that global could be anywhere, and there's no way for you to know when someone else is doing your 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 am I sitting on top of here? But now with JavaScript modules and whatever, we're moving towards sanity, and more and more the world is written that way in the JavaScript Eco. system. And that's a good thing. And I think that will help us down the line with AI. AI, it's just starting to become aware of, you know, the existence of language services. And agents today like to use

Grep and Hawk and whatever, you know, to find all the places where you reference a certain thing. But it's not semantic search, right? And so if you have a common name for this property like count or address or whatever, right? Well, it's going to find a whole bunch of properties named address. And then that's not going to work so well because now you don't know that you're renaming the right one, right? But this is where language services come in and semantic search. And I think that's going to increasingly become more important with AI. And really, 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.

And I also wonder if, for example, performance will be interesting because we know that these things can run faster, so faster feedback. So, faster feedback will 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 you could imagine, you know, like a server, keeping a project hot and giving your LSP services, you know, that AI can ask semantic questions and whatever. And then once AI stops asking after 10 minutes, the server just dumps it, you know, and whatever. There are ways of putting this together, I think, where we can make some progress 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. What about the software craft? You've been in this industry 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, I guess the higher level languages came, knowing that AI agents and AI tools will be part of the craft. What do you think parts of software engineer craft will become less important

and what might become more important? In a sense, we're all turning into project managers. right 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 and so increasingly our craft is going from one of writing the code to one of reviewing the code and and building the architecture of the code and overseeing the work if you will it's a different kind of craft it's a different kind of of enjoyment. 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? And in a way, AI robs a little bit of that, right? I mean,

because I am less interested in reviewing code. But I think we could also make the process 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 now it's up to you to make heads or tails of it. I mean, there are more pedagogical ways of presenting that, 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 that symbiotic relationship, I think we need to work on that more and sort of to keep

the enjoyment in there. But I think it's foolish to think that AI will just eliminate programs. And then be, because ultimately, that's great. You know, like vibe coding is wonderful as long as it works. And then the minute 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'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're not going to go back to the eye and say, shame on you. I'm going to fire you. What does that even mean? Right? I mean, now you have nothing.

You know, it's, no, you need someone to have that function of being responsible. And so, so that's, you know, 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 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 it, 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 right there. It's an extension of my fingertips, right? So for me, as a language designer, I'm never just looking at the language. It's you're looking, you've 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 by programmers become so attached to their tools, you know, and their languages, right? I mean, it's almost a religious thing for which, which language you're and which tool you're using. And because it's, it's so ingrained in your workflow.

And it's so enables you to be in the zone, right? So that, I think, is the, that's the key to focus on. And that's what I've tried to do with the work that I've done over the years. And it sounds like this is why from the very being, you also focus on the IDE, the tool where developers spend their time in. Yeah, you can't have one without. the other. Well, you can, but it's just not, it's not nearly as effective. Yeah. 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 stake at this point, because it's evolving so much. But I still believe that programmers are going to be relevant in this equation. You know, I fundamentally believe that. What about performance and efficiency? Early on in your career, you just mentioned that your first computer you've had on how many

kilobytes it had and how you fit your compiler into 12 kilobytes, which these days, I cannot even create a text file that's smaller than that. Or it's very hard to do, right? But it seems in those years 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? I think it's a case of it depends.

There are certain classes of apps for which efficiency is absolutely key. I mean, the kind of program that my group works on, like compilers, tooling and whatever. Yeah, people do care. That's why we're spending a year and a half moving to native code. Infference in the cloud or up against data. I mean, oh, my God, you know, like financial fast trading, whatever. It's all about Perf, right? I mean, at the speed of light and like trying to move your trade faster than the other.

other guys. So there are lots of places where Perf is king. But there's increasingly also places where Perf doesn't really matter because, you know, it's so fast anyway that even if it's 10 times slower, you still can't detect a difference. And so it's just not worth optimizing there anymore. It depends, I think, on the kind of app you're building. It's a good reminder that not all use cases are born equal. I'm interested. What is your personal development set up like these days. Well, I'm an old Windows guy. I still, I still, Windows is my desktop. I have a Lenovo, P1. You know, I like, I like just keeping everything portable. So I don't have a big screen or whatever. I just, but this is like, you know, what, 15, 16 inch laptop with a nice OLED screen

and a nice keyboard. And that's, that's what I do my coding on, you know, pretty much exclusively. And what tools do you use? Oh, I, VS code, VS code, VS code all day every day? Visc code and GitHub all the time. Yes, yes, yes. And for AI coding assistance? It's mostly the GitHub and VS code stuff, which means, you know, I mean, well, you get to choose your LLM 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 good at. surfacey stuff. But when it comes to like getting the big picture and how to types and symbols and binding and parsing and all relate then where's what's the most efficient data structure here and whatever, it's yeah, it's not quite to that level. I'm also wondering if the lower you go into the stack may that be very high performance code or very concise code where all these things matter, maybe the applicability starts to drop because again, we know we already see those other elements. They're amazing for

greenfield work. when you have an existing large application, it's useful, don't get me wrong, but it's not nearly as useful. Yeah, and we are one big brown field because, you know, we already have a huge code base, right? And 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 AI where there's a gazillion gooey apps written in React 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 30 years and you've been working on programming languages for 40.

That's even a lot to say. But in this industry, it's pretty common for people to change jobs every three to five years or so. What has kept you at a company for so long and also in a similar area for even longer? Well, there's just something about developer tools that is just what I love to do. you know, on that programming languages. And they're, they're complex, algorithmically complex problems to solve. And I, for some reason, like that.

They have fewer dependencies on other things. So you're building from the bottom yourself. You know what I mean? You don't have to like sit on top of someone else's framework and, and swear at them when it, when it doesn't do what you wanted to do. Right. So that kind of works for me, right? But the thing is like, do our programming languages.

come to realize it's a long play. I mean, if you look back at the stuff I worked on, it goes in 10 years cycles at least. And TypeScript didn't really, for example or seat shop 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've got to convince people to actually adopt it.

And, and it's just, it's a long play. you've got to be willing to do the long way. And I think, like, having been at a company like Microsoft is, it's been great because to be put in a position where a company like Microsoft is putting their mic behind your efforts on creating a programming lease, 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 always have them. Yeah, that's how they started. Developers matter. it's not it's not advertisers who are paying the bills it's it's developers and enterprises that you know and i like that like where you feel like you're doing an artist day's 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 niklaus viet's programs plus data structures equals algorithms it's actually like available online now it was written in the 70s but

And that was the book that it was a revelation for me to read this book. This is how I learned about hash tables and how to construct a small compiler and whatever. And it was, it was just wonderful. It's very light on symbolism and very rich on examples. And I was always an engineer. And so that book just appealed to me. And I think it's still, in a lot of ways, super relevant today. The basics have not changed, have they?

Too much. No, no, no, certainly. And particularly when it comes to programming languages, heck, it's a well-established discipline, quite honestly. Yeah, it's been around for 50-plus years. 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. Version 1 has issues, version 2 fixes them, version 3 is finally great, and then you have to convince people to actually adopt it. 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-sharp Languages Line team was,

and how lean that they worked. Six to seven people, three meetings per week, two 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. Just a good reminder that standout technical work more often comes from small teams than it does from committees. Finally, I really like how Anders said that IDs are the language.

From Turbo Pascal in the 1990s, to TypeScript and VScode today, Anders 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 on all of us building software. The product is the complete way that your customers use the product, not just the screens or parse that you are responsible for. If you'd like to go deeper on Microsoft's developer tool routes and operating systems,

check out the Related the Pragmatic Engine Your Deep Dives linked in the show notes below. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks, and see you in the next one.