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

29:01But 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 discriminated 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.

29:40But 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. But it's just the way it panned out. Right. OpenAI, Anthropic, Cursor, and Vercel 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.

30:25There's SSO, there's SCIM, there's RBAC, 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.

31:07When the agent is done, it surfaces a pull 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 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 take 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 type in JavaScript.

31:47There 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. Flow 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 Flow 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.

32:28That was why we wrote it. And so right there, hand in hand with our 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. 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 wanted red squigglies. 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.

33:13I mean, it's like you kind of got to be a certain kind of 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 code 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.

34:08And 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 understand all the distinctions between the different styles of programming, like procedural and object-oriented 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 um 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 and it just takes an incredible amount of devotion to to that so you gotta really not be the type that tires of a problem quickly and then moves along that you're not meant to do language design and you see that too if 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 the objective pieces that you need to implement and then there's the the art of the design and making the language i guess ergonomic for developers.

35:36When 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 that's much closer to math than it is to machines. And I think there's a lot of incredible goodness that 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, It can be shared between different threads or processes that don't mutate the data, and therefore they can share one data structure, right?

36:38And 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?

37:19It'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, you also kind of need tooling now. I mean, you need a language service, 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.

38:07Well, when you think about all those pieces, they're really 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 LLMs will generate machine code directly. I wonder. 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.

39:09So half of all the data is noise already. 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, 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 at writing machine code straight off, out of our head, right?

39:50AI 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 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 microcom. 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 then and capacities of machines that we went for 64 to 640k and then then kaboom the the lid went off right and you could have as much memory as you wanted and so not one person couldn't do it.

40:59And 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, oh, 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, you know.

41:39And 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. 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 got to keep yourself informed because, like I said, we all stand on the shoulders of giants.

42:21You 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 Async, 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, we all learn from each other. And that's how the industry moves forward, really.

42:57You 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? Is there like maybe a story or a particular project where you let go and you kind of develop that skill? Well, it's almost like I got a counter story to the letting go there. Because in the 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.

43:41and before that when I when I had worked on Turbo Pascal I was I was doing a bunch of active coding you know on 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 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?

44:19I mean, I still enjoyed it, but there was something missing, right? And so when this TypeScript opportunity came along, I decided to jump in and actually actively participating, right, in compiler, and it brought so much happiness to my life. I finally realized I'm just a happy coder. You know, 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 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.

44:56And so how do you continue to write code as such a high-level engineer? Well, the specific code I'm writing isn't necessarily having all that impact, but 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? Or you realize, oh, we need to refactor this.

45:36This is not feeling right anymore. But if you let go of that, you can't really talk about the thing that people use day to day. You can talk about the syntax of the thing that people use day to day, but you can't talk about that thing. 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?

46:21No, 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 that's what I learned, you know, along the way there, that coding is part of that, a big part of that.

47:09So 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, 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, that's kind of interesting. I mean, do you know what I mean? But now I got to go write some more specs, you know? So then was TypeScript something you kind of went towards because you wanted to write more code? Well, I went towards it for many reasons.

47:49I mean, there 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.

48:39And 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 target it. 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. 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.

49:26And I want to hear your 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, right? I mean, like writing code for you. And they make mistakes just like we do, 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 have performance challenging. And if you add like if you're writing code in a big project and you have to like type check it, it takes two minutes every time the LLM writes something.

50:07Do 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.

50:46And 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.

51:30to 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 AI is going to write 90 plus percent of the code within a year. I'm curious what you think on that. Well, for certain classes of apps, like all the Vitecoded apps are 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?

52:15Because 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.

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

53:48It'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 ever 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 often 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 gonna do I mean if you don't understand what 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 gonna sue you it's not they're gonna sue you not the AI.

54:50I 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 at 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?

55:36And 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, hey, I did it all and we were completely unnecessary. Yeah, the next one I was going to ask you was, you know, three years from now, will AI replace junior software engineers or what junior software engineers do today?

56:13Well, if it does, then how do you ever get senior software engineers? Right? I mean, I don't think so. Well, 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 got to 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?

56:57I think the craft of being a software engineer is definitely changing from you're typing in lines of code to you're having agents type in lines of code and you are reviewing the work of the agents. Right. And so you do more reviewing, less typing. And some people love that, you know, I mean, 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. But it is but a tool. And there are still programmers involved in the process. That I firmly believe. It sounds like you enjoy typing out the code.

57:46Would you be less happy if five years from now? For 40, 50 years, I have enjoyed typing out code. I'm actually, there are 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 than 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?

58:33I mean, often today you just get, here's like a list of the files that were changed and here are the deltas. You figure it out, 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. I mean, this last project we worked on, we knew that sort of the easy part was getting the native code.

59:20That's just like, let's 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 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, how do you in the cases where you have to do that, how do you then synchronize it and avoid deadlocks and race conditions and whatever?

1:00:05Right. This it was it was tricky. There were some good technical problems that we licked that I think we can be proud of, you know. 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 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 the Basic Interpreter. and you could buy these books and type in these Star Wars games or whatever. They were all text, you know, just scrolling and telling you there's Klingons over in that quadrant, you know, and K4, you know, whatever, right?

1:00:55But I got fascinated with understanding how it was all put together and quickly learned how to write AssemblyCo. 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 EEPROM 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.

1:01:38Instead, I could jump to this short jump and then jumps to that jump. And then I could save one, that's one byte saved. Okay, you know, moving right along. And you would just like sit 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 like, 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 Niklas Wies, the inventor of Pascal, and then later Modula and Oberon and whatever.

1:02:25And 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?

1:03:09You 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, understanding how to do error recovery, he explains that in like how you construct a simple compiler. And then like, you know, and 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. Yeah. Yeah. Last question for you is with all the experience that you have now, if you go back to yourself and you just entered the industry and give yourself some advice, what would you say?

1:04:01Well, 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 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 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.

1:04:46That's like, nah, you guys are beautiful as 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, Andrews. You're welcome. This was 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.

1:05:20On 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.

1:05:52Thank you again for watching the podcast. And I'll see you in the next episode.