TypeScript, C# and Turbo Pascal with Anders Hejlsberg

23:07And so, so that was kind of how we, we, 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++ minus because we didn't use all of the C++ features, you know, in that compiler implementation. But it wasn't until the Roslin project that we self-hosted the C Sharp compiler.

23:38Anders Hejlsberg:And a Rustin meaning that the compiler is in C-sharp, right? Exactly. Yes. Yes. That was a project that came later to build the compiler in itself. And also early on, you know, this is, you got to remember back then, IDEs were not really all that fancy, you know. I mean, we have syntax colorization. Statement completion was kind of like, well, some IDEs 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.

24:19But 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 Roslyn, 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 doing it that way that are still not being taught in school.

25:05Anders Hejlsberg: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. 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 Cursor'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 little known and relative to the new product at the time, TurboPuffer.

25:36Anders Hejlsberg: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 NVMe SSDs. Cursor's active codebases get loaded into the cache, so searches are fast, and inactive codebases 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.

26:08Anders Hejlsberg: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 full-text search and is used by the likes of Antropic, Notion, Linear, Ramp, and many others. I'm getting to know the TurboPuffer team and will 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 slash pragmatic. When it comes to useful tools, I need to also mention our season sponsor, WorkOS.

26:39Anders Hejlsberg: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, SCIM, RBAC, 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?

27:16Anders Hejlsberg: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 dogfooding, 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.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, and so they switched us to, uh, to C sharp and that helped a lot.

27:55Um, 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 got tons of users onto it.

28:17Anders Hejlsberg:Now, C Sharp introduced a lot of new features that were net 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 handle the event and then you yield back to the event handler loop.

29:00And it all runs in a single thread 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.

29:40And 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 the state machine. If you introduce syntax that allows you to indicate where you want to yield, and that's what await is. Await is basically, I'm saying, I want to yield here, 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.

30:35And doing all of that work is something that compilers are great at. 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 with async await, 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.

31:13Now, 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 function. 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.

31:53And 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.

32:30But 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.

32:46Anders Hejlsberg:Speaking of JavaScript, as C Sharp was becoming really popular across startups, enterprises, and so on, it was exploding in 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 went from the mid-90s to this script language normally took seriously to just exploding in 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.

33:35HTML5 got ratified 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.

34:09Anders Hejlsberg:Who would have thought? 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.

34:54And 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 a 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 of 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?

35:37Anders Hejlsberg:Yes. So they were a programming language, right? Which generated JavaScript, but it wasn't JavaScript itself. Yes. Yes. It was 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 Eich. I mean, he understood functional programming. And Brendan Eich, 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.

36:13You 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 now we have the foundation for great tooling, and then we could build a great tooling on top and actually create a wonderful development experience.

36:57Anders Hejlsberg: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 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?

37:38And 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 TypeScript, insisting that that was what we had to do.

38:23And 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 workflow. 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.

39:06But once we switched to GitHub, the entire workflow moved to open development also. And I love that workflow. 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, the language moved to GitHub in 2014.

39:28Anders Hejlsberg:And in November 2025, 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 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.

40:10It'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, or, or whatever, you know, and like these types in comments or, 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.

40:52Anders Hejlsberg: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 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 we work 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.

41:35we had our own precursor of LSP because LSP didn't exist when we first integrated TypeScript into Visual Studio Code. But there were 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.

41:59Anders Hejlsberg: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 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 tree that you can navigate that effectively is a map of the source code, but broken into syntactic primitives and checked that syntactically everything is, or grammatically that everything is correct.

42:51So 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 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.

43:32It'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.

43:44Anders Hejlsberg: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 runtimes, for example, classes. And then we would down-level them to constructor functions and whatever.

44:25And 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 ECMAScript 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 that where it can function in a highly interactive mode, which is what the IDE uses.

45:05Normally, 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 come next? Well, that means we need to know what is the type of 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.

45:44And 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 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.

46:27So 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 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.

46:58Anders Hejlsberg: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. And 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 roadmap? What is something that you feel could make TypeScript a lot better? But of course, there's a constraint there.

47:37We track the ECMAScript committee and, you know, So new language features that get developed in ECMAScript, 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.

48:16And 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 and expressions and then reuse them. This is the 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 a variable or turn it into state.

48:58Anyway, you know, that's one thing that I would like to fix. There's something called do expressions 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, 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.

49:35This 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 int 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.

50:17And 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, 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?

50:55But 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 language features that no other languages can provide because they can't get to 100%. per se.

51:14Anders Hejlsberg: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.

51:54In 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 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.

52:36We 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 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.

53:20Not at all. No.

53:22Anders Hejlsberg: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. an idea 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, either just because random or because there's a new model or there's a whatever.

54:07It's not, it's not that it's, there's no determinants 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 whatever, right? So you have to have something that where the rubber reach the road and where you can reason about and where you can replicate the behavior. Every time you're on the app, the same thing happens.

54:34Anders Hejlsberg:Absolutely. I mean, I even see it in a bunch, I think almost all AI agents or tools these days, when you ask it 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, 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.

55:17Anders Hejlsberg:What is your take on either modifying existing languages for AI usage based on what you're seeing, 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 that just reinforces itself, right?

55:55And you could argue, well, the reason TypeScript and JavaScript are popular, well, that's mostly to do with the 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.

56:38Because 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.

57:11Anders Hejlsberg: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 from at a project level at a at an aggregate level what do you think language characteristics could become more important in this world of of just a lot more code oftentimes generated by machines i mean you could argue that we were already past peak truth on the on the on the internet right and now there's 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.

58:00So 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. 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 pound include 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, then do I burn like a gazillion tokens on, on trying to include, but, but if you have good locality where you, you clearly stating what you're importing and whatever, and, and you can analyze just a single source file.

58:49and 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.

59:09Anders Hejlsberg: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, a global could be anywhere. And there's no way for you to know when someone else is doing your now back-to-state problem, which you just talked about. Original JavaScript suffered from this problem.

59:45There 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 ECMAScript modules and whatever, 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 with AI. AI, it's just starting to become aware of the existence of language services. Agents today like to use grep and oc and whatever to find all the places where you reference a certain thing, but it's not semantic search.

1:00:26And so if you have a common name for this property, like count or address or whatever, 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. 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.

1:01:06Anders Hejlsberg:And I also wonder if for example performance will be interesting because we know that these things can run faster so faster feedback will be helpful which we're now going back to one of the reasons that TypeScript was so popular is that 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 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:01:55Anders Hejlsberg: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, higher level languages came. knowing that AI agents and AI tools will be part of the craft. What do you think parts of software in your 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.

1:02:37And so increasingly, our craft is going from one of writing the code to one of reviewing the code 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 enjoyment. I've always liked writing the code. 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

1:03:14Anders Hejlsberg:of reviewing code much more interesting than it is today, right? I mean, today you see a list 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. Don't you, 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. But I think it's foolish to think that AI will just eliminate programmers and that B because ultimately that's great.

1:03:53You know, like, 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 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.

1:04:34And 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.

1:04:51Anders Hejlsberg: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 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.

1:05:25It'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 programmers become so attached to their tools, you know, and their languages, right? I mean, it's almost a religious thing for which language you're on, which tool you're using, because it's so ingrained in your workflow, and it so enables you to be in the zone, right? So that, I think, is the key to focus on, and that's what I've tried to do with the work that I've done over the years.

1:06:06Anders Hejlsberg:And it sounds like this is why, from the very beginning, 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 not nearly as effective. 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 what will come next.

1:06:41Yeah, I don't know that we can see the steady state at this point because it's evolving so much. But I still believe that programmers are going to be relevant in this equation. I fundamentally believe that.

1:06:56Anders Hejlsberg:What about performance and efficiency? Early on in your career, you just mentioned that your first computer you 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 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 we have more resources or maybe this will change?

1:07:35I 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. inference in in the cloud or on up against that i mean oh my god you know like financial fast trading uh whatever it's all about perf 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.

1:08:24And so it's just not worth optimizing there anymore. It depends, I think, on the kind I have you're building.

1:08:30Anders Hejlsberg:It's a good reminder that not all use cases are born equal. I'm interested, what is your personal development setup like these days? Well, I'm an old Windows guy. I still, Windows is my desktop. I have a Lenovo P1. 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 what I do my coding on, you know, pretty much exclusively. And what tools do you use? Oh, I use VS Code. VS Code. VS Code all day, every day? VS Code and GitHub all the time. Yes, yes, yes.

1:09:10Anders Hejlsberg:And for AI coding assistants? It's mostly the GitHub and VS Code stuff. So which means, you know, I mean, well, you can, 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 surfacy stuff. But when it comes to like getting the big picture and how to types and symbols and binding and parsing and all relate and where's what's the most efficient data structure here and whatever. It's, yeah, it's not quite to that level.

1:09:52Anders Hejlsberg: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 already see this with LLMs. 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 GUI apps written in React and whatever, right?

1:10:33So no wonder it's good at those, right?

1:10:34Anders Hejlsberg: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, and programming languages. and they're complex, algorithmically complex problems to solve. And I, for some reason, like that. They have fewer dependencies on other things.

1:11:17So 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 swear at them when it doesn't do what you want it to do, right? So that kind of works for me, right? But the thing is like, do a programming language as you've come to realize, it's a long play. I mean, if you look back at the stuff I worked on, it goes in 10-year cycles at least. And TypeScript didn't really, for example, or C-Shark 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.

1:11:53And 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 it's just, it's a long play. You got to be willing to do the long play. And I think having been at a company like Microsoft, 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 release, 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.

1:12:28And they always have been. Yeah.

1:12:30Anders Hejlsberg:That's how they started. Developers matter. It's not advertisers who are paying the bills. It's developers and enterprises that, you know, and I like that, like where you feel like you're doing an artist's work and people are paying you for it and it's good stuff, you know. As closing, what is a book that you would recommend and why? I always recommend the same book, which is Niklaus Wietz, Programs Plus Data Structures 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 learned about hash tables and how to construct a small compiler and whatever.

1:13:12And 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.

1:13:40Anders Hejlsberg: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.

1:14:13Anders Hejlsberg: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 IDEs are the language. From Turbo Pascal in the 1990s to TypeScript and VS Code today, Anders says that the compiler is not the product. The product is the whole edit, compile, run, debug cycle.

1:14:43Anders Hejlsberg:This is a good reminder to any and all of us building software. 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 tool routes 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 on YouTube. A special thank you if you also leave a rating on the show. Thanks, and see you in the next one.