The Peterman Pod - Creator of TypeScript: 10x Faster Typescript, Why AI Won't Replace SWEs | Anders Hejlsberg

Episode Date: August 17, 2026

Anders Hejlsberg is the creator of TypeScript and C#, and I asked him about how the TypeScript compiler got 10x faster through a rewrite in Go and his thoughts on how AI has impacted software engineering.• My ergonomic keyboard project I mentioned, you can follow along here: https://read.compose.llc/• The Kickstarter page for it: https://www.kickstarter.com/projects/ryanlpeterman/compose-simple-ergonomics-beautifully-donePodcast links:• YouTube: https://www.youtube.com/watch?v=cywK3XYYJ2o• Apple: https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835• Transcript: https://www.developing.dev/p/creator-of-typescript-10x-fasterThank you to this episode's sponsors for supporting my work:• WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://workos.com/• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at https://jira.dev/Timestamps:(00:00) Intro(00:48) Why write a compiler in JavaScript(07:29) Why rewrite the compiler in Go(14:49) LLMs for large migrations(20:12) Why Javascript is so popular(26:32) Why ever use Javascript on the backend(32:59) What it takes to build a programming language(37:06) Will there be fewer languages in 10 years(42:57) Hands on engineering vs delegation(49:14) Why fast tooling matters more now(51:16) AI software engineering predictions(58:52) The most technically challenging work(01:02:04) Top book recommendation(01:03:50) Advice for his younger self(01:05:00) OutroWhere to find Anders:• GitHub: https://github.com/ahejlsberg• X/Twitter: https://x.com/ahejlsberg• Wikipedia: https://en.wikipedia.org/wiki/Anders_Hejlsberg• LinkedIn: https://www.linkedin.com/in/ahejlsberg/Where to find Ryan:• Newsletter: https://www.developing.dev/• X/Twitter: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/• Threads: https://www.threads.com/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman• TikTok: https://www.tiktok.com/@ryanlpetermanReferenced in this episode:• Flow type checker repository: https://github.com/facebook/flow• TypeScript compiler repository: https://github.com/microsoft/TypeScript• Algorithms + Data Structures = Programs (book): https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs• TypeScript native rewrite: https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

Don't let people tell you that it can't be done. When they tell you it can't be done, it's because they can't do it. This is Anders Heilsberg, the creator of TypeScript and C. Sharp, and we talked about how TypeScript recently became 10 times faster through a native rewrite. Couldn't we like fix JavaScript? Wouldn't that be better? Do you know what I mean? If you think about Rust, what didn't it have that if it had it, you would have picked it? I mean, I think there are two things.

If you're going to hand AI the keys, I mean, then all bets are off, right? Why is there such a big difference between this opinion and what I see from maybe people who work at Anthropic? People love these, like, take it all the way to 100%, right? And that's where I get off the bus. Here's the full episode.

The big thing that we're going to talk about here is obviously TypeScript 7 with the native rewrite. And the first thing that I think of when I see this was I didn't even realize that the compiler was written in JavaScript to begin with. Because I don't usually think of compilers being written in high-level dynamic languages. Yeah, no.

So why was TypeScript written originally, the compiler written in JavaScript? No, it's a good question. And honestly, if you had told me, like, before the TypeScript project started that enters, you're going to be writing compilers in JavaScript, I'm like, no, no, I'm not. But, I mean, it, you know,

the original, prototypes for for typescript the strata project as it was called in the in the very early days was actually written in C because it was like an adapt adaptation of the the parser the JavaScript parser that we had in IE and whatever and and then we moved to to JavaScript but we wrote it sort of C sharp style but why did why did we go with JavaScript well I mean if you can self-host in the ecosystem that you want to be a part of, then that is just dramatically better

than putting yourself outside the ecosystem and trying to target that ecosystem. Do you know what I mean? Because by writing it in TypeScript, we were also daily users of TypeScript and daily users of the tooling that we were building. And whenever something didn't work right, we knew it immediately.

And whenever something didn't perform right, we knew it, you know. And so in the early years, it was a huge, boom, I think. And then, of course, JavaScript runs everywhere, right? And that meant automatically our compiler could run on every platform anywhere,

even in the browser, right? Had we gone with a native code solution at that time, it wouldn't have been possible to run it in the browser. Now we have WebAssembly or WASM, you know, but that didn't exist at the time, right? So it was a meaningful choice.

And honestly, at that time also, people didn't really realize how fast JavaScript had gotten. I mean, it used to be very slow. And then Google did all of their excellent work with V8 and got it to within 2 or 3X of Native Code, which is pretty darn impressive. And it was like full well possible to write compilers in JavaScript. And you could even get them perform it, because often it's the algorithms that determine how performant you are.

It isn't necessarily the runtime environment, right? I mean, it's a combo, but, yeah. Is there anything unique about the TypeScript compiler? Like, you know, I think of a compiler. I think of Klang or, you know, one of those ones that is used for maybe C++ or those static languages. What's unique about the TypeScript compiler when it was written in JavaScript compared to these native compilers?

I think there are a couple of things that are pretty unique about typescripts compiler. First of all, it doesn't target machine code. It targets JavaScript. And some people call that a transpiler. And in a sense, you know, the compilation face is mostly about removing the type annotations and turning your typescript back into JavaScript, right? Now, in the early days, also an important part of the compilation process was to down-level your JavaScript,

meaning all of the runtime environments at the time were not evergreen, and sometimes people were lagging like multiple years behind on which level of the standard was implemented. And for example, when classes got standardized, most JavaScript runtimes didn't implement classes. But it turns out that you can down-level to constructor function, and transform the code. And so part of what we did was this transformation down-level transpiling of the code. But then, of course, the type-checking is the big thing that we do. And the type-checker in TypeScript is also quite unlike any other type-checker in other compilers.

Typically, type-checkers exist in compilers to guide the code generator. because you want to know, are we dealing with a float or a string here so we can generate the correct machine instructions for that data type, et cetera, et cetera. That's not the case in TypeScript. In fact, since we erase the types, the types have no impact whatsoever on the runtime behavior of the code. They purely exist for tooling's sake and for the developer's sake and to guide things like statement completion and refactoring and code.

navigation, which is a whole different thing. And also, they don't necessarily have to be there. And so TypeScript has a gradual type system. You can sort of have half of your code have types, and the other half is just any's, that we don't check. Now, very few languages have anything like that. So it's a very different compiler in that sense, you know, and a very different language in that sense. That actually made it fast. fascinating to work on because we were solving problems that no one had solved before, you know. I know a lot of compilers, you know, they take the higher level code and they typically apply optimizations as well. Maybe, you know, they unroll loops or they get rid of duplicate instructions to simplify things.

Is anything like that happen in the TypeScript to Java compilation process? Very little. Like I said, when we do the down-leveling, there are some transformation. that go on that are complex. But it is less and less the thing that's important about TypeScript. And in fact, a lot of people use TypeScript only for the type checker. And then they use some bundler like ESBuild or SWC or whatever to package their app, erase the types, do whatever needs to be done in order to make it runable in the browser. And so we're not really there to optimize your code.

for runtime. We're there to make you more productive as a developer or make AI more productive as a developer. So with the native rewrite of this originally fully JavaScript compiler, what was the problem you were trying to solve with the rewrite and why did you end up rewriting it in native code? Well, I mean, the problem we were trying to solve is real simple, performance and scalability. JavaScript was never really optimized for compute-intensive workloads like compilers, right? JavaScript is more about creating UI that runs in a browser, was originally intended for just like maybe 100 lines of code, but now, of course, it's gotten to be a lot more.

But it's not a place that you would optimize for the kind of workload that we are. So in JavaScript, first of all, you pay a 2 to 3x perf penalty compared to native code. I mean, it depends on the workload, you know, but that's, but if you're doing compute, that's about where it's at. And then secondly, in JavaScript, there are a lot of restrictions around use of concurrency. JavaScript was always engineered, in fact, to be a single-threaded language. That's why we have callbacks and async and whatever. It's because you can't spin up threads.

And that's a good thing mostly because concurrency in a language with mutable data is very, very hard because you can have races and deadlocks and all of this good stuff, right? That's why functional programming languages are easier with concurrency because all the data is immutable and it's much easier to reason about. So JavaScript doesn't give you access to concurrency other than web workers. but web workers can't share data between each other other than by remoting it. So you can have one web worker compute something, but if it wants to give it to some other web worker, it has to turn it into JSON, or it can't just hand it objects. And that means you can't have one worker compute some data structure

and then have someone else use it. In other words, you can't have shared memory concurrency. And really, that's what we wanted in order to get, all of the perf that we were leaving on the table by not utilizing multi-core CPUs that everyone has today, right? Because Moore's law has stopped giving us faster CPUs. It's giving us more CPUs. And we got to like find ways to use them in our in our compute-intensive workloads or else we're leaving money on the table. And so we were leaving money on the table in multiple ways, right? And so native code, and that was why we looked for a language that would

get us out of both of those binds. It had to be native and it had to have access to shared memory and currency. I saw for the language choice you went with Go and when I think of all the systems languages, the ones that are often hot or maybe, you know, Rust or Zig. Why did you choose Go for the native rewrite? I think the decision process was actually pretty structured. You know, the first decision we made was we're not going to rewrite. We're going to port. because only by porting can we preserve the semantics and the algorithms and the exact behavior of our existing compiler, which everyone depends on for backwards compatibility. Now, we could have cleaned the slate and start it completely from scratch,

but we would have come up with a different language in the sense that it would give you different errors or behave differently in certain situations where it has to make choices between multiple possibilities and what have you, right? we wanted to port. And that meant our code makes certain assumptions. Like our code, for example, assumes the existence of garbage collection. It assumes the existence of first class treatment of functions. You can have functions within functions and you can close over outer state and so forth. And as we evaluated all of these, Go was the one that checked the most boxes.

You know, it gives us very robust and mature native code generation on all major platforms. It has garbage collection, and it has excellent access to shared memory concurrency. And those were like the high order bits that we wanted to check. And every other language had something that kind of worked against those objectives. So for this particular workload, Go was the right choice for us. And it's worked out well. If you think about Rusk, what didn't it have that if it had it, you would have picked it? I mean, I think there are two things.

It doesn't have garbage collection. It's done manually, you know. Well, or it's done through the borrow checker, but the borrow checker doesn't allow circular data structures. And our compiler is chalkful of circular data structures. We have trees with parent pointers. We have types that are recursive. We have symbols that refer. I mean, it's everywhere.

And like I said, if we had chosen to rewrite, we could have probably solved all of that. But it wouldn't have been just porting the code. It would also have been like solving a whole bunch of new problems that we had bought ourselves by going that route. We tried. And it just wasn't feasible. You know, and so we were just trying to optimize for, you know, doing as little work as possible. to get us to payout, which is, which, and honestly, Rust is no better when it comes to like the quality of the generated code or the, or the concurrency gains that we could have gotten out of it.

Go is just, it's great. I mean, so, so we got, we got all the bennies for less work by going that route. I know some languages there, when you say they're garbage collected, they, there's something in the language itself that is doing. garbage collection, but there's also independent libraries that can provide garbage collection, right? There is, but it comes often with a whole bunch of restrictions, and it doesn't come necessarily with the safety guarantees that we were looking for.

I mean, like, Go is type safe and memory safe, meaning that you don't get to just, like, have stray pointers or whatever, where, you can do ref count. or you can do all sorts of different strategies. But there's always like that little bit of unsafe where you have to like do this in order to make it all work. You know, where if garbage collection is engineered into the language, it really is a separate concern. That is, you don't have to do anything special in,

I mean, of course, you have to like not hold on to data that you no longer need and whatever, you know, but that's true of ref. counting as well, right? But it is inherent in the language. When you ported it from JavaScript to go, I'm curious how much LLMs were used in that process because I know famously there's some major projects that have been doing rewrites of their entire code base. I know there's this JavaScript project called Bunn that rewrote everything from Zieg into Rust. And so it seems like a pretty useful tactic. And I'm curious if you

leverage that in this process? Not a whole lot, but it also has to do with timing. We started this project two years ago, and two years ago, LLMs were nowhere near as good as they are now. I mean, that's how crazy fast, it's all moved, right? So what we did, though, is we certainly had a bunch of tools that aided us in the port. I'd say the prototypes we wrote, the scanner and the parsum, we wrote manually. And at that point, we could convince ourselves, wow, we can actually get 10x out of this. Now, what do we do with the rest of this codebase? And what we did was we wrote a tool that syntactically translates TypeScript into Go.

This Go that comes out of it, it has no syntax errors in it, but it doesn't compile either because it's full of, you know, like it uses types as if they were TypeScript, which they're not and go. And so all of that had to be refactored. We had to redo all the data structures or whatever, but we got the same code base out of it. And then we can sort of bang on that. And then in a more localized fashion, maybe use AI occasionally to help us do the transformation. So it was sort of manual and automated. And a little bit of AI. Now, if we were to start the project today, would we do it differently, possibly, although I will say if we just let AI loose on, you know, what is it, like a half million lines of code that we have in the old compiler or somewhere between half a million

and a million, right, and asked it to translate it all. Well, I don't know that that would absolve us from then having go in and carefully examining every line that came out of it to make sure that there were no hallucinations, right? Unless you have 100% perfect test coverage, you probably still got to go check all of that. Now, I think a better approach, quite honestly, would be enlist AI to write a program that helps you translate from TypeScript to go. Because at that point, you can part the stochasticness in that program, and then you can get deterministic behavior whenever you run the program, which means you get the same transformation every time you run it. That's always the thing about AI that people forget. It's not deterministic.

So you can't really trust that it's going to do the same thing twice. So we might have done it that way, but AI was not ready to do it at the time. Now, that doesn't mean that we don't use AI. I mean, like now down the line, we use AI a lot in our internal processes around like the compiler, as everyone does, right? Like help it to write tests and to move pull requests and what have you. And whenever an issue was logged, the first thing we do is put copilot on and see if it can fix it for us, right? I mean, so, yeah.

In that approach where you use the LM to generate tooling and then, you know, the tooling's deterministic. But you'd still have to validate that thing. Yes, but that's a lot smaller surface area that you have to validate, right? And honestly, I've seen that even with friends that are like we did some trip together and there was like some accounting. of the, well, he paid for the hotel rooms, and we paid for this and whatever, and we needed to, like, sort it all out, right? And so, okay, well, here's what all the costs were,

and here were the pieces, and I have AI fix it for us, right? Or, like, tell who owes who what. And it very authoritatively came up with the wrong answer, right? Because it just forgot, like, about some of the settlements, right? But if we had asked it to write a spreadsheet, which is really, that's just a program, right? then we would have gotten the right answer because it's very good at writing programs. So it's kind of funny how you don't ask, sometimes you don't ask AI for the answer.

You ask it for a program that computes the answer. What are the potential benefits that you left on the table by doing a port instead of a full rewrite? To be honest, I don't think there are any. And I don't think we would consider a rewrite. We were quite happy. We're quite happy with the way this code base works. and we certainly, I don't think we're leaving any money on the table currently. And as I said earlier, rewrites are toxic often for ecosystems because they sacrifice

compatibility because you never rewrite and you get, you never get back to exactly what you had before, right? Oh, but in the name of making it better or prettier or whatever, we change this and that and this and that and the other, right? And then while all the users get to suffer. through that, right? So backwards compatibility is super important if you want to keep your ecosystem happy. And we do want that. In studying for this interview, I just keep reading about JavaScript and the strange semantics of the language. And I think throughout my career, too, people have typically

not been super satisfied or happy with JavaScript for some reason or the other. And my question is, Why is it so popular despite that? So first of all, I don't think JavaScript is as bad of a language as some people make it out to be. I will say in like the three, what, three, four weeks that Brendan Ike had to create this language back in the mid-90s, he did a lot of things right. And thank God that he had been educated on functional programming and got first-class functions done right, where you can have functions within functions and the inner-function. can access the out of function state,

and you can pass functions around as first-class values. That is super powerful. And JavaScript actually got that very right. Now, there's some quirks in the language, too, like all of the automatic conversions and all of the bizarre differences between double equals and triple equals are just like drives everyone mad, right?

But that's exactly what type checkers are happy to do. They can, like, they can ferret out all the little different because they understand all the deep semantics of the language that no one seems to be able to keep in their mind, right? So, and I think that's part of my TypeScript has become so popular, right? It's like it can actually like truly bring out the best parts of JavaScript and leave the bad stuff behind. And of course, you can't like like the thing about JavaScript is it is the cross-platform language like even Java that was engineered and intended to be the way to write cross-platform language. Like even Java that was engineered and intended to be the way to write. cross-platform applications. It's not really cross-platform.

It doesn't run in the browser. You know, I mean, it doesn't run everywhere, right? JavaScript runs everywhere. So there are a lot of reasons why you should like JavaScript. And with TypeScript, I think we've managed to sort of capture all the badness and park it. I saw there were some projects. I don't know if you're familiar with Dart or... CoffeeScript, and it seems like these were some effort to replace JavaScript or improve it,

but they're not popular today, so I'm curious what happened. I mean, I think CoffeeScript was mostly, it's a different syntax for JavaScript. So it doesn't really change the semantics, and it didn't provide any additional tooling and whatever. And Dart was also, in a sense, about fixing JavaScript, right? But if you can fix something by fixing it instead of trying to replace it with something else, then you're doing the ecosystem a much bigger favor, I think, right? And that's what we set out to do with TypeScript. We weren't trying to change JavaScript.

We were trying to improve JavaScript. And I think that's ultimately why we succeeded. I mean, in this new age where it's very feasible, that maybe AI could rewrite codebases. I imagine people will start to go towards the desired languages rather than the ones that are the incumbent languages. And I'm curious if you think that JavaScript might become less used in the future. See, I don't think so.

What I've observed is that AI is best at the languages if seen the most of in its training set, right? And AI gets trained on all the code that exists in the world, which means there's an awful lot of JavaScript, an awful lot of TypeScript, and awful lot of Python, and therefore AI is good at JavaScript and TypeScript and Python. And it is less good at my favorite little language that I just invented. In fact, there's none of it in the training set, which means you have to sacrifice God knows how many tokens in the prompt to teach AI the language before.

you can even ask it a question about the language. Do you know what I mean? So in that sense, I think incumbent languages are actually, if anything, going to flourish because of AI. And we're sort of seeing that right now with TypeScript, too, right? There's a noticeable knee in the curve of TypeScript adoption that coincides with the advent of AI. I do think the incumbent languages are actually, if anything, getting stronger. What percent of all JavaScript is written in TypeScript?

Well, so in the last year, TypeScript became the number one use language on GitHub. More than JavaScript. More than JavaScript. So more than 50 percent on GitHub at least is written in TypeScript. So we're actually like the larger now than the language that we set out to improve. Wow. Yeah. And larger than Python.

If you were to just draw that out in the future, do you think that eventually TypeScript would become the default and almost 100% of all JavaScript would be typed? Well, certainly, I mean, if you're having AI write it, I almost challenge you to find a tool that writes JavaScript. They all write TypeScript because it helps AI write better code. Because the type annotations guide the LLM towards writing, or twice making fewer mistakes

and the ability for us to statically validate the code before you run it. I mean, that's the distinction, right? The only way you can validate JavaScript is by running it, which means you have to set up a runtime environment which might not be possible for AI to do

because AI lives in a sandbox, right? But AI can run through tools, the compiler and check the code that it just generated and be told, oh, you made a mistake, oh, well, let me fix it then before I even tell anyone that I made the mistake, right? After learning about this 10x improvement and performance from rewriting it in native, makes me wonder why anyone would use JavaScript on the back end. Why not just always use native languages on the back end?

Well, it depends on your problem. I think because the thing that that overlooks is what kind of thing am I going to write on the back end. You know, like, like there are an awful lot of very, very good web server frameworks, for example, that use TypeScript or JavaScript, right? So, so if there are like frameworks in your ecosystem that gets you to a solution quicker, than if you had to write that because your native language wasn't really intended to target that particular community. So I think it very much depends on what your problem is affinitized with.

And often, Perf of your code isn't the bottleneck. I mean, like, look at Python, I mean, right? It's used to basically script and all of the LLM training in the world, right? I mean, which clearly a lot of that code is ultra-time critical, but that's written in native code, right? And then you use Python as the orchestration language. And in a sense, in a website,

server, you know, like TypeScript is just an orchestrator, you know, of talking to a database and doing this and that and the things that, the things that ultimately control the performance of applications like that aren't necessarily whether that inner for loop is running as, as, as native code or not, which actually it is because of the JIT anyway, right? I mean, so, I mean, measure. Measure first and then big decisions, right? because you always get surprised when you measure. When you talk about how much faster it was, too, one of my immediate thoughts is why wasn't it done sooner?

You know, at the time we started TypeScript, I don't know that we had ever envisioned that people would be writing projects that are the size of the projects that people are now writing in TypeScript, right? Like Visual Studio Code is like 2.3 million lines of code. I mean, we have in-house projects that are over 10 million lines of code, which is insanity.

We would have just at the time gone, well, that's clearly no one's ever going to do that, right? But that was a decade ago, or more than a decade ago, right? We started in 2012 with the TypeScript project, and the world looked very different. And so gradually, people have started writing larger and larger and larger projects, right? And at the same time, our compiler has gotten smarter and smarter. We've added all sorts of cool features like union types and discriminating. unions and control flow analysis and blah, blah, blah. And all these things make our type checking even better, but it also makes it go a little slower

every time we add a new feature, right? In fact, our TypeScript 6 runs only about 50% of the speed of TypeScript 1.5, for example. But TypeScript 1.5 also did a whole lot less. So projects have gotten bigger, and the compiler does more, all of which detract from your effective output. And as I mentioned, Moore's Law also unfortunately stopped delivering faster CPUs and JavaScript keeps you from taking advantage of the additional cores. And it's not clear that we could have foreseen all of that, right? But it's just the way it panned out, right? Open AI, Anthropic, Cursor, and Versel all use this product to make their lives better.

And the problem it solves is when you're building SaaS or an AI product, and you want to sell to other companies, there's all these requirements you need to meet. There's SSO, there's SCM, there's Rback, there's audit logs. These are all things that take time to integrate, but aren't the main focus of your app. WorkOS is an API layer that lets you meet all of these requirements in just a few lines of code.

So let's say you have a new SaaS product and you want to sell to other companies. WorkOS will solve all of these critical feature gaps for you. You can check them out at WorkOS.com to learn more and get started, and I appreciate them for supporting my work and sponsoring this podcast. Jira by Atlassian isn't just for tracking work anymore.

Now you can pick your favorite AI agent to assign tasks to, and they'll get access to the rich context that's already in Jira. When the agent is done, it surfaces a poll request. That way, you can get more done with your favorite agents all in one place. Learn more at Jira.dev, that's J-I-R-A dot D-E-V. Appreciate them for you.

for sponsoring the podcast and back to the show. When I first became a software engineer and I went to start working at Facebook at the time, they had this popular framework called Flow, which was doing type inference on top of JavaScript. It was this thing that would think a long time. And then I'd never hear about it these days. So it sounds like TypeScript won if there was a competition to typing JavaScript. There was a bit of it, yeah, in the early days. I think the thing that worked for us was actually the fact that we were self-hosted,

which made it a lot easier for the community to contribute to the project. Flo was written, as I recall, in Camel. And so in order to contribute to Flow, you had to go learn a whole different way of programming and in a different language, right? And Flood also didn't really focus all that much on IDE-based tooling, which we knew full well going in. We're writing a compiler, but we're not writing a compiler

in order to generate machine code. We're writing it to make better tooling. That was why we wrote it. And so right there, hand in hand with a compiler, we had a language service. It was deeply integrated into Visual Studio, Visual Studio code, all sorts of other editors,

through an open protocol, you know, and that just, that's where, that was the problem that needed solving, right? I mean, it's not, it's nice to have a type checker, but boy, you want that, you also want statement completion. You want red squigglys. You want, I mean, you want it interactive, right? So I know in your career you've worked on multiple programming languages.

What does it take to build a programming language? Well, first I'll say that the world needs another programming language like it needs another hole in the head. I mean, it's like you kind of got to be a certain. kind of a person to even embark on it to begin with, right? It's a super fascinating area of computer science, and it's one that's been around ever since the beginning of computers. Now, every compiler, every language, has a whole bunch of things you need to understand,

like parsers and scanners and lexers and co-generators and whatever, right? But that's sort of the mechanics of implementing the language. And then there's the design of the language, sort of the art of making it feel right, whatever, right? And I think you sort of have to master both. And then you also got to appreciate that like every new language is actually only 10% new. And then it's 90% the same drudgery that every other language has to go do. And so be prepared for a lot of work that maybe isn't as interesting, you know. And then finally, maybe I'll say that, you know, like, never forget there that you stand on the shoulders of giants.

I mean, in order to make a great programming language, you've got to understand a bunch of other programming languages first. And I understand all the all the distinctions between the different styles of programming like procedural and object or functional or what have you. And then last but not least, it's like, it's a long game. I mean, it is probably a longer game than anything else. I mean, like every language project I've worked on, I've worked on each of them for at least 10 years and shipped multiple versions. And it's really never until version 3 that it truly starts to get okay.

Do you know what I mean? And it just takes an incredible amount of devotion to that. So you've got to really not be the type of tires of a problem quickly and then moves along. that you're not meant to do language design. And you see that too when you talk to language designers in the industry, they've been doing it for a long time.

You mentioned those two parts. There's the objective pieces that you need to implement, and then there's the art of the design and making the language, I guess, ergonomic for developers. When you think of that second part, that art, and you look at other programming languages, Are there any that you admire outside of the ones that you've worked on, of course? Learning and fully appreciating the beauty of functional programming has been very educational, right?

I mean, because it really is a different way of thinking about programming. A way of thinking of programming is much closer to math than it is to machines. And I think there's a lot of incredible goodness that has, has come from that. And then honestly, even in like building the TypeScript project, large portions of the TypeScript compiler are written in a highly functional style.

And work on immutable data structures that are then now, because of shared memory concurrency, can be shared between different threads or processes that don't mutate the data, and therefore they can share one data structure, right? And that's incredibly powerful. But mastering this, you know, like writing islands of pure functional programming inside an imperative program and putting it together with concurrence. I mean, it's complex.

But I think functional programming has brought a lot to the world. I know object-oriented programming as well, I mean, but I wouldn't single out any particular language. Every one language you come in contact with, you learn something, you know. You mentioned the world doesn't really need more programming languages. And if you think 10 years from now, do you think there'll be less programming languages than there are today? It's hard to say. I mean, but like I said, AI tends to favor the incumbents, right? And I do think, and I think this has been true even before AI.

The bar keeps going up for what it takes. to successfully implement a programming language and create an ecosystem around it. I mean, it used to be, oh, you just need a compiler. Well, wow. You also kind of need tooling now. I mean, you need a language service. You need, you need debuggers, you need profilers,

you need frameworks and libraries, you need code generators that can target all sorts of, I mean, it's like it just keeps getting harder and harder, you know, to get all the way there. Well, when you think about all those pieces that really, they're all for the people, I mean, the IDE and the types. And I mean, the computer looks at that too, but it's so that we can read source.

Maybe one day the LMs will generate machine code directly. I wonder. I think, I think, LLMs are better at what they do when they don't have to repeat themselves a lot. I think like when a program is expressed in text, it is closest to its sort of ultimate condensed meaning and representation, right? If you translate it into machine code, there's an awful lot of noise in that machine code. Like all of the instructions, like half of the instructions are memory addresses that have absolutely no bearing on what's going on here, right?

So half of all the data is noise already, right? And then whichever register you pick, well, that doesn't matter either in the code generator. And honestly, you could change your mind at any point in time. So teasing the truth out of that noise is a lot harder than if you just have a program where the variable is called I and whatever. And by the way, that you can relate to the written instruction that the user just gave you. I mean, keep in mind that, like, AI are, they're just emulators of humans in a sense, right? I mean, it's like neural networks, right?

There's a reason we have programming languages, because we're terrible of writing machine code straight off out of our head, right? AI is not that different from us, you know? So the same would probably be true there. When you look back on working on C-sharp and, you know, TypeScript and these language projects, they were long journeys and I think one thing people might want to know is what did you learn through those journeys

that if you knew at the beginning of when you embarked on working on them you might have been better off. Gosh. Well, each journey is different. I mean, like the first project I worked on Turbo Pascal.

I think that project started back in the old days when it was 8 bit micros and 64K of memory. and one person could do everything themselves and have ultimate control of everything. And so I was very much a one-man shop, right? But that quickly was not scalable, right? And capacities of machines,

we went for 64 to 640K, and then the lid went off, right? And you could have as much memory as you wanted. And so one person couldn't do it. And I had to learn to become a team player, right? And that was a big journey for me. I mean, to learn to let go, right? If you're a perfectionist, that could be hard. But that's one thing that I would say I learned there.

Well, another way to word this question is, you know, what's the most common mistake that you see people make when they embark on building a programming language? Well, I think people tend to over-index on one idea, you know, that they have, that they think, Or wouldn't it be cool if my language could do blah? And then they under-index on all of the mundane stuff that every programming language has to do.

And then it ends up doing that one thing they love, maybe better, but then it does everything else not as good. And the net is a detractor, right? And so it's so hard to convey how many things you have to do that really doesn't have anything to do with the problem. you're trying to solve per se, you know, when you're implementing programming languages. And when you were working on C-sharp, do you keep tabs on the other languages and, you know, what they're doing better, what you could do better with C-sharp?

Yeah, no, you've got to keep yourself informed about it because, like I said, we all stand on the shoulders of giants, you know, no other, no programming language was ever created in perfect isolation, right? everyone learns from everyone, and then someone comes up with a good idea, and then you see it adopted elsewhere, and we've adopted many ideas from functional programming, you know, in C-sharp, for example, and then other languages have adopted some of the good ideas we had in C-sharp, like A-Sync, you know, now is in JavaScript, and in some of the other programming languages out there, and that was pioneered in C-sharp, and so, you know, it's, we all learn from each other, and that's how

the industry moves forward, really. mentioned the I guess learning to let go I think that's something that a lot of people as their career advances they start with individual contributor work and then later they start delegating things how did you learn that or what was the is there like a maybe a story or particular project where you you let go and you you kind of develop that skill well it's it's almost like I got a counter story to the to the letting go there because in the season C. Sharp project, my main function was not implementing the C-sharp compiler. It was being the language designer and writing the spec and designing all the new language features. And before that, when I had

worked on Turbo Pascal, I was doing a bunch of active coding, you know, on the thing itself, right? But then I sort of let go of that, but I let go of it too much. And I sort of drifted up into the stratosphere and became more of an architecture, astronaut. Do you know what I mean? And I wasn't getting my hands dirty. I was writing stuff in the framework and in the libraries, but it didn't quite, these are not like the deep, really super hard problems to solve, right? And I didn't really know it at the time, but I was gradually getting less happy

with the work that I was doing, right? I mean, I still enjoy it, but there was something missing, right? And so when this TypeScript opportunity came along, I decided to jump in and actually actively participating in compiler. And it brought so much happiness to my life. Like I finally realized I'm just I'm just a happy coder. You know what I mean? I like the spec stuff too, but coding is like, man, that's what gets me up in the morning, make coffee and write some code. You know, that's that's when I'm in my happy space, you know.

you know when people are at these really really high levels they kind of have this expectation of a certain level of impact and so how do you continue to write code at as such a high level engineer well the specific code I'm writing isn't necessarily having all all that impact but it's it's the fact that I also do the architectural guidance you know as part of a group of people right in a project you know, there's plenty of work for everyone to go around, and then you just, but you stay involved in a corner of the project, because then you see what happens in the code. You know, when you're checking in your code, you go, what was that over there? Let me just, what's happening over here? You know, or you realize, oh, we need to refactor this. This is not, this is not feeling right anymore. Or if, if you let go of that, you don't really, you can't really talk about the thing that people use day to day. You can talk about the simple. You can talk about the simple. of the thing that people use data, but you can't talk about that thing. You know, so both are important, I think. And I'm happy that I get to do both now.

I know a lot of companies have this idea of engineering archetypes or the way that high-level engineers get some work done. And you mentioned architect, for instance. A lot of companies have different words for architect. I'm not sure if you're saying it's just your working style, Or are you saying that all high-level engineers should be hands-on at some level? No, I'm not saying that because I don't think it's like I made a conscious choice to remain an independent contributor as opposed to become a manager. I mean, I have plenty of opportunities.

But that is not where I do my best work, right? So I think you have to decide for yourself. What is it that motivates you, makes you happy, keeps you doing. this for a lifetime. Do you know what I mean? And you only get one run at it in life here, you know, and so if you're going to do your best work, do the thing that makes you the most happy, I think. And then that's what I learned, you know, along the way there. That coding is part of that, a big part of that. So then when you were working on C-sharp but before TypeScript, Like, how did you know something was missing?

I just knew something. I don't know how, I mean, it just, I just wasn't feeling as fulfilled with only doing the design part, right? I missed the coding. And whenever I had a chance to write a little bit of code, I would feel a lot happier. And I go, it's kind of interesting. I mean, do you know what I mean? But now I got to go write some more specs, you know what? So then was TypeScript something you come?

kind of went towards because you wanted to write more cover? Well, I went towards it for many reasons. I mean, it wasn't specifically that to begin with. I just found the problem fascinating, right? I mean, because the way TypeScript came about was actually indirectly through C-sharp because the Outlook.com team, I think it was, approached the C-sharp group and asked whether we would pretty please productize something called Script Sharp. And script sharp was this thing that took C-sharp.

and transpiled it into JavaScript. So you could run it in a browser. And I'm like, what? Why would you want to do that? Why don't you just write the job? Well, because that way we can get great tooling. Then we can use Visual Studio, and we can have projects, and we can have type checking,

and we can have code refactoring and navigation, and we can write interfaces, and people can understand how this all works. And I'm like, wow, is JavaScript really? that busted? And you're saying like the way you want to fix that problem is by abandoning JavaScript, treating it as an instruction language, right, and then having a code generator targeted. I'm like, couldn't we like fix JavaScript? Wouldn't that be better? Do you know what I mean?

And that's how TypeScript kind of got off the ground, right? It was like, gosh, there's something here that's really broken that needs to be fixed, right? And when it comes to JavaScript tooling. And that's what we set out to do. You know, one thing I thought would be interesting is in one of the talks that you gave, you said that you believe that the speed of your tooling is more important now because of AI. And I want to hear thoughts on why is that the case? Well, more and more workflows now are dominated by agents that are like running away in the background, like writing code for you.

And they make mistakes just like we do, but they, but, you know, but you can have as many of them as you want. So there are like many, many more little workers in the ecosystem writing much more code, right? And that whole workflow is like LLMs already, I have performance challenging. And then if you add like, if you're writing code in a big project and you have to like type check it and it takes two minutes every time the LLM writes something, do you know what I mean? That's horrible, right? So making that go faster is a big benefit. Yeah, absolutely. I guess because it's hammering away.

Yeah, because I mean, like, well, we all know LLMs, they like to use grep and whatever, right? But then they're also smart enough now to realize that if you're like trying to change this property called version, and like every other object has a version property, you can't just grep for version and then go rename. it to something else because like you're breaking all these other interfaces that have a version in them right so you got to do semantic search and the only thing that can do semantic search is a compiler and so you got to use the compiler through typically through LSP through language services or through our command line tool that would give you the equivalent right and so more and more AI is doing that

and that means you know compilers run at You may not even see that they're running, but they're running. And they're doing work on your behalf. When you talk about AI, it's very realistic and grounded in the software engineering. And so I thought it might be interesting to run some common AI takes that I hear from the Internet. And get your sense of how accurate is this? What are your thoughts on when or if it'll be true? Okay, so the first one that I've heard, this is more common at the end of last year,

is that, you know, AI is going to write 90 plus percent of the code, you know, within a year. Curious what you think on that. Well, for certain classes of apps, that might be like all the Vite code of the apps, they're writing 100% of the code, right? And there's an awful lot of that being written. Are they going to write 90% of the high quality code on the Internet? I don't know about that. So the thing is like 90% of what?

The volume of written code is just like going like that right now, right? Because AI writes so much code. So in a sense, that's a self-fulfilling prophecy, right? I mean, but when it comes to like the super high quality code that no one has ever written before, it's not clear to me that AI is going to write 90% of that. So when you think about cases that AI is not writing all the code, maybe some examples of the super high quality stuff, what is that? Well, I mean, it's algorithms that no one has ever seen before, for example,

or particular solutions. I mean, I know that AI could not write our compiler, the typescript compiler. It just can't. I mean, we've tried. It can't do it. And I'm not asking it to either. I mean, I'm not expecting it to either. But our compiler is also not a typical piece of code.

I mean, that's why it's bad at writing it, because it's seen none of it in the training set. Well, I've seen some compilers, but not like this one, not with these concepts, not with done the way that we're doing it, right? And so it's just not a good fit there. AI, we can't forget that AI is at heart, a big stochastic machine that has memorized the entire internet, right, and has an ability to extrapolate somewhat over what it's memorized,

right? But if it hasn't seen it before, it's not necessarily going to be all that good at doing it. It's getting better. I mean, I'm not saying it's not impressive. It's wildly impressive what it can do. But I just think there's a long way still to it's doing all of it. And I don't know that we get there. I hope we don't because then what's the point of humans anymore then? I mean, it's... What I see this take off in too is, you know, you won't need to use an IDE within the year or you don't need to read the code anymore. Well, good luck to you. I mean, if you're going to hand AI the keys, I mean, then all bets are off, right? I mean, the minute AI, you can't convince AI to fix this issue or this new feature that you want built. What are you going to do?

I mean, if you don't understand what's below, right, that's one problem. The other problem is, let's say a user comes to you and goes, your app just stole my bank account. Well, it's going to sue you. They're going to sue you, not the AI. I mean, it's like at the end of the day, someone has to take responsibility for what AI is doing. And if you're giving it the keys, well, it's on you, you know, but I don't know. I personally would not feel comfortable. I wouldn't be able to go to sleep at night.

I mean, if I didn't understand what it is that I am vouching for. Why is there such a big difference between this opinion and what I see from maybe people who work anthropic? Well, the difference is all I'm saying here is not that AI can't do amazing things. It does. It can. It does that every day. But people love these, like, take it all the way to 100%, right?

And that's where I get off the bus a little bit, right? I think, oh, yeah, okay, fine. We can get higher and higher percentage. But there still has to be someone understanding what's going on and how it's relevant to our business problem and how it relates to what our organization is doing. And there's so many other things that have to be connected, that I think it's wrong to just view it as,

AI did it all and we were completely unnecessary, you know. Yeah, the next one I was going to ask you was, you know, three years for now, will AI replace junior software engineers or what junior software engineers do today? Well, if it does, then how do you ever get senior software engineers? Right? I mean, it's like, I don't think so. Well, I'm not unless you also believe that you will be able to do your business three years later than that without any senior software engineers.

Right. Because where are they going to come from? You gotta train them. I mean, but to me, I think maybe one thing that to some extent has happened is that for certain classes of programmers, the pyramid has narrowed at the bottom, right? There are fewer people coming in, and we are wanting them to advance higher up faster so that they can get to this more supervisory role, right? I think the craft of being a software engineer is definitely changing from your typing in lines of code to you're having agents type in lines or code and you are reviewing the work of the agents, right?

And so you do more of reviewing, less typing. And some people love that, you know, and really are fantastic at that workflow, right? But it's a change in nature of what the job looks like as a programmer. And this tool that you now have in a toolbox is having that impact, right? But it is but a tool. And there are still programmers involved in the process that I firmly believe. Sounds like you enjoy typing out the code. Would you be less happy if five years from now?

For 40, 50 years, I have enjoyed typing out code. I'm actually, there, there, some, and so I will continue to type certain parts of the code, you know, but there are other parts of the code that I don't particularly care to type. I don't care to type in tests and follow all the rigor of the particular testing framework. Heck no, if I can farm that out to AI, happy me, you know. I do think reviewing has always been harder for me. It's harder for me to, like, spend time on reviewing other people's code and it is, you know, writing the code. But I also think that over time, we can make that process of reviewing code much more ergonomic than it is today, right?

I mean, often today you just get, here's like the list of the files that were changed, and here are the deltas. You figured up, right? I mean, AI could help us more there by explaining what the changes are and whatever, and so I think we're going to get better. This is going to get more interesting, but it will change the nature of the craft. You said that you've been writing code for 40, maybe 50 years. What is the hardest piece of code you've ever written? Or what's the most technically challenging thing you've ever done? There are so many things that in their time were challenging, you know.

I mean, this last project we worked on, we knew that like, like, you know, sort of the easy part was getting the native code. That's just like, just move it to this other language, right? But then this taming this beast called shared memory concurrency and getting the compiler to use, like as many CPUs as there are available on your box, right? That is not a simple problem to solve in a compiler. Because we're all taught to write sequential stuff, right? I mean, first you do this, then you do this, but how do you do? do all of this at the same time and then share the data structures afterwards without anyone

like accidentally modifying the other guy's data structure and, you know, in the cases where you have to do that, how do you then synchronize it and avoid deadlocks and race conditions and whatever, right? This, it was tricky. There were some good technical problems that we lick that I think we can be proud of, you know, but. What about when hardware was more constrained earlier in your career? Is there any wacky thing you had to do to kind of, you know, make it work?

Oh, totally. I mean, when I started, it was a bit like being a programmer was a very, very different thing, right? I mean, I started out with 8-bit micros that had Microsoft Basic in ROM, right? And then that basic interpreter and you could buy these books and type in these Star Wars games or whatever. They were all text, you know, it was just scrolling and telling you there's Klingons over in that conference. quadrant, you know, and K4, you know, and you got it, whatever, right? But I got fascinated with understanding how it was all put together and quickly learned how to write assembly code.

And Turbo Pascal, the first product I worked on, was all written in Z80 assembly code. The compiler, the editor, the runtime library, everything was assembly. and writing structured, a compiler in assembly code is like that that was like took a lot of fiddling, you know, and I mean, and you were counting like, okay, I think I can, I need to, we need to squeeze this into this e-prom and then there's only 12K, you know, and I'm 20 bytes over budget here. Oh, but I can make this jump, this long jump. Instead, I could jump to this short jump and then jumps to that jump. And then I could save one. That's one bites. saved, okay, you know, moving right along. And you would, you would just like sit in there fiddling, you know, it was a craft. It was like woodworking almost. I mean, it's just so different from what we do now, right? Everything is now, it's bottomless pits of capacity and bottomless pits of expectation from users, right? Is there a top technical book recommendation you have for software engineers? I usually recommend the same, but the one book that was like

the It book for me when I was younger, and it's called Algorithms plus data structures equals programs by Nicholas Vieth, the inventor of Pascal, and then later Modula and Oberon and whatever. And it's a book that is light on math and symbolism and rich in instructive examples and good explanations about how data structures work. I mean, that's how I learned about hash tables, right? I mean, like, when you're self-taught, you don't know about hash tables. You sort of know about linked lists, right? And fine. So in the original version of Turbo Pascal, all the symbol tables were just, well, they were just linked lists, you know, or whatever.

And then, of course, as you had many local variables, well, you're going exponential in search time to, you know. And then I read about these hash tables and like, wow, what? You mean, I can, like, just do this? and then like it's basically like linear lookup time and implemented and the compile went twice as fast, right? I'm like, holy cow. You know, that was useful reading, do you know what I mean? So I was always like the engineer.

I mean, and understanding how to do error recovery, he explains that in like how you construct a simple compiler and then like, you know, and it's, it's, it was for me a great book. But and now it's actually like, I mean, it's just a big PDF you can download it out there. It's out of print since 40, 30 years. Last question for you is with all the experience that you have now, if you go back to yourself when you just entered the industry and give yourself some advice, what would you say?

Well, I, a couple of things maybe. Like we talked about being a team player. You know, I would have probably tried to educate myself a bit more about that to, to begin with. I think also one thing in retrospect is like, don't let people tell you that it can't be done. When they tell you it can't be done, it's because they can't do it.

That doesn't mean that you couldn't possibly do it. Do you know what I mean? So don't let that discourage you. Is there a project where you, someone said you couldn't do it and then you did it and that's how you? Well, I think the first thing I worked, on like Turbo Pascal, people were telling me, whenever we told them, here's what we have,

they said, that can't be done. That's like, nah, you guys are you full shit. That's like not possible. You know? Well, it was. And I didn't know that it wasn't possible, right? Awesome. Well, thank you for your time.

I really appreciate it, Andrew. You're welcome. This is a lot of fun. Hey, thank you for watching this podcast. If you liked it and you want to see the show grow, please support with a comment or a like. Also, if you have any recommendations for people, you want me to bring on. Please drop a comment. Guests like Barbara Liskov, Mike Stonebreaker,

Mark Brooker, these were all people that I brought on because someone left a comment. On another note, aside from the podcast, I'm working on building the ergonomic keyboard that I wish existed. Here's a glance at the prototype. It's a split keyboard. So there's two sides. This is in the case. But yeah, we launched on Kickstarter and we hit our goal within eight hours of launching. I really appreciate it if you were one of the people who grabbed one of the early units. We're now working on the long journey of building the tooling now. And so if you still want to pick one up, I've left the late pledges open on Kickstarter. So you can grab one there. I'll put a link in the description. Thank you again for watching the podcast and I'll see you in the

next episode.