Anders Hejlsberg Rewrites TypeScript Compiler in Go

Anders Hejlsberg 使用 Go 重写 TypeScript 编译器 TypeScript 通过使用 Go 重写其编译器实现了十倍的性能提升，因为 JavaScript 的单线程事件循环和内存模型构成了无法避免的执行瓶颈。 Anders Hejlsberg 剖析了将 TypeScript 编译器从 JavaScript 迁移至 Go 背后的工程考量，解释了单线程运行时瓶颈、循环图数据结构以及单核摩尔定律的终结为何使 Go 成为优于 Rust 的理想目标，同时排除了不向后兼容的全新重写方案。他详细介绍了他们采用确定性语法转译器而非原生大语言模型的迁移策略，并告诫不要依赖随机性工具进行大规模重写。Hejlsberg 还评估了 AI 的实际影响，指出尽管智能体会生成大量脚手架代码并需要极快的编译器反馈循环，但人类工程师在系统理解、新颖架构以及现实中的法律和商业问责方面仍然不可或缺。最后，他分享了数十载职业生涯的心得，强调了坚持亲自动手写代码、避免成为脱离实际的“架构宇航员”的价值。 TypeScript 编译器通过使用 Go 进行原生重写实现了 10 倍的性能提升，支持跨多个 CPU 核心的共享内存并发，克服了单线程 JavaScript 的性能极限。 (7:29) 之所以选择 Go 而非 Rust，是因为 TypeScript 编译器严重依赖 AST 节点与符号表之间的循环引用图，如果不彻底重构内部内存模型，自动垃圾回收就成为必不可少的特性。 (12:16) 面对 50 万至 100 万行代码的编译器迁移，团队构建了确定性语法转译器，而非依赖批量大语言模型翻译，从而避免了在庞大代码库中审查幻觉 Bug 所带来的无法承受的负担。 (14:49) 自主编程智能体的兴起使得快速的编译器工具链变得更加关键，因为机器调用语义类型检查和重构工具的频率远高于人类，使延迟成为了主要瓶颈。 (49:14)

Anders Hejlsberg argues that porting the TypeScript compiler to Go unlocks essential multi-core concurrency while preserving ecosystem compatibility, and contends that artificial intelligence will augment software engineering rather than replace human developers. Native Compiler Migration: Choosing Go Over Rust (7:29) The TypeScript compiler was originally self-hosted in JavaScript to establish an immediate feedback loop and run across platforms. However, codebase scale exploded—with projects like Visual Studio Code reaching 2.3 million lines and enterprise repositories exceeding 10 million—while compiler throughput dropped by roughly 50% between versions 1.5 and 6 due to advanced features like control-flow analysis and discriminated unions. Because JavaScript is single-threaded and worker communication requires expensive serialization, the team needed native multi-core execution to exploit modern hardware as single-core clock scaling plateaued. Rather than launching a greenfield rewrite—which Hejlsberg describes as toxic to ecosystems due to behavioral drift and broken compatibility—the team pursued a faithful port. Go was chosen over Rust because the TypeScript codebase fundamentally relies on automatic garbage collection, closures, and heavily cyclic memory structures. AST parent pointers, recursive types, and scope-linked symbol tables conflicted with Rust's borrow checker, whereas Go provided built-in garbage collection and shared-memory concurrency without requiring a complete redesign of the internal memory model. Deterministic Migration and Parking the Stochasticness (14:49) Migrating a codebase spanning 500,000 to 1,000,000 lines of code required strict architectural discipline rather than trusting large language models with bulk translations. After hand-written scanner and parser prototypes demonstrated a potential 10x performance improvement, the team built a deterministic compiler that translated TypeScript syntax directly into syntactically valid Go. Engineers then manually refactored the structural type system, utilizing AI tools only for targeted, local transformations and unit tests. Hejlsberg outlines a core design principle: developers should prompt models to produce deterministic programs rather than relying on raw probabilistic outputs. Because LLMs are stochastic and can authoritatively invent incorrect answers, asking an AI to generate a translation tool or a calculation script "parks the stochasticness" inside a verifiable artifact. This narrows the human review surface to inspectable code rather than auditing massive, non-reproducible outputs. Tooling Feedback Loops and Language Incumbency (23:28) Hejlsberg challenges predictions that AI will allow rapid transitions away from flawed legacy languages, arguing instead that AI acts as a moat for incumbents. Because models reflect open-source training data, they excel at established languages like JavaScript, TypeScript, and Python while struggling with niche alternatives. TypeScript surpassed JavaScript and Python as the primary language on GitHub partly because static type annotations constrain LLMs, reducing hallucinated errors and allowing automated static check-and-repair loops before code is delivered to users. Furthermore, the emergence of autonomous AI agents demands ultra-fast developer tooling. Agents iterate by generating speculative edits and invoking compilers to validate AST semantics and resolve shared property names where simple text searches fail. If compiler diagnostic cycles take minutes instead of sub-seconds, background agent swarms become unusable. Novel Architecture, Liability, and Engineering Roles (53:00) Hejlsberg rejects forecasts that AI will automate 90% of novel software engineering or render IDEs and human comprehension obsolete. Current generative models rely on training distributions and struggle to design novel algorithms or specialized architectures, such as compilers. Additionally, organizational accountability demands human oversight: when applications cause financial or operational damage, legal liability rests on the engineering organization, not the model. Addressing the career ladder, Hejlsberg warns that eliminating junior developers would destroy the talent pipeline required to produce future senior leaders. While the craft is shifting away from typing raw syntax toward directing agents and reviewing file diffs, human engineers remain essential for connecting technical implementation to domain constraints, business architecture, and final system accountability. While Hejlsberg embraces automated assistance for repetitive tasks like test generation, he maintains that deep systems engineering requires human architectural design. The continuing transition toward agentic workflows makes sub-second compiler performance vital, leaving the software industry to navigate the challenge of improving code review ergonomics and training early-career engineers in an automated environment.

[0:00] Anders Hejlsberg: People love these like take it all the way to 100%, right? And that's where I get off the bus. [7:29] Anders Hejlsberg: 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 compute-intensive workloads or else we're leaving money on the table. [17:11] Anders Hejlsberg: It very authoritatively came up with the wrong answer... because it just forgot like about some of the settlements. 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. [21:15] Anders Hejlsberg: We weren't trying to change JavaScript; we were trying to improve JavaScript. [32:59] Anders Hejlsberg: the world needs another programming language like it needs another hole in the head. [32:59] Anders Hejlsberg: it's really never until version three that it truly starts to get okay. [43:52] Anders Hejlsberg: I wasn't getting my hands dirty. I was writing stuff in the framework and in the libraries, but... 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... 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. [47:10] Anders Hejlsberg: I'm like, what? Why? Why would you want to do that? Why don't you just write JavaScript? '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 target it. I'm like, couldn't we like fix JavaScript? Wouldn't that be better? [63:50] Anders Hejlsberg: 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. [63:50] Anders Hejlsberg: Whenever we told them here's what we have, they said that can't be done. That's like, 'Nah, you guys are full of... that's like not possible,' you know. Well, it was. And I didn't know that it wasn't possible, right?

[0:00] Don't let people tell you that it can't [0:02] be done. [music] When they tell you it [0:03] can't be done, it's because they can't [0:05] do it. [0:06] >> This is Anders Hilesberg, the creator of [0:08] Typescript and C. And we talked about [0:10] how Typescript recently became [music] [0:12] 10 times faster through a native [0:14] rewrite. [0:15] >> Couldn't we like fix JavaScript? [music] [0:17] Wouldn't that be better? [laughter] [0:19] Do you know what I mean? [0:20] >> If you think about Rust, what didn't it [0:22] have that if it had it, you would have [0:24] picked it? [0:25] >> I mean, I think there are two things. [0:26] [music] Um, if you're going to hand AI [0:29] the keys, I mean, then all bets are off, [0:32] right? [0:33] >> Why is there such a big difference [0:34] between this opinion and what I see from [0:38] maybe people who work at Anthropic? [0:40] People love these like take it all the [0:43] way to 100%. [music] Right? And that's [0:45] where I get off the bus. [0:47] >> Here's the full episode. [0:51] The big thing that we're going to talk [0:53] about here is obviously TypeScript 7 [0:55] with the native rewrite. And the first [0:58] thing that I think of when I see this [0:59] was I didn't even realize that the [1:02] compiler was written in JavaScript to [1:03] begin with because I don't usually think [1:05] of compilers being written in you know [1:08] highle dynamic languages. [1:10] >> Yeah. No. [1:11] >> So why was Typescript written originally [1:14] the compiler written in JavaScript? [1:17] >> No, it's a good question. Uh, and [1:20] honestly, if you had told me like before [1:23] the TypeScript project started that [1:24] Anders you're going to be writing [1:25] compilers in JavaScript, I'm like, "No, [1:27] no, I'm not." But I mean it it it you [1:31] know the original prototypes for for [1:34] TypeScript um the Strata project as it [1:36] was called in the in the very early days [1:39] was actually written in C because it was [1:42] like an adapt adaptation of the the [1:45] parser the JavaScript parser that we had [1:47] in IE and whatever and and then we moved [1:50] to to JavaScript but we wrote it sort of [1:52] C style. Um but why did why did we go [1:56] with JavaScript? Well, I mean, if you [1:59] can self-host in the ecosystem that you [2:03] want to be a part of, then that is just [2:05] dramatically better than putting [2:07] yourself outside the ecosystem and [2:09] trying to target that ecosystem. Do you [2:11] know what I mean? Because by writing it [2:13] in Typescript, we were also [2:17] daily users of Typescript and daily [2:19] users of the tooling that we were [2:20] building. And whenever something didn't [2:22] work right, we knew it immediately. And [2:24] whenever something didn't perform right, [2:26] we knew it, you know. And so so in the [2:29] early in the early years, it was it was [2:31] a huge uh boon I think. And then of [2:35] course [2:37] JavaScript runs everywhere, right? And [2:38] that meant automatically our compiler [2:40] could run on every platform anywhere [2:42] even in the browser right uh had we gone [2:45] with a native code solution at that time [2:47] it wouldn't have been possible to run it [2:49] in the browser. Now we have web assembly [2:51] or wom you know but that didn't exist at [2:54] the time right um so so it was it was a [2:58] meaningful choice uh and honestly [3:02] at that time also people didn't really [3:04] realize how fast JavaScript had gotten I [3:08] mean it used to be very slow and then [3:10] Google did all of their excellent work [3:12] with V8 and got it to within two or 3x [3:16] of of native code which is pretty darn [3:18] impressive. Um, and it was like full [3:22] well possible to write compilers in in [3:25] JavaScript. Um, and you could even get [3:28] them performant. Uh, because often [3:31] it's the algorithms that determine how [3:33] performant you are. It isn't necessarily [3:34] the runtime environment, right? I mean, [3:36] it's a combo, but but yeah. [3:38] >> Is there anything unique about the [3:40] TypeScript compiler? like you know I [3:43] think of a compiler I think of clang or [3:46] or you know one of those ones that is [3:48] used for maybe C, C++ or those static [3:51] languages. What's unique about the [3:53] TypeScript compiler when it was written [3:55] in JavaScript compared to these native [3:59] uh compilers? [4:00] >> I think there are a couple of things [4:02] that are pretty unique about [4:04] TypeScript's compiler. First of all, it [4:07] doesn't target machine code. targets [4:09] JavaScript [laughter] [4:11] and and some people call that a [4:12] transpiler and in a sense you know the [4:15] the compilation phase is mostly about [4:17] removing the type annotations and [4:19] turning your TypeScript back into [4:21] JavaScript. Right now in the early days [4:24] also an important part of of the [4:27] compilation process was to downlevel [4:29] your JavaScript meaning [4:32] all of the runtime environments at the [4:34] time were not evergreen. uh and [4:36] sometimes people were lagging like [4:38] multiple years behind on which level of [4:41] the standard was implemented and for [4:43] example when classes got standardized [4:46] most JavaScript runtimes didn't [4:47] implement classes but it turns out that [4:49] you can downlevel to constructor [4:51] functions and and trans transform the [4:54] code and so part of what we did was this [4:58] transformation down level transpiling of [5:01] the code but then of course the type [5:03] checking uh is is the big thing that we [5:05] loop and the type checker in in [5:09] Typescript is also quite unlike any [5:11] other type checker uh in other [5:14] compilers. Typically type checkers exist [5:17] in compilers to guide the code generator [5:21] um because you want to know are we [5:23] dealing with a float or an in or a [5:24] string here so we can generate you know [5:26] the correct machine instructions for [5:28] that data type etc etc. That's not the [5:31] case in in Typescript. In fact, since we [5:34] erased the types, the types have no [5:36] impact whatsoever on the runtime [5:38] behavior of the code. They purely exist [5:41] for for tooling sake and for the [5:45] developer sake and to guide things like [5:48] statement completion and refactoring and [5:50] code navigation, which is a whole [5:52] different thing. Um, and also they don't [5:56] necessarily have to be there. Uh, and so [5:59] Typescript has a gradual type system. [6:01] you can sort of have half of your code [6:02] have types and the other half is just [6:04] any um that we don't check. Now very few [6:09] languages have anything like that. So, [6:13] so it's very it's a very different [6:14] compiler in in in that sense, you know, [6:16] and a very different language in in that [6:18] sense. Um, that actually made it [6:20] fascinating to work on because we were [6:22] solving problems that no one had solved [6:24] before, you know. [6:25] >> I know a lot of compilers, you know, [6:27] they take the the higher level code and [6:29] they typically apply optimizations as [6:31] well. Maybe, you know, they unroll loops [6:34] or they get rid of duplicate [6:36] instructions, simplify things. Is [6:38] anything like that happen in the [6:40] TypeScript to Java compilation process? [6:44] >> Very little. Um, like I said, when we do [6:47] the down leveling, there there's some [6:50] transformations that that that go on [6:52] that are that are complex, but it is [6:55] less and less the thing that's important [6:57] about Typescript. And in fact, a lot of [6:59] people use TypeScript only for the type [7:01] checker. uh and then they use some [7:05] bundler like ESB build or SWC or [7:08] whatever to package their app, erase the [7:10] types, do whatever needs to be done in [7:13] order to make it runnable in in in the [7:15] browser. And so we're not really there [7:18] to optimize your your code for runtime. [7:21] We're there to make you more productive [7:23] as a developer or make AI more [7:26] productive as a as a developer. [7:29] So with the the native rewrite of this [7:32] originally fully JavaScript compiler, [7:35] what was the problem you were trying to [7:37] solve with the rewrite and why did you [7:40] end up write rewriting it in native [7:42] code? [7:43] >> Well, I mean the the problem we were [7:44] trying to solve it's real simple [7:46] performance and scalability. JavaScript [7:48] was never really optimized for compute [7:52] inensive workloads like compilers, [7:54] right? JavaScript is more about creating [7:57] UI that runs in a browser. Was [7:59] originally intended for just like maybe [8:02] a 100 lines of code, but now of course [8:03] it's gotten to be a lot more. Um, but [8:06] it's not it's not a place that that you [8:09] would optimize for um for the kind of [8:13] workload that that we are. So in [8:16] JavaScript, first of all, you pay a 2 to [8:19] 3x perf penalty compared to native code. [8:22] I mean it depends on on the workload you [8:24] know but that's but if if you're doing [8:26] compute that's about where it's at. Um [8:30] and then secondly in JavaScript there [8:32] are a lot of restrictions around use of [8:34] concurrency. Uh JavaScript was always [8:38] engineered in fact to be a single [8:40] threaded language. That's why we have [8:41] callbacks and async and and and [8:43] whatever. It's because you can't spin up [8:45] threads. Um, and that's a good thing [8:49] mostly because concurrency in a language [8:52] with mutable data is very very hard [8:55] because you can have races and deadlocks [8:57] and all of this good stuff, right? [8:58] That's why functional programming [9:01] languages are easier with concurrency [9:03] because all the data is immutable and [9:05] it's much easier to reason about. Um [9:09] so JavaScript doesn't give you access to [9:12] concurrency other than web workers and [9:15] but web workers can't share data between [9:18] each other other than by remoting it. So [9:20] you can you can have one web worker [9:22] compute some something, but if it wants [9:24] to give it to some other web worker, it [9:26] has to turn it into JSON or it can't [9:29] just hand it objects. And that means you [9:32] can't have one worker compute some data [9:36] structure and then have someone else use [9:38] it. In other words, you can't have [9:40] shared memory concurrency. And really [9:42] that's what we wanted in order to gain [9:46] all of the perf that we were leaving on [9:48] the table by not utilizing multi-core [9:50] CPUs that everyone has today, right? [9:53] Because Moors law has stopped giving us [9:56] faster CPUs. It's giving us more CPUs [9:59] and we got to like find ways to use them [10:01] in our in our compute intensive [10:02] workloads or else we're leaving money on [10:04] the table. And so we were leaving money [10:05] on the table in multiple ways, right? [10:08] And so native code and that was why we [10:11] we looked for a language that [10:15] would get us out of both of those binds. [10:17] It had to be native and it had to have [10:19] access to shared memory concurrency. [10:21] >> I saw for the language choice you went [10:23] with Go. And when I think of all the [10:26] systems languages, the ones that are [10:28] often hot or maybe you know Rust or [10:31] Zigg, why did you choose Go for the [10:34] native rewrite? I think the decision [10:36] process was actually pretty structured. [10:39] You know, the first decision we made was [10:43] we're not going to rewrite. We're going [10:44] to port because only by porting can we [10:48] preserve the semantics and the [10:49] algorithms and the exact behavior of our [10:52] existing compiler which everyone depends [10:55] on for backwards compatibility. Now we [10:57] could have we could have cleaned the [10:59] slate and started completely from [11:01] scratch but we would have come we would [11:02] have come up with a different language [11:04] in the sense that it would give you [11:06] different errors or behave differently [11:07] in certain situations where it has to [11:09] make choices between multiple [11:12] possibilities and and what have you. [11:14] Right? So we wanted to port and that [11:17] meant our code makes certain assumptions [11:21] like our code for example assumes the [11:23] existence of garbage collection. It [11:26] assumes the existence of first class um [11:31] uh treatment of functions. You know, you [11:33] can have functions within functions and [11:34] you can close over over out of state and [11:36] so forth. Um and as we evaluated all of [11:40] these, [11:42] Go was was the one that checked the most [11:44] boxes. You know, it gives us it gives us [11:48] very robust and mature native code [11:51] generation on all major platforms. it [11:54] has garbage collection and it has access [11:58] excellent access to shared memory [11:59] concurrency. Um, and those were like the [12:02] high order bits that we wanted to check [12:04] and every other language had something [12:08] that kind of worked against those [12:10] objectives. So for this particular [12:12] workload, Go was the right was the right [12:13] choice for us and it's worked out well. [12:16] >> If you think about Rusk, what didn't it [12:19] have that if it had it, you would have [12:21] picked it? I mean I think there are [12:23] there are there are two things um it [12:26] doesn't have uh garbage collection [12:29] it's done manually you know uh well or [12:33] it's done through the borrow checker but [12:35] the borrow checker doesn't allow [12:36] circular data structures and our [12:39] compiler is chalk full of circular data [12:42] structures we have trees with parent [12:43] pointers we have types that are [12:45] recursive we have symbols that refer I [12:47] mean it's everywhere and like I said if [12:50] we had chosen to rewrite we could have [12:52] probably solved all of that, but it [12:54] wouldn't have been just porting the [12:56] code. It would also have been like [12:57] solving a whole bunch of new problems [12:59] that we had bought ourselves by by going [13:01] that route. We tried [laughter] [13:04] and it just wasn't feasible, you know, [13:07] uh and and and so so we were we were [13:09] just trying to optimize for, you know, [13:12] doing as little work as possible to get [13:14] us to the payout, which is which and [13:18] honestly, Rust is no better when it [13:20] comes to like the quality of the [13:22] generated code or the or the the [13:24] concurrency gains that we could have [13:25] gotten out of it. [13:27] Go just as it's great. I mean, so so we [13:31] got we got all the bennies with for less [13:33] work by by going that route. [13:35] >> I know some languages they're when you [13:37] say they're garbage collected, they [13:40] >> there's something in the the language [13:42] itself that is doing garbage collection, [13:45] but um there's also independent [13:48] libraries that can provide garbage [13:50] collection, right? [13:52] There is, but it it but it comes often [13:55] with a whole bunch of restrictions and [13:57] and and it doesn't come necessarily with [14:00] the safety guarantees that we were [14:02] looking for. I mean, like Go is type [14:04] safe and memory safe. uh meaning that [14:07] you don't get to just like have stray [14:10] pointers or or whatever where Rust you [14:13] can do ref counting or you can do you [14:15] can do all sorts of different strategies [14:17] but there's always like that little bit [14:20] of unsafe where you have to like do this [14:22] in order to make it all work you know uh [14:25] where where if garbage collection is [14:28] engineered into the language it really [14:30] is a a separate concern that is you you [14:33] you don't you don't have to do anything [14:35] special in I mean of course you you have [14:39] to like not hold on to data that you no [14:41] longer need and whatever you know but [14:43] that's true of ref counting as well [14:45] right but but it is inherent in in the [14:48] language [14:49] when you ported it from JavaScript to go [14:52] I'm curious how much LLMs were used in [14:55] that process because I know famously [14:58] there's some major projects that have [15:00] been doing uh rewrites of their entire [15:03] codebase I know there's this JavaScript [15:05] project called bun [15:06] >> that rewrote everything from Zigg into [15:09] Rust and so [15:10] >> seems like a pretty useful tactic and [15:13] I'm curious if you leverage that in this [15:16] process. [15:16] >> Not a whole lot but it also has to do [15:18] with timing. Uh we started this project [15:21] two years ago and two years ago LLMs [15:23] were nowhere near as good as they are [15:25] now. I mean that's how crazy fast it [15:27] it's all moved, right? Um, [15:31] so what we did though is we we certainly [15:34] had [15:36] a bunch of tools that aided us in the in [15:39] the in the the port. I'd say the [15:42] prototypes we wrote, the scanner and the [15:43] parser we wrote manually. Um, and at [15:47] that point we could convince ourselves, [15:49] wow, we can actually get 10x out of [15:51] this. Now what do we do with the rest of [15:53] this codebase? And what we did was we [15:56] wrote a tool that syntactically [15:58] translates TypeScript into Go. [16:03] This Go that comes out of it, it has no [16:05] syntax errors in it, but it doesn't [16:06] compile either because it's full of, you [16:09] know, like it uses types as if they were [16:12] TypeScript, which they're not in Go. And [16:14] so all of that had to be refactored. We [16:17] had to redo all the data structures or [16:18] whatever, but we got the same code base [16:21] out of it. And then we can sort of bang [16:23] on that. and then in a more localized [16:25] fashion maybe use AI occasionally to [16:28] help us do the transformation. So it was [16:30] sort of manual and automated [16:34] and a little bit of AI. Now if we were [16:38] to start the project today would we do [16:41] it differently? Possibly. Um although I [16:43] will say if if we just let AI loose on [16:48] you know what is it like half a million [16:49] lines of code that we have in the old [16:50] compiler or somewhere between half a [16:52] million and a million right uh and asked [16:54] it to translate it all. Well I don't [16:57] know that that would absolve us from [16:58] then having go in and carefully [17:00] examining every line that came out of it [17:02] to make sure that there were no [17:03] hallucinations. Right? Unless you have [17:05] 100% perfect test coverage, you probably [17:08] still got to go check all of that. Now I [17:11] think a a a better approach quite [17:14] honestly would be enlist AI to write a [17:17] program that helps you translate from [17:20] Typescript to Go because at that point [17:23] you can park the stochasticness in that [17:25] program and then you can get [17:27] deterministic behavior whenever you run [17:29] the program which means you get the same [17:31] transformation every time you run it [17:34] right that's always the thing about AI [17:36] that people forget it's not [17:37] deterministic right so you can't really [17:40] trust that it's going to do the same [17:41] thing twice. [17:43] Um, [snorts] [17:44] so, so we might have done it that way, [17:47] but AI was not ready to do it at the [17:49] time. Now, that doesn't mean that we [17:50] don't use AI. I mean, like now down the [17:53] line, we use AI a lot in our in our [17:56] internal processes around like the the [17:58] compiler as everyone does, right? Like [18:00] help it to write tests and to move pull [18:03] requests and what what what have you. [18:05] and and whenever an issue is logged, we [18:08] first thing we do is put copilot on and [18:09] see if it can fix it for us, right? I [18:11] mean, and so yeah, [18:13] >> in that approach where you you use the [18:15] LM to generate uh tooling and then you [18:19] know the tooling is deterministic, [18:21] >> but you'd still have to validate that [18:23] thing. [18:23] >> Yes. But that's that's a lot smaller [18:25] surface area that you have to validate, [18:27] right? And honestly, I I've seen that [18:30] even with friends that are like we did [18:32] some trip together and there was like [18:34] some some accounting of they go, well, [18:36] he paid for the hotel rooms or we paid [18:38] for this and whatever and we needed to [18:39] like sort it all out, right? And so, so, [18:42] okay, well, here's what all the costs [18:43] were and here were the pie and like have [18:45] AI fix it for us, right? Or like tell [18:47] who owes who what and it very [18:50] authoritatively came up with the wrong [18:52] answer, right? [laughter] [18:54] Because it just forgot like about some [18:57] of the settlements, right? And but if we [18:59] had asked it to write a spreadsheet, [19:02] which is really that's just a program, [19:03] right? Then we would have gotten the [19:05] right answer because it's very good at [19:06] writing programs. So it's kind of funny [19:09] how you you you don't sometimes you you [19:12] don't ask AI for the for the answer. You [19:14] ask it for a program that computes the [19:16] answer. [19:17] >> What are the potential benefits that you [19:20] left on the table by doing a port [19:21] instead of a full rewrite? [19:23] >> To be honest, I don't think there are [19:25] any. Um, and I don't think we would [19:27] consider uh a rewrite. We were quite [19:29] happy we're quite happy with the way [19:31] this codebase works. Uh, and we're and [19:34] we certainly I don't think we're leaving [19:36] any any money on the on the table [19:38] currently. Um, and and as I said [19:41] earlier, rewrites are toxic often for [19:44] ecosystems because they sacrifice [19:47] compatibility because you never rewrite [19:50] and you get you never get back to [19:52] exactly what you had before, right? Oh, [19:54] but oh, but in the name of making it [19:56] better or prettier or whatever, we [19:57] change this and that and this and that [19:59] and the other, right? And then well, all [20:01] the users get to suffer through that, [20:03] right? So, so backwards compatibility is [20:05] super important if you want to keep your [20:08] ecosystem happy. Uh, and and and we we [20:10] do want that. [laughter] [20:12] In studying for this interview, I I just [20:15] keep reading about JavaScript and the [20:17] the strange semantics of the language. [20:20] And I think throughout my career too, [20:22] people have typically [20:24] not been super satisfied or happy with [20:27] JavaScript for some reason or the other, [20:29] >> right? [20:30] >> And my question is why is it so popular [20:34] despite that? [20:36] >> So first of all, I I don't think [20:38] JavaScript is as bad of a lang of a [20:40] language as as some people make it out [20:42] to be. I I I will say in in like the [20:44] three about three four weeks that [20:46] Brendan Ike had to create this language [20:48] back in the mid 90s, he did a lot of [20:51] things right. Um and thank God that he [20:54] had been educated on functional [20:55] programming and and got first class [20:58] functions done right where you can have [21:00] functions within functions and the inner [21:02] functions can access the outer function [21:04] state and you can pass functions around [21:07] as first class values. [21:10] that is super powerful and JavaScript [21:12] actually got that very right. Um, now [21:15] there's some quirks in the language too, [21:18] like all of the automatic conversions [21:20] and all of the bizarre differences [21:22] between double equals and triple equals [21:24] are just like drives everyone mad, [21:27] right? But that's exactly what type [21:28] checkers are happy to do. They can like [21:30] they can far it out all the little [21:32] differences because they understand the [21:34] all the deep semantics of the language [21:36] that no one seems to be able to keep in [21:38] their mind, right? So, and I think [21:40] that's part of why Typescript has become [21:42] so popular, right? It's like it can [21:44] actually like truly bring out the best [21:46] parts of JavaScript uh and leave the bad [21:49] stuff behind. And of course, you can't [21:52] like like the thing about JavaScript is [21:55] it is the crossplatform language. Like [21:58] even Java that was engineered and [22:00] intended to be the way to write [22:02] crossplatform applications, it's not [22:04] really crossplatform. It doesn't run in [22:07] the browser, you I mean it doesn't it [22:09] doesn't run everywhere, right? [22:10] JavaScript runs everywhere. Um, so there [22:15] are a lot of there are a lot of reasons [22:16] why you should like JavaScript and and [22:20] with TypeScript, I think we've managed [22:22] to sort of capture all the badness and [22:25] park it. [22:27] I saw there were some projects. I don't [22:29] know if you're familiar with Dart or [22:32] CoffeeScript and [22:34] >> it seems like these were some effort to [22:37] replace JavaScript or improve it and [22:40] >> right [22:41] >> but they're not popular today. So I'm [22:43] curious what happened. [22:44] >> I mean I think coffecript was mostly [22:49] it's a different syntax for JavaScript. [22:51] So, so it doesn't really change the the [22:53] semantics and it doesn't it didn't [22:55] provide any additional tooling and and [22:57] whatever. And and Dart was also in a [23:00] sense about fixing JavaScript, right? [23:03] But if you can fix something by fixing [23:06] it instead of trying to replace it with [23:09] something else, then you're doing the [23:13] ecosystem a much bigger favor, I think. [23:16] Right. And that's what we set out to do [23:18] with TypeScript. We weren't trying to [23:19] change JavaScript. we were trying to [23:21] improve JavaScript. Um, and I think [23:24] that's ultimately why we why we [23:26] succeeded. [23:28] >> I mean, in this new age where it's very [23:31] feasible that maybe AI could rewrite [23:34] code bases, [23:36] um, I imagine people will start to go [23:39] towards the the desired languages rather [23:42] than the ones that are the incumbent [23:43] languages. [23:45] And I'm curious if you think that [23:47] JavaScript might become less used in the [23:49] future. [23:51] >> See, I I don't think so. I I what I've [23:54] observed is that AI [23:58] is best at the languages if seen the [24:01] most of in its training set, right? And [24:04] AI gets trained on all the code that [24:06] exists in the world. Um, [24:09] which means there's an awful lot of [24:11] JavaScript, an awful lot of TypeScript, [24:12] an awful lot of Python. And therefore, [24:15] AI is good at JavaScript and TypeScript [24:17] and Python. And it is less good at my [24:20] favorite little language that I just [24:22] invented. In fact, there's none of it in [24:23] the training set, which means you have [24:25] to sacrifice God knows how many tokens [24:27] in the prompt to teach AI the language [24:31] before you can even ask it a question [24:33] about the language. Do you know what I [24:35] mean? So in that sense I think incumbent [24:38] languages are actually if anything going [24:41] to flourish uh because of AI and we're [24:44] sort of seeing that right now with with [24:45] TypeScript too right there there's a [24:47] noticeable knee in the curve of [24:49] TypeScript adoption that coincides with [24:52] the advent of AI. I do think the [24:55] incumbent languages are actually if [24:57] anything getting stronger. [24:59] >> What percent of all JavaScript is [25:02] written in Typescript? [25:04] Well, so, so in the last year, [25:08] Typescript uh became the number one used [25:11] language on GitHub. Um, so there's [25:14] JavaScript more than JavaScript. [25:16] >> So, so more than 50% on GitHub at least [25:20] >> is is is written in in Typescript. Um, [25:23] so so we're actually like larger now [25:25] than the language that we set out to [25:27] improve. [25:28] >> Wow. [25:29] >> Yeah. And larger than Python. If you [25:32] were to just draw that out in the [25:33] future, do you think that eventually [25:35] TypeScript would become the default and [25:37] almost 100% of all JavaScript would be [25:40] typed? [25:41] >> Well, certainly, I mean, if you're [25:43] having AI write it, I I almost challenge [25:46] you to find a tool that writes [25:48] JavaScript. They all write TypeScript. [25:50] Uh because it helps AI write better code [25:53] because the type annotations guide the [25:56] LLM towards writing or to write making [25:59] fewer mistakes. and the ability for us [26:02] to statically validate the code before [26:06] you run it. I mean, that's the [26:08] distinction, right? The only way you can [26:09] validate JavaScript is by running it, [26:12] which means you have to set up a runtime [26:14] environment, which might not be possible [26:16] for AI to do because AI lives in a [26:18] sandbox, right? But AI can run through [26:21] tools, the compiler, and check the code [26:24] that it just generated and be told, "Oh, [26:26] you made a mistake. Oh, well, let me fix [26:28] it then before I even tell anyone that I [26:30] made the mistake, right? [laughter] [26:32] [snorts] [26:32] >> After learning about the this 10x [26:35] improvement in performance from uh [26:37] rewriting in native, I makes me wonder [26:40] why anyone would use JavaScript on the [26:44] back end. Why not just always use native [26:47] languages on the back end? [26:48] >> Well, it depends on your problem. Uh I [26:51] think because the thing that that [26:52] overlooks is [26:55] what kind of thing am I going to write [26:56] on the back end, you know, like like [26:58] there are an awful lot of very very good [27:02] web server frameworks for example that [27:04] that use TypeScript or JavaScript, [27:07] right? So, so if there are like [27:10] frameworks in your ecosystem that gets [27:11] you to a solution quicker than if you [27:14] had to write that because your native [27:16] language wasn't really intended to [27:18] target that particular community. So, I [27:22] think it very much depends on [27:25] your what what your problem is [27:27] affinitized with. Um, and and often PF [27:31] of your code isn't the bottleneck. I [27:34] mean, like look at Python. I mean right [27:37] it's it's used to basically script and [27:39] all of the LLM training in in the world [27:42] right I mean which clearly a lot of that [27:44] code is ultra timer critical uh but [27:47] that's written in native code right and [27:49] then you use Python as the orchestration [27:51] language and in a sense in a web server [27:53] you know like TypeScript is just an [27:55] orchestrator you know of talking to a [27:58] database and doing this and that what [27:59] and and and the things that the things [28:01] that that ultimately control the [28:03] performance of applications like that [28:05] aren't necessarily [28:07] whether that inner for loop is running [28:10] as as as native code or not which [28:13] actually it is because of the JIT anyway [28:15] right I mean so [28:18] I mean measure measure first and then [28:22] make decisions right because you always [28:24] get surprised when you measure [28:26] >> when you talk about how much faster it [28:28] was too one of my immediate thoughts is [28:31] why wasn't it done sooner [28:33] >> you know at the time we started [28:35] TypeScript script. I don't know that we [28:37] had ever envisioned that people would be [28:39] writing projects that are the size of [28:42] the projects that people are now writing [28:44] in Typescript, right? Like Visual Studio [28:47] Code is like 2.3 million lines of code. [28:50] I mean, we have in in-house projects [28:52] that are over 10 million lines of of of [28:55] code, which is insanity. We would have [28:57] just at the time gone, well, that's [28:58] clearly no one's ever going to do that, [29:00] right? But that was a decade ago or more [29:02] than a decade ago, right? We started in [29:04] 2012 with the TypeScript project and the [29:06] world looked very different and so [29:08] gradually people have started writing [29:11] larger and larger and larger projects, [29:13] right? And at the same time, our [29:16] compiler has gotten smarter and smarter. [29:18] We've added all sorts of cool features [29:20] like union types and discriminated [29:22] unions and control flow analysis and [29:24] blah blah blah. And all of these things [29:28] make our type checking even better, but [29:30] it also makes it go a little slower [29:32] every time we add a new feature. Right? [29:33] In fact, our TypeScript 6 runs only [29:35] about 50% of the speed of TypeScript 1.5 [29:39] for example. But TypeScript 1.5 also did [29:42] a whole lot less. Um, so projects have [29:46] gotten bigger and the compiler does [29:48] more. All of which [laughter] [29:51] detract from your effective output. And [29:53] as I mentioned, Mors law also [29:56] unfortunately stopped delivering faster [29:58] CPUs and JavaScript keeps you from [30:00] taking advantage of the additional [30:02] cores. And it's not clear that we could [30:04] have foreseen all of that, right? But [30:07] but but it's just the way it panned out, [30:10] right? [snorts] [30:11] >> Open AAI, Enthropic, Curser, and [30:14] Verscell all use this product to make [30:16] their lives better. And the problem it [30:18] solves is when you're building SAS or an [30:20] AI product and you want to sell to other [30:23] companies, there's all these [30:24] requirements you need to meet. There's [30:26] SSO, there's skim, there's arbback, [30:29] there's audit logs. These are all things [30:31] that take time to integrate but aren't [30:33] the main focus of your app. Work OS is [30:36] an API layer that lets you meet all of [30:37] these requirements in just a few lines [30:40] of code. So let's say you have a new SAS [30:42] product and you want to sell to other [30:44] companies. work OS will solve all of [30:46] these critical feature gaps for you. You [30:49] can check them out at workos.com to [30:51] learn more and get started. And I [30:53] appreciate them for supporting my work [30:55] and sponsoring this podcast. Jira by [30:58] Atlassian isn't just for tracking work [31:00] anymore. Now you can pick your favorite [31:02] AI agent to assign tasks to and they'll [31:04] get access to the rich context that's [31:06] already in Jira. When the agent is done, [31:09] it surfaces a pull request. That way you [31:11] can get more done with your favorite [31:13] agents all in one place. Learn more at [31:16] jira.dev. That's jir.dev. [31:20] Appreciate them for sponsoring the [31:22] podcast. And back to the show. When I [31:24] first became a software engineer and I I [31:27] went to start working at Facebook at the [31:29] time, they had this popular framework [31:32] called Flow, which was [31:34] >> doing type inference on top of [31:36] JavaScript. It was this thing that would [31:38] take a long time. [31:39] >> Yep. And then I' I'd never hear about it [31:41] these days. So it sounds like Typescript [31:44] won if there was a competition to [31:46] typing. [31:47] >> There was a bit of it. Yeah. In in in [31:49] the early days. Um I think the thing [31:52] that worked for us was actually the fact [31:54] that we were self-hosted which made it a [31:57] lot easier for the community to [31:58] contribute to the project. [snorts] [32:01] Flow was written as I recall in camel. [32:04] Um, and so in order to contribute to [32:07] flow, you had to go learn a whole [32:09] different way of programming and and in [32:11] a in a different language, right? And [32:13] Float also didn't really focus all that [32:15] much on [32:17] IDE based tooling, [32:20] which we knew full well going in. We're [32:22] writing a compiler, but we're not [32:23] writing a compiler in order to generate [32:26] machine code. We're writing it to make [32:27] better tooling. That was why we wrote [32:30] it, you know, and so right there [32:33] handinhand with our compiler, we had a [32:35] language service. It was deeply [32:36] integrated into Visual Studio, Visual [32:38] Studio Code, all sorts of other editors [32:40] through an open protocol, you know, and [32:42] that just that's where that was the [32:46] problem that needed solving, right? I [32:48] mean, it's not it's it's nice to have a [32:50] type checker, but boy, you you want [32:52] that. You also want statement [32:53] completion. You wanted red squiggies. [32:55] You want like I mean, you want it [32:57] interactive, right? [32:59] So I know in your career you've you've [33:01] worked on uh multiple programming [33:03] languages. What does it take to build a [33:06] programming language? Well, first I'll [33:09] say that the world needs another [33:11] programming language like it needs [33:12] another hole in the head. I mean it it's [33:14] it's like you you kind of got to be a [33:16] certain [laughter] kind of of person to [33:20] to even embark on it to begin with, [33:22] right? It's a super fascinating area of [33:25] of computer science and it's one that's [33:27] been around ever since the beginning of [33:29] of of computers. Now, every compiler, [33:33] every language has a whole bunch of [33:35] things you need to to understand like [33:37] parsers and scanners and lexers and code [33:39] generators and and and and whatever, [33:41] right? But but that's sort of the [33:44] mechanics of implementing the language. [33:46] And then there's the design of the of [33:49] the language, sort of the art of making [33:53] it feel right and whatever, right? And I [33:55] I think you sort of have to master both. [33:59] And then you also got to appreciate that [34:01] like every new language is actually only [34:03] 10% new and then it's 90% the same [34:06] drudgery that every other language has [34:08] to go do. And so be prepared for a lot [34:11] of work that maybe isn't as interesting, [34:14] you know. [34:16] And then finally maybe I'll say that you [34:19] know like never forget there that you [34:21] you stand on the shoulders of giants. I [34:24] mean you you in order to make a great [34:26] programming language you got to [34:27] understand a bunch of other programming [34:28] languages first uh and understand all [34:31] the all the distinctions between the [34:33] different styles of programming like [34:34] procedural and object-oriented or [34:36] functional or what have you. Um [34:40] and then last but not least it's like [34:43] it's a long game. I mean, it is probably [34:45] a longer game than anything else. I [34:47] mean, like every language project I've [34:51] worked on, I've worked on each of them [34:53] for at least 10 years. Um, and shipped [34:57] multiple versions, and it's really never [34:59] until version three that it truly starts [35:02] to get okay. Do you know what I mean? [35:05] And, and it just takes an incredible [35:07] amount of devotion to to that. So, you [35:09] got to really not be the type that tires [35:11] of a problem quickly and then moves [35:13] along. that you're not meant to do [35:14] language design. [35:17] And you see that too if when you talk to [35:19] language designers in the industry, [35:20] they've been doing it for a long time. [35:22] >> You mentioned those two parts. There's [35:24] the the objective pieces that you need [35:28] to implement and then there's the the [35:31] art of the design and making the [35:32] language I guess ergonomic for [35:35] developers. When you think of that [35:37] second part, that art [35:39] >> and you look at other programming [35:41] languages, are there any that you admire [35:43] outside of the ones that you've worked [35:45] on? Of course, [35:47] >> learning and and and fully appreciating [35:49] the beauty of functional programming has [35:51] has been very educational, right? I [35:54] mean, because it really is a different [35:55] way of thinking about programming, a way [35:58] of thinking of programming that's much [36:00] closer to math than it is to [36:04] machines. Um, [36:07] and I think there's there's a lot of uh [36:10] incredible goodness that has come from [36:12] that. And and honestly even in in like [36:14] like building the TypeScript project uh [36:17] large portions of the TypeScript [36:18] compiler are written in a highly [36:20] functional style um and work on [36:23] immutable data structures that are then [36:25] now because of shared memory concurrency [36:27] can be shared between different [36:32] uh threads or processes that don't [36:35] mutate the data and therefore they can [36:37] share one data structure. Right? And [36:39] that's incredibly powerful. But [36:41] mastering this, you know, like writing [36:43] islands of pure functional programming [36:46] inside an imperative program and ma and [36:48] and and putting it together with [36:50] concurrency. I mean, it's it's it's [36:51] complex, but I think functional [36:53] programming has brought a lot to the [36:54] world. Um, I know object-oriented [36:56] programming as well. I mean, but I [36:58] wouldn't single out any particular [37:01] language. Every one language you you [37:03] come in contact with, you learn [37:05] something. You know, [37:07] >> you mentioned the world doesn't really [37:10] need more programming languages and uh [37:14] if you think 10 years from now, do you [37:16] think there'll be less programming [37:17] languages than there are today? [37:19] >> It's hard to say. I mean, but like I [37:22] said, [37:24] AI tends to favor the incumbents, right? [37:28] And I I do think and I I think this has [37:30] been true even before AI. The bar keeps [37:33] going up for what it takes to [37:36] successfully implement a programming [37:38] language and create an ecosystem around [37:40] it. I mean it used to be oh you just [37:42] need a compiler. [37:45] Well [37:46] you also kind of need tooling now. I [37:48] mean you need a language service you [37:50] need uh you need debuggers. You need [37:52] profilers. You need frameworks and [37:54] libraries. You need code generators that [37:58] can target all sorts of I mean it's like [38:02] it just keeps getting harder and harder [38:04] uh you know to to to get all the way [38:07] there. [38:08] >> Well, when you think about all those [38:09] pieces that really they're all for the [38:13] people or I mean the you know the IDE [38:16] and the types and I mean the the [38:19] computer looks at that too but it's so [38:22] that we can read source. [38:24] Maybe one day the LMS will generate [38:27] machine code directly. I wonder. Um [38:32] I think [38:35] I think LLMs are better at what they do [38:39] when when they don't have to repeat [38:41] themselves a lot. I I I think like [38:46] when a program is expressed in text, it [38:49] is closest to its sort of ultimate [38:54] condensed meaning and representation, [38:57] right? If you translate it into machine [38:59] code, there's an awful lot of noise in [39:01] that machine code. Like all of the [39:03] instructions, like half of the [39:04] instructions are memory addresses that [39:06] have absolutely no bearing on what's [39:08] going on here, right? So half of it, [39:10] half of all the data is noise already, [39:12] right? And then whichever register you [39:14] pick, well, that doesn't matter either [39:15] in the code generator. And honestly, you [39:17] could change your mind at any point in [39:18] time. So, so teasing the truth out of [39:21] that noise is a lot harder than if you [39:26] just have a program where the variable [39:27] is called I and whatever. And by the [39:29] way, that you can relate to the written [39:32] instruction that the user just gave you. [39:34] I mean, keep in mind that that like AI [39:36] are they're just emulators of humans in [39:39] a sense, right? I mean, they they it's [39:41] like neural networks, right? There's a [39:42] reason we have programming languages [39:44] because we're terrible at writing [39:46] machine code straight off. out of our [39:49] head, right? AI is not that different [39:51] from us, you know? So, the same would [39:54] probably be true there. when you look [39:57] back on working on C and you know [39:59] TypeScript and these language projects [40:02] they were long journeys and I think you [40:04] know one thing people might want to know [40:06] is what did you learn through those [40:09] journeys that if you knew at the [40:11] beginning of when you embarked on [40:12] working on them you you might have been [40:16] better off [40:19] gosh well each journey is is different [40:23] uh I mean like the first project I [40:25] worked on turbo Pascal. I I think [40:30] that project started back in the old [40:32] days when it was 8-bit micros and 64k of [40:34] memory and one person could do [40:36] everything themselves and have ultimate [40:39] control of everything. And so I was very [40:41] much a one-man shop, right? But that [40:45] quickly was not scalable, right? And and [40:48] and capacities of machines. So we went [40:50] for 64 to 640K and then then kaboom the [40:53] the the the lid went off, right? and you [40:54] could have as much memory as you wanted [40:56] and so not one person couldn't do it and [40:59] I had to learn to become a team player [41:02] right and that that was a big journey [41:05] for me I mean to learn to let go right [41:08] if you're a perfectionist that that that [41:10] could be hard but that's one thing that [41:12] I would say I learned there [41:14] >> well another way to word this question [41:16] is you know what's the most common [41:18] mistake that you see people make when [41:20] they embark on building a programming [41:22] language [41:24] Well, I think people tend to overindex [41:26] on one idea, you know, that that they [41:29] have that they think, "Oh, wouldn't it [41:30] be cool if my language could do blah, [41:33] and then they underindex on all of the [41:35] mundane stuff that every programming [41:38] language has to do, you know, and then [41:40] it ends up doing that one thing they [41:41] love maybe better, but then it does [41:44] everything else not as good." [laughter] [41:47] And and and the net is a detractor, [41:50] right? And so it's so hard to convey how [41:55] many things you have to do that really [41:57] doesn't have anything to do with the [41:59] problem you're you're trying to solve [42:02] per se, you know, when you're [42:04] implementing programming languages. [42:06] >> And when you were working on C, do you [42:08] keep tabs on the other languages and [42:11] >> you know what they're doing better, what [42:13] you could do better with C? [42:15] >> Yeah. No, you got to keep yourself [42:16] informed about because like I said, we [42:19] all stand on the shoulders of giants, [42:21] you know, no other no programming [42:23] language was ever created in in in [42:26] perfect isolation, right? Everyone [42:28] learns from from everyone and then [42:30] someone comes up with a good idea and [42:32] then you see it adopted elsewhere and [42:33] we've adopted many ideas from functional [42:35] programming you know in C for example [42:38] and then other languages have adopted [42:40] some of the good ideas we had in C# like [42:42] async you know now is in JavaScript and [42:44] in some of the other programming [42:45] languages out there and that was [42:47] pioneered in C and so you know it's it's [42:50] we all learn from each other um and and [42:53] that's how the industry moves forward [42:56] really You mentioned the I guess [42:59] learning to let go. I think that's [43:00] something that a lot of people as their [43:03] career advances they they start with you [43:06] know individual contributor work and [43:07] then later they start delegating things. [43:10] >> How did you learn that or what was the [43:12] is there like a maybe a story or [43:14] particular project where you you let go [43:17] and you you kind of develop that skill? [43:21] Well, it's it's almost like I got a [43:23] counter story to the to the letting [43:24] letting go there because in the C [43:28] project um my main function was not [43:31] implementing the the C# compiler. It was [43:34] being the language designer and writing [43:35] the spec and designing all the new [43:37] language features. And [43:42] before that when I when I had worked on [43:44] Turbo Pascal, I was I was doing a bunch [43:45] of active coding, you know, on on the [43:48] thing itself, right? But then I sort of [43:50] let go of that. But I let go of it too [43:52] much and I sort of drifted up into the [43:55] stratosphere and became more of an [43:57] architecture astronaut. Do you know what [43:59] I mean? And and and I wasn't getting my [44:01] hands dirty. I was writing stuff in the [44:03] framework and in the libraries, but it [44:04] was it didn't quite these are not like [44:07] the deep really super hard problems to [44:10] solve, right? And and I didn't really [44:12] know it at the time, but I was gradually [44:14] getting less happy with with the work [44:17] that I was that I was doing, right? I [44:19] mean, it's I still enjoy, but there was [44:21] something missing, right? And so when [44:23] when this TypeScript opportunity came [44:25] along, I decided to jump in and actually [44:28] actively participating writing compiler [44:30] and it brought so much happiness to my [44:32] life. Like I I I I finally realized I'm [44:34] just I'm just a happy coder, you know? I [44:37] mean, I like the spec stuff too, but but [44:40] coding is like, man, that's what gets me [44:42] up in the morning, make coffee, and [44:43] write some code, you know? That's that's [44:45] that's that's when I'm my in in my happy [44:48] space, you know. [44:50] you know, when people are at these [44:51] really really high levels, they're kind [44:53] of have this expectation of a certain [44:55] level of impact. And so, how do you [44:58] continue to write code at as such a high [45:01] level engineer? [45:02] >> Well, the specific code I'm writing [45:06] isn't necessarily having all all that [45:08] impact, but it's it's the fact that I [45:10] also do the architectural guidance, you [45:14] know, as part of a a group of people, [45:16] right? in a in a project, you know, [45:18] there's plenty of work for everyone to [45:19] go around and then you you just but you [45:21] you you stay involved in a corner of the [45:23] project because then you see what [45:25] happens in the code, you know, when [45:27] you're checking in your code, you go, [45:29] what was what what was that over there? [45:31] Let let me just what what's happening [45:32] over here, you know, or or you realize, [45:35] oh, we need to refactor this. This this [45:36] is not this is not feeling right [45:38] anymore. Or if if but if you let go of [45:41] that you don't really you can't really [45:43] talk about the thing that people use [45:46] day-to-day. You can talk about the [45:47] syntax of the thing that people use [45:49] day-to-day but you can't talk about that [45:50] thing you know so [45:54] so both are important I think and I'm [45:56] happy that I get to do both now I know a [46:00] lot of companies have this idea of [46:01] engineering archetypes or the the way [46:04] that highle engineers get some work done [46:07] and you mentioned architect for instance [46:10] a lot of companies have different words [46:11] for architect I'm not sure if you're [46:13] saying it's just your working style or [46:16] are you saying that all high level [46:18] engineers should be hands-on at some [46:21] level. [46:22] >> No, I I'm not saying that because I [46:24] don't think it's it's like I made a [46:26] conscious choice to [46:28] remain an independent uh contributor as [46:31] opposed to become a manager. I mean, I [46:33] had plenty of opportunities um but but [46:36] it that is not where I do my best work, [46:39] right? So I think you have to decide for [46:41] yourself what is it that motivates you, [46:44] makes you happy, keeps you doing this [46:46] for for a lifetime. Do do you know what [46:49] I mean? And and and you only get one run [46:52] at it in in life here, you know? And so, [46:54] and if you're going to do your best [46:56] work, do the thing that that makes you [46:58] the most happy, I think, is and and [47:01] that's what I [47:04] learned, you know, along the way there, [47:06] that coding is part of that, a big part [47:08] of that. [47:10] >> So then when you were working on C, but [47:12] before Typescript, like how did you know [47:15] something was missing? [47:16] >> I just knew something. I I I I don't [47:18] know how I mean it it just I would I [47:20] just wasn't feeling as fulfilled with [47:23] with with the with only doing the design [47:26] part, right? I I I missed the coding. [47:28] And whenever I had a chance to write a [47:31] little bit of code, I would feel a lot [47:33] happier and I go, it's kind of [47:34] interesting. I mean, do you know what I [47:36] mean? But now I got to go write some [47:37] more specs, you know? [laughter] [47:41] >> So then, uh was Typescript something you [47:43] kind of went towards because you wanted [47:46] to write more code? I went towards it [47:47] for for many reasons. I mean it wasn't [47:50] specifically that to begin with. I I [47:52] just found the problem fascinating, [47:54] right? I mean because the way Typescript [47:56] came about was [47:58] actually indirectly through C because [48:01] the outlook.com team I think it was [48:04] approached the C group and asked whether [48:07] we would pretty please productize [48:09] something called script sharp. And [48:11] script sharp was this thing that took C [48:14] and transpiled it into JavaScript so you [48:17] could run it in a browser. And I'm like [48:20] what? Why? Why would you want to do [48:23] that? Why don't you just write the job? [48:24] Well, because that way we can get great [48:26] tooling. Then we can use Visual Studio [48:29] and we can have projects and we can have [48:31] type checking and we can have code [48:33] refactoring and navigation and we can [48:35] write interfaces and people can [48:37] understand how this all works. And I'm [48:40] like, "Wow, [48:42] is JavaScript really that busted?" And [48:45] and you're saying like the the way you [48:47] want to fix that problem is by [48:48] abandoning JavaScript, treating it as an [48:50] instruction language, right? And then [48:52] having a code generator target it. I'm [48:54] like, couldn't we like fix JavaScript? [48:57] Wouldn't that be better? Do you know [48:59] what I mean? And that's how Typescript [49:01] kind of got off the ground, right? It [49:03] was like, gosh, there's something here [49:05] that's really broken that needs to be [49:07] fixed, right? and when it comes to [49:10] JavaScript tooling [49:12] >> and that's what we set out to do. [49:14] >> You know, one thing I thought would be [49:16] interesting is in one of the talks that [49:18] you gave, you said that you believe that [49:21] the speed of your tooling is more [49:24] important now because of AI and I want [49:28] to hear thoughts on why is that the [49:30] case? Well, more and more our workflows [49:32] now are are dominated by agents that are [49:35] like running away in the background, [49:38] right? Right. I mean, like writing code [49:40] for you and they make mistakes just like [49:44] we do, but they but they but you know, [49:46] but you can have as many of them as you [49:47] want. So there are like many many more [49:49] little workers in the ecosystem writing [49:52] much more code, right? And that whole [49:55] workflow is like LLMs already have have [49:59] performance challenging is and then if [50:00] you add like if if you're writing code [50:02] in a big project and you have to like [50:04] type check it and takes two minutes [50:05] every time the LLM writes something. Do [50:07] you know what I mean? That's horrible, [50:09] right? So So making that go faster is is [50:13] a big benefit. [50:14] >> Yeah. Absolutely. I guess because it's [50:16] it's hammering away. [50:18] >> Yeah. Because I mean like like well we [50:21] all know LLMs they they like to use GP [50:24] and and whatever right but then they're [50:26] also smart enough now to realize that if [50:28] you're like trying to change this [50:30] property called version and like every [50:33] other object has a version property. You [50:36] can't just grip for version and then go [50:38] rename it to something else because like [50:40] you're breaking all these other [50:42] interfaces that have a version in them, [50:44] right? So you got to do semantic search [50:46] and the only thing that can do semantic [50:48] search is a compiler and so you got to [50:52] use the compiler through typically [50:54] through LSP through language services or [50:57] through our our command line tool that [50:59] would give you the equivalent right and [51:01] so more and more AI is doing that um and [51:06] that means you know compilers run at you [51:09] don't you may not even see that they're [51:11] running but they're running [51:13] and they're doing work on on your [51:14] behalf. Yeah. [51:16] >> When you talk about AI, it's very [51:20] realistic and grounded in the software [51:22] engineering. And so I thought it might [51:24] be interesting to uh run some common AI [51:28] takes that I hear from the internet and [51:31] you get your sense of how accurate is [51:33] this? What are your thoughts on when or [51:35] if it'll be true? Okay. Okay. So the [51:38] first one that I've heard um this is [51:40] more common at the end of last year is [51:42] that you know AI is going to write 90 [51:45] plus% of the code you know within a [51:47] year. Um curious what you think on that. [51:51] >> Well for certain classes of apps that [51:54] that might like all divide code coded [51:56] apps they're writing 100% of the code [51:58] right and and there's an awful lot of [51:59] that being written. [52:01] Are they going to write 90% of the high [52:03] quality code on the internet? I don't [52:05] know about that. Um so the the thing is [52:09] like 90% of what the volume of written [52:12] code is just like going like that right [52:15] now right because AI writes so much code [52:18] so [laughter] [52:19] so in a sense that's a self-fulfilling [52:21] prophecy right I mean but [snorts] but [52:24] but when it comes to like [52:27] the super high quality code that no one [52:29] has ever written before um it's not [52:32] clear to me that AI is going to write [52:34] 90% of that. So when you think about [52:36] cases that AI is not writing all the [52:40] code, maybe some examples of the super [52:42] high quality stuff, what is that? [52:44] >> Well, [52:46] I mean it's it's algorithms that no one [52:48] has ever seen before, for example, or or [52:50] particular solutions like I mean I I [52:52] know that AI could not write our [52:55] compiler, the TypeScript compiler. It it [52:57] just can't. I mean we've tried it. It it [53:00] can't do it. Um and I'm not asking it to [53:03] either. I mean, I'm not expecting it to [53:05] either. Um, but but our compiler is also [53:10] not a typical piece of code. I mean, [53:12] that's why it's bad at writing it [53:14] because it's seen none of it in the [53:16] training set. Well, I've seen some [53:17] compilers, but not like this one. Not [53:19] with these concepts, not with done the [53:21] way that that we're doing it, right? And [53:23] so, it's just not a good fit there. AI [53:26] we we we can't forget that AI is at [53:30] heart a big stochastic machine that has [53:33] memorized the entire internet, right? [53:35] And and is ability and has an ability to [53:37] extrapolate somewhat over what it's [53:40] memorized, right? Um but if it hasn't [53:43] seen it before, it's it's it's not [53:45] necessarily going to be all that good at [53:47] at doing it. Um it's getting better. I [53:50] mean, I'm not saying it's it's not [53:51] impressive. I it's it's wildly [53:53] impressive what it can do, but I just [53:57] think there's a long way still to it's [54:00] doing all of it. [54:02] >> And I don't know that we ever get there. [54:04] I hope we don't because then what's the [54:06] point of humans anymore then? I mean, [54:08] it's [laughter] [54:09] >> Well, I see this take often, too, is um [54:12] you know, you won't need to use an IDE [54:15] within the year or you don't need to [54:17] read the code anymore. [54:19] >> Well, good luck to you. I mean, if [54:21] you're going to hand AI the keys, [54:24] I mean, then all bets are off, right? I [54:26] mean, the minute AI you can't convince [54:28] AI to fix this issue or this new feature [54:31] that you want built, what are you going [54:32] to do? I mean, if you don't understand [54:36] what what's below, right, that's one [54:39] problem. The other problem is, let's say [54:41] a user comes to you and goes, your app [54:43] just stole my bank account. I'm well, [54:47] it's going to sue you. It's not. They're [54:48] going to sue you, not the AI. I mean, [54:50] it's like at the end of the day, someone [54:52] has to take responsibility for what AI [54:55] is doing. And if you're giving it the [54:57] keys, well, it's on you, you know, but [55:00] but I don't know. I personally would not [55:05] feel comfortable. I wouldn't be able to [55:06] go to sleep at night. I mean, if I [55:09] didn't understand what it is that I am [55:11] vouching for. [55:13] Why is there such a big difference [55:14] between this opinion and what I see from [55:20] maybe people who work at Anthropic? [55:22] >> Well, the difference is all I'm saying [55:25] here is not that AI can't do amazing [55:27] things. It does it can it does that [55:30] every day. But but people love these [55:34] like take it all the way to 100%. Right? [55:36] And that's where I get off the bus a [55:39] little bit, right? I think, oh yeah, [55:40] okay, fine. We can get we can get higher [55:42] and higher percentage but there still [55:45] has to be someone understanding what's [55:48] going on and how it's relevant to our [55:50] business problem and how it relates to [55:52] what our organization is doing and like [55:54] I mean there's so many other things that [55:55] have to be connected that it's I think [55:57] it's wrong to just view it as AI did it [56:00] all and we were completely unnecessary [56:02] you know and [56:04] >> yeah the next one I was going to ask you [56:06] was you know three years from now will [56:08] AI replace junior software engineers or [56:11] what junior software engineers do today. [56:13] >> Well, if it does, then how do you ever [56:15] get senior software engineers, [56:18] >> right? I mean, it's it's like I don't [56:20] think so. Well, I not unless you also [56:22] believe that you will be able to do your [56:24] business three years later than that [56:27] without any senior software engineers, [56:30] >> right? [56:30] >> Because where are they going to come [56:31] from? You got to train them. I mean and [56:35] but to me I think maybe one thing that [56:39] to some extent has happened is that for [56:41] certain classes of programmers the the [56:43] the pyramid has narrowed at the bottom [56:45] right there are fewer people coming in [56:48] um and we are wanting them to advance [56:51] higher up faster um so that they can get [56:55] to this more supervisory role right I [56:58] think the the craft of being a software [57:01] engineer is definitely changing from [57:03] you're you're typing in lines of code to [57:08] you're having agents type in lines of [57:10] code and you are reviewing the work of [57:12] the agents, right? And so so you do more [57:16] reviewing, less typing. [57:18] Um, and some people love that, you know, [57:21] I mean, and and and and really are [57:23] fantastic at at that workflow, right? [57:26] But it's it's a change in nature of of [57:28] what what the job looks like as a [57:30] programmer. And this tool that you now [57:32] have in a toolbox is having that impact, [57:35] right? But it is but a tool and there [57:38] are still programmers involved in the in [57:40] the process that I firmly believe. [57:43] >> It sounds like you enjoy typing out the [57:45] code. Would you be less happy if five [57:48] years from now [57:49] >> I I I for for 40 50 years I have enjoyed [57:52] typing out code. Um [57:55] I'm actually there there some and so I [57:59] will continue to type certain parts of [58:01] the code, you know, but there are other [58:02] parts of the code that I don't [58:04] particularly care to type. I don't care [58:05] to type in tests and follow all the [58:08] rigor of the particular testing [58:10] framework. Heck no. If I can farm that [58:12] out to AI, happy me, you know. Um I do [58:16] think reviewing has always been harder [58:18] for me. It's harder for me to like spend [58:20] time on reviewing other people's code [58:22] than it is you know writing the code. [58:24] But I also think that over time we will [58:27] we can make that process of reviewing [58:29] code much more ergonomic than it is [58:32] today. Right? I mean often today you [58:34] just get here's like the list of the [58:35] files that were changed and here are the [58:37] deltas. You figure it up, right? I mean [58:40] AI could help us more there by [58:41] explaining what the changes are and and [58:43] whatever. And so I I think we're going [58:45] to get better at this. It's going to get [58:46] more interesting, but it will change the [58:49] nature of of the craft. [58:53] You said that you've been writing code [58:55] for 40 maybe 50 years. [58:58] >> What is the hardest piece of code you've [59:01] ever written or what's the most [59:02] technically challenging thing you've [59:04] ever done? [59:05] >> There there are so many things that in [59:08] their time were challenging, you know. [59:10] Um [59:13] I mean this last project we worked on, [59:15] we knew that like like you know sort of [59:18] the easy part was getting the native [59:20] code. it's just like just just move it [59:22] to this other language, right? But then [59:25] this taming this beast called uh shared [59:29] memory concurrency and and getting the [59:33] compiler to use like as many CPUs as [59:36] there are available on your box, right? [59:40] That is not a simple problem to solve in [59:42] a in a in a compiler because we're all [59:45] taught to write sequential stuff, right? [59:48] I mean first you do this then you do [59:49] this but how do you do all of this at [59:51] the same time and then share the data [59:53] structures afterwards without anyone [59:55] like accidentally modifying the other [59:57] guy's data structure and you know how do [59:59] [snorts] you in the cases where you have [60:00] to do that how do you then synchronize [60:02] it and avoid deadlocks and race [60:03] conditions and and and whatever right [60:05] this it was it was tricky uh there were [60:08] some good technical problems uh that [60:10] that we licked that I think we can be [60:12] proud of you know but [60:14] >> what about when hardware was more [60:16] constrained earlier in your career Is [60:18] there any wacky thing you had to do to [60:21] kind of, you know, make it work? [60:23] >> Oh, totally. I mean, when I started it [60:26] was a like being a programmer was a very [60:28] very different thing, right? I mean, I [60:30] started out with with 8-bit micros that [60:32] had Microsoft basic in ROM, right? And [60:35] and the basic interpreter and and you [60:38] could buy these books and type in these [60:41] Star Wars games or or or whatever. They [60:43] were all text, you know, there was just [60:45] scrolling and and telling you there's [60:46] Klingons over in that C quadrant, you [60:48] know, and K4, you know, you got to [60:51] whatever, right? Um, [60:55] but I got fascinated with understanding [60:58] how it was all put together and and got [61:00] and and quickly learned how to write uh [61:03] assembly code and Turbo Pascal, the [61:06] first product I worked on, was all [61:08] written in Z80 assembly code. um the [61:11] compiler, the editor, the runtime [61:12] library, everything was assembly. Um and [61:16] writing structured a compiler in [61:18] assembly code is like that that was that [61:21] was like took a lot of fiddling, you [61:24] know, and I mean and you were counting [61:26] like okay, I think I can I need to we [61:28] need to squeeze this into this EPROM and [61:30] then there's only 12K, you know, and I'm [61:33] I'm 20 bytes over budget here. Oh, but I [61:36] can make this jump this long jump [61:38] instead. I could jump to this short jump [61:40] and that then jumps to that jump and [61:42] then I could save one and that's one [61:44] bite saved. Okay. You know, moving right [61:46] along. [laughter] I mean, and you you [61:48] would you would you you were just like [61:49] sitting there and fiddling, you know, it [61:51] was it was a craft. It was like [61:53] woodworking almost. I mean, it was just [61:55] so different from what we do now, right? [61:57] Everything is like it's bottomless pits [62:00] of capacity and and and and bottomless [62:02] pits of expectation from users, right? [62:05] Is there a top technical book [62:07] recommendation you have for software [62:09] engineers? I usually recommend the same [62:10] but the the one book that was like the [62:13] it book for me when I was younger and [62:15] it's called algorithms plus data [62:17] structures equals programs by Nicholas V [62:20] uh the inventor of Pascal and then later [62:23] modular and Oberon and whatever and it's [62:26] a [62:27] it's a book that is [62:30] light on [62:32] math and symbolism uh and rich in [62:36] instructive examples and good [62:38] explanation. ations about how data [62:40] structures work. I mean, that's how I [62:42] learned about hashts, right? I mean, [62:44] like when you're self-taught, you don't [62:46] know about hashts. You sort of know [62:48] about linked lists, right? And fine. So, [62:50] in the original version of Turop Pascal, [62:53] all the symbol tables were just well, [62:55] they were just linked lists, you know, [62:57] or whatever. And then of course as you [62:58] had many local variables well you're [63:02] you're you're you're going exponential [63:04] in search time to you know and then I [63:07] read about these hash tables and like [63:08] wow what you mean I can like just do [63:11] this and then like it's it's basically [63:13] like linear lookup time and implemented [63:17] and the compilement twice as fast right [63:19] I'm like holy cow [laughter] [63:22] you know that was useful reading do do [63:24] you know what I mean so I was always [63:25] like the engineer it like that that I [63:29] mean and and understanding how to do [63:31] error recovery. He explains that in like [63:33] how you construct a simple compiler and [63:35] then like you know and it's it's [63:38] a it was for me a great book but and now [63:41] it's actually like I mean it's just a [63:43] big PDF you can download it out there um [63:46] it's out of print since 40 30 years. [63:49] Yeah. Last question for you is with all [63:52] the experience that you have now, if you [63:54] could go back to yourself when you just [63:56] entered the industry and give yourself [63:57] some advice, what would you say? [64:01] >> Well, I a couple of things maybe like we [64:04] talked about being a team player, you [64:05] know, I I I would have probably tried to [64:07] educate myself a bit more about that to [64:09] to begin with. Um, I think also [64:14] one thing in in retrospect is like [64:18] don't let people tell you that it can't [64:20] be done. When they tell you it can't be [64:23] done, it's because they can't do it. [64:25] That doesn't mean that you couldn't [64:27] possibly do it. Do do you know what I [64:29] mean? So, so don't let that discourage [64:31] you. Is there a project where you [64:34] someone said you couldn't do it and then [64:36] you did it and that's how you [64:38] >> Well, I think the first thing I worked [64:39] on like Turbo Pascal, people were [64:41] telling me whenever we told them here's [64:43] what we have, they said that can't be [64:45] done. That's like nah, you guys are you [64:48] full of That's like not possible, [64:50] you know. [laughter] [64:51] Well, it was. And I didn't know that it [64:54] wasn't possible, right? [64:56] >> Awesome. Well, thank you for your time. [64:57] I really appreciate it, Andrew. [64:58] >> You're welcome. No, this is a lot of [64:59] fun. Hey, thank you for watching this [65:01] podcast. If you liked it and you want to [65:03] see the show grow, please support with a [65:05] comment or a like. Also, if you have any [65:08] recommendations for people you want me [65:10] to bring on, please drop a comment. [65:13] Guests like Barbara Liskoff, Mike [65:15] Stonereaker, Mark Brooker, these were [65:17] all people that I brought on because [65:19] someone left a comment. On another note, [65:21] aside from the podcast, I'm working on [65:23] building the ergonomic keyboard that I [65:25] wish existed. Here's a glance at the [65:27] prototype. It's a split keyboard, so [65:30] there's two sides. This is in the case, [65:32] but yeah, we launched on Kickstarter and [65:34] we hit our goal within eight hours of [65:36] launching. I really appreciate it if you [65:38] were one of the people who grabbed one [65:39] of the early units. Um, we're now [65:41] working on the long journey of building [65:43] the tooling now. And so, if you still [65:45] want to pick one up, I've left the late [65:47] pledges open on Kickstarter, so you can [65:49] grab one there. I'll put a link in the [65:51] description. Thank you again for [65:53] watching the podcast and I'll see you in [65:56] the next