与安德斯·海尔斯伯格一起学习 TypeScript、C# 和 Turbo Pascal

没错。

Exactly.

对。

Yes.

是的。

Yes.

那是后来才启动的一个项目，目的是用语言本身来编写编译器。

That was the a project that came later to to build the compiler in itself.

而且早期的时候，你得记住，那时候的集成开发环境根本没那么先进。

And also early on, you know, this is gotta remember back then, IDEs were not really all that fancy.

你知道的。

You know?

我们那时候只有语法高亮。

I mean, we have syntax colorization.

代码补全呢，有些IDE刚开始尝试，但还远不是标配。

Statement completion was kind of like, well, some IDEs were starting to dabble in it, but it wasn't really a norm.

所以我们实际上搭建了一个经典的编译器。

So we built like, in a sense, a classic compiler.

但同时我们也搞了个简化的语言服务，虽然偷了点懒，但能做基本的语句补全和语法高亮。

But then we also built this, like, mini language service y thing that that sort of cut some corners and whatever, but could do some rudimentary statement completion and syntax coloring.

换句话说，我们得同时维护两套实现，还得同步更新。

But in a sense, we had two implementations that we had to evolve in parallel.

时间一长，这负担就越来越重了。

And over time, that became quite a drag.

对吧？

Right?

后来我们加了泛型、其他新功能、链接支持之类的，简直头大。

Because as we added generics and added other features and link and whatever, and it was like, oh my god.

现在每加一个新功能，都得在真正的编译器和语言服务里各实现一遍。

Now now this is like, we gotta go implement all of these features twice in the in the real compiler and in the language service.

对吧？

Right?

这最终促使我们启动了ROSLyn这个项目，我们打造了一个单一的编译器，它既能作为命令行工具运行，也能作为IDE内的交互式服务运行。

And so that ultimately led us to this project called ROSLynn where we built a single compiler that really is both it's a compiler that can both function as a command line compiler and as an interactive service inside the IDE.

TypeScript也是用同样的方式构建的，这种做法带来的很多经验，至今学校里依然不教。

TypeScript is built that same way also, and there's a lot of learnings from from doing it that way that are still not being taught in school.

很多真正有用的东西，即使对学习很有帮助，学校里也从来不教。

There are many useful things not being taught in school even when they are useful to learn about.

其中有一个特别实用的工具，我必须提一下，那就是我们的长期赞助商Turbo Puffer。

One of these really useful tools that I must mention is our seasoned sponsor, Turbo Puffer.

Turbo Puffer是一个极其可扩展、快速又便宜的向量和全文搜索引擎，由一支我非常欣赏的工程团队开发。

Turbo Puffer is a ridiculously scalable, fast and cheap vector and full text search engine built by an engineering team that I really like.

我第一次听说他们，是在和Cursor的联合创始人聊天时，他提到他们的向量数据库根本跟不上他们不断增加的代码库数量。

The first time I heard about them was when I was talking with one of Cursor's co founders about how their vector database could not keep up with the number of code bases that they were adding.

那是在2023年。

This was back in 2023.

Cursor当时做了一件看似冒险的事——他们押注了一个当时还鲜为人知、相对新兴的产品：Turbo Puffer。

Cursor did something seemingly risky, they took a bet on what was a little known and relatively new product at the time, turbopuffer.

但这一赌确实值得。

But it paid off.

Cursor 把语义搜索的负载全迁过去了，TurboPuffer 真的扛住了他们不断增长的巨大流量。

Cursor moved their semantic search workload over, and turbopuffer was indeed able to handle Cursor's massive ever increasing load.

这背后全靠出色的工程设计。

The reason has everything to do with smart engineering.

TurboPuffer 基于对象存储构建，同时在 NVMe 固态硬盘上做了智能缓存。

TurboPuffer is built on top of object storage with smart caching on NVMe SSDs.

Cursor 正在活跃的代码库会被加载到缓存里，搜索起来飞快；不活跃的就自动退到对象存储中。

Cursor's active codebases get loaded into the cache so searches are fast, and inactive codebases fade into object storage.

Cursor 对 TurboPuffer 的评价高得不得了。

Cursor has so many good things to say about TurboPuffer.

迁移之后，他们的语义搜索成本降了 95%，在 Slack 里，他们觉得 TurboPuffer 的工程师就像自己团队的延伸，而且在快速扩张的过程中，TurboPuffer 是少数他们从不操心的基础设施之一。

They cut their semantic search costs by 95% when they switched, they think of TurboPuffer engineers as an immediate extension of their team in Slack, and TurboPuffer is one of the few pieces of infrastructure that they have not had to worry about as they scaled.

如今，TurboPuffer 已经为超过四万亿份文档提供向量和全文搜索服务，客户包括 Anthropic、Notion、Linear、Ramp 等众多知名公司。

Today, TurboPuffer indexes over 4,000,000,000,000 documents for vector and full text search and is used by the likes of Antropic, Notion, Linear, Ramp and many others.

我正在慢慢了解 TurboPuffer 的团队，接下来几期会跟大家聊聊他们幕后一些很酷的工作。

I am getting to know the TurboPuffer team and will share more about some of the cool things that they do behind the scenes throughout the season.

如果你需要大规模的向量搜索或全文搜索，不妨试试 TurboPuffer。

If you need vector search or full text search at scale, think turbo puffer.

更多详情请访问 turbopuffer.com/pragmatic。

Check it out at turbopuffer.com/pragmatic.

说到实用工具，我还得提一下本季的赞助商 WorkOS。

When it comes to useful tools, I need to also mention our seasonal sponsor WorkOS.

今天和安德斯的对话中，一个突出的主题是他多年来一直在思考开发者效率的问题，这种视角远超大多数人所关注的几个月或几个季度。

One theme of today's episode with Anders is how he has spent the timeframe thinking about developer productivity on a scale that most of us do not decades, not months or quarters.

WorkOS 也秉持着同样的长期视角来打造企业级基础设施。

WorkOS takes the same kind of long term view on enterprise infrastructure.

单点登录、SCIM、基于角色的访问控制、审计日志——他们花好几年把这些问题打磨到位，让你不用再花几周时间去从零搭建。

SSO, SCIM, RBAC, audit logs they spend years getting these right so you do not have to spend weeks implementing them.

所以，增长最快的那些 AI 公司都选择信赖 WorkOS。

That's why the fastest growing AI companies trust WorkOS.

了解更多，请访问 workos.com。

Visit workos.com to learn more.

好了，接下来让我们继续和 Anders 一起探讨语言的设计。

And with this, let's get back to building languages with Anders.

当你在打造一门语言作为产品时，你是怎么收集反馈的？

And when you're building a language as as your product was, I guess, the the language itself, how did you get feedback?

当然，你之前提到过有一群人一直在批评它。

Of course, you had the the you already said the group criticized it.

你们有没有内部的测试用户？

Did you have an internal beta tester?

因为对于后端服务来说，通常都会有内部试用、内测、公测，然后才正式发布，但你们这显然不是普通的 SaaS 产品。

Because again, for like a back end service, you would typically have dogfooding, alpha testing, beta testing, and then you go public at some point, but this is not your your average software as a service for sure.

是的。

Yeah.

幸运的是，我们当时已经有内部客户在用了。

I I mean, luckily, we had internal clients.

.NET 框架很快就开始用 C 语言来实现了。

The dot net framework very quickly started implementing in C.

他们之前用的是一个拼凑出来的 C++ 版本，这有点奇怪，毕竟目标是字节码，但又不完全是。

They had sort of used a hacked up version of C plus plus to to implement, which was kinda odd because, I mean, it was like targeting byte codes, but not really.

后来他们改用 C 语言，效果好了很多。

And and so they switched us to to C, and that helped a lot.

之后还有其他内部团队在使用它。

And then we had other internal teams using it.

所以我们通过这种方式收集到了大量反馈。

And so we we got a bunch of feedback that way.

而且整个迭代周期也没那么长。

And then we had you know, the cycle was not that long.

对吧？

Right?

我记得我们大概是 1998 年底开始的，到 2000 年的 PDC 之前，就已经签下了不少用户。

I mean, I think we started in late ninety eight, and by the PDC of 2000, we had we signed up.

我们 basically 把测试版免费放出去，结果一下子吸引了大量用户。

I mean, we basically gave away beta copies, right, and and got tons of of users onto it.

C# 引入了很多编程语言里以前没有的新特性。

Now c sharp introduced a lot of new features that were net new, I think, to to programming languages.

LINQ 肯定是其中之一。

Link is certainly one of them.

但可能最有影响力、被其他语言广泛借鉴的，是 async/await 这套机制。

But one thing that might have been maybe one of the most influential parts that other languages adopted as inspiration was the AsyncAwait setup.

回头看看，你觉得这个设计哪些地方做对了？为什么它能被 JavaScript、Python、Rust 这些语言这么快地抄过去？

Looking back, what do you think you got right with this design and why did it become so copyable across languages like JavaScript, Python, Rust, and others?

很多语言都是基于协作式多任务的，就是有个事件循环一直在那儿分发事件，你处理完一个事件，就主动让出控制权，回到事件循环，全部都在单线程里协作运行。

Well, a lot of languages are built around cooperative multitasking in the sense that they have an event loop that sits and dispatches events, and then, you know, you handle the event, and then you yield back to the event handler loop, and it all runs in a single thread cooperatively.

对吧？

Right?

但问题来了，如果你得做点耗时很长的任务，怎么在中间停下来，主动让出控制权，回到事件循环呢？

The problem with that is if you then wanna do some long running work, how do I stop in the middle of this piece of long running work and yield back to the event loop cooperatively?

对吧？

Right?

等我的结果准备好了，我就能回来接着往下执行。

And then and then when my result is ready, then I can come back and continue executing here.

但在这种倒置的架构里，要想做到这一点，你得建一个状态机。

Well, in order to do that in in an inverted architecture like that, you have to build a state machine.

状态机 notoriously 难写，因为你得把所有状态从栈里挪到对象里。

And state machines are notoriously hard for for people to implement because you gotta move all of your state off of the stack into objects.

你得记清楚自己在哪儿，然后写一个巨大的 case 语句来包裹整个逻辑，简直让人头大。

You gotta remember where and then you have this big case statement that envelopes your entire logic, and it's it's like it's a nightmare to to figure out.

对吧？

Right?

但把顺序执行的代码转换成状态机——这种延续处理风格的转换，其实是可以自动化完成的。

But the transformation from serially executing code into a state machine, this this this continuation processing style translation, is actually one that you can do in a machine based fashion.

只要你加点语法标记出哪里需要暂停，编译器就能自动生成状态机代码。

You can have the compiler write the state machine if you introduce syntax that allows you to indicate where you want to yield.

而这就是 await 的作用。

And that's what a wait is.

await 的意思就是，我想在这里暂停，把这个 Promise 交出去。

A wait is basically I'm saying I want to yield here and then when and I want to yield this promise.

等 Promise 完成后，你再回到这里，继续往下执行。

And then when the promise completes, I want you to come back here and continue executing.

然后编译器会围绕它生成一个状态机，变成一个巨大的 switch 语句，把所有跨越 await 保留的状态都移到堆上，以便后续恢复。

And then the compiler writes a state machine around it, and it actually turns it into this big switch statement, you know, and moves all of the state that survives across the await into something that's heap allocated so it can be brought back.

这种工作，正是编译器最擅长的。

And doing all of that work is is something that compilers are great at.

所以我们有了这种新的编程方式：用 Promise 或类似的东西，配合 yield 能力，再加上回调——但如果你真用这种风格写程序，那就会像 JavaScript 常常遇到的那样，一团乱麻，对吧？

And so that was sort of the idea that we have this new style of programming where where we're using promises or the equivalent of promises and the ability to yield, and then we have callbacks, but trying to write your program in that style, that's also, you know, what JavaScript suffer from a lot, right?

就是一堆回调嵌套，烦得不行。

It's like all this callback style stuff.

而有了 async/await，你就能假装自己在写普通的顺序代码，复杂的转换工作全由编译器替你搞定。

And with AsyncAwait, you get sort of the illusion that you're just writing normal sequential code, and then the compiler does the the the painful transformation for you.

这实际上非常有用。

And that turns out to be really useful.

当然，另一种做法是使用操作系统的线程。

Now, arguably, an alternative way of doing this is to use threads in the OS.

但线程的问题在于它是抢占式的，操作系统随时可能中断你，而这未必是你想要的。

But the problem with threads is that they come with preemptiveness, and the OS has the ability to preempt you at any point in time, and that's not necessarily what you want.

而且你的用户界面现在也得变成多线程的，随之而来一大堆其他问题。

And and and your UI, now you have to be multithreaded in your UI, and all sorts of other problems come along with it.

再加上线程开销大，通常不适合像异步函数那样轻量级的任务。

Plus, threads are heavyweight and typically not well suited for lightweight tasks like like you could do with async functions.

所以各有优劣。

So there are pros and cons.

比如，异步等待引入了函数着色这个概念，有点麻烦，现在分两种函数：异步函数和普通函数。

You know, like asyncawait introduces this notion of function coloring, which is unfortunate, where you have two kinds of functions, async functions and regular functions.

所有异步函数都能调用普通函数，但普通函数不能调用异步函数。

And all of the red functions can call the blue functions, but the blue functions can't call the red functions.

所以一旦你需要一个红色函数，那它上面所有调用它的函数都得变成红色的。

And and so that means once you want, you know, a red function, it now everything above it has to be red.

如果你想从一个同步函数里调用异步代码，那就得把这个函数改成异步的，它的调用者也得改，再往上一层也得改，以此类推，对吧？

And then so if you want from a sync function to call something async, well then you've got to turn this function into an async function and its caller has to be, etcetera, etcetera, right?

这确实挺麻烦的，所以像 Go 这样的语言就用了协程和绿色线程，这些是语言层面模拟的轻量级线程，能实现我刚才说的效果，但开销小得多。

So that's unfortunate, and that's why some environments like Go for example, has Go routines and green threads, which are really language emulated lightweight threads that kind of do what I'm talking about, but at a much lower cost.

而且你不用面对函数着色的问题。

But you avoid the function coloring.

所以不同的语言有不同的解决方案。

So there is a bunch of different things.

但对于 JavaScript、C#、Windows 事件循环这些已经存在的环境来说，这种方案反而是最合适的选择。

But but, you know, but for an environment that already exists like JavaScript or like C Sharp and and the Windows event loop and and whatever, this this was the right solution.

说到 JavaScript，当 C# 在初创公司和大企业里越来越流行的时候，它也在游戏领域得到了广泛探索。

Speaking of JavaScript, as as c sharp was becoming really popular across startups, enterprises, and so on, it was exploring the popular games as well.

直到今天，它在游戏开发领域依然非常受欢迎。

To this date, it's very popular with with games development.

但那时候 JavaScript 开始越来越受欢迎了。

But JavaScript was starting to become more popular.

你能回顾一下吗？JavaScript 是怎么从九十年代中期那个没人当真的脚本语言，突然之间爆火起来的？

Can you can you take us back to your observations on on how how JavaScript went from, you know, like, the the mid nineties to this script language no one really took seriously to just exploding in popularity?

我觉得这跟两千年初发生的一系列事情有关。

I think it was sort of a confluence of a number of things that happened in the early two thousands.

对吧？

Right?

首先，JavaScript 的运行环境成熟了很多。

First of all, the the the JavaScript platform, execution platform, matured a lot.

比如谷歌推出了出色的 V8 引擎，一下子让 JavaScript 变成了性能不错的编程语言。

Like Google did their excellent work on V eight and all of a sudden make JavaScript a fairly performant, programming language.

HTML5 也正式通过了，我们终于能用 JavaScript 真正搭建复杂的用户界面了。

HTML five got ratified, and and and we were getting to a point now where you could actually build real UIs in JavaScript.

再加上苹果发布了 iPhone，掀起了设备革命，各种屏幕尺寸和形态一下子都冒出来了。

And there was this device revolution that the iPhone set off, and all of a sudden we have all of these different form factors.

现在可不只是Windows电脑在桌面上了。

It's not just Windows PCs on the desktop anymore.

各种各样的设备都冒出来了。

It's all sorts of diverse devices.

可巧的是，这些设备全都运行着支持JavaScript的浏览器。

But lo and behold, they all run browsers with JavaScript in.

说来也巧，真正跨平台的语言根本不是Java。

Lo and behold, the real cross platform language isn't Java.

而是JavaScript。

It's JavaScript.

谁能想到呢？

Who would have thought?

没错。

Exactly.

于是，世界开始意识到这一点，纷纷用JavaScript开发越来越庞大的应用。

And so the world started opening its eyes to that and and started building larger and larger applications in JavaScript.

我们不仅在外面看到了这一点，内部也是如此。

And we saw that externally, but also internally.

其中一个关键转折点是，Outlook.com团队来找C团队，问我们能不能把一个叫Script Sharp的东西产品化。

And one of the trigger events was when the outlook.comteam came to see the C team and asked us whether we would pretty please productize this thing called Script Sharp.

我们当时就问：Script Sharp？那是什么东西？

And we go, well, what is what is Script Sharp?

它是一个交叉编译器，能把C#代码编译成JavaScript，这样你就能把JavaScript当成一种指令语言，让C#应用在浏览器里运行。

It's this cross compiler that allows you to cross compile C Sharp into JavaScript such that you can basically treat JavaScript as an instruction language and and run your C apps in a browser.

我当时就想：谁会想这么干啊？

And I'm like, well, why would anyone want to do that?

因为这样你就能用上真正专业的编程语言和配套工具。

Well, because then you can get a grown up programming language with grown up tooling.

你可以用Visual Studio。

You can use Visual Studio.

还能创建项目，管理代码结构。

You can you can have projects.

你可以做这么多棒的事情，你知道的，这些在 JavaScript 里根本做不到，因为 JavaScript 就是个工具差劲的脚本语言。

You can do all of these wonderful things, you know, that you can't do with JavaScript because JavaScript is just the scripting language with with shitty tooling.

我们当时就惊了。

And we were like, wow.

真的吗？

Really?

天哪。

Well, gosh.

也许更好的办法是直接把 JavaScript 本身改进一下。

Well, perhaps a better approach would be to fix JavaScript.

我的意思是，你不可能靠让人用别的语言写代码，就在 JavaScript 生态里做到顶尖。

I mean surely you're not going to be best of breed in the JavaScript ecosystem by telling people to write in a different programming language.

虽然确实很多人还记得 CoffeeScript 那些专门为 JavaScript 设计的语言。

Although plenty of people were like, remember CoffeeScript and all

还有其他那些瞄准 JavaScript 的语言，对吧？

of these other languages that targeted JavaScript, right?

是的。

Yes.

它们是一种编程语言，能生成 JavaScript，但本身并不是 JavaScript，对吧。

So they were a programming language, right, which generated JavaScript, but it wasn't JavaScript itself, yes.

是的。

Yes.

它们曾经非常流行。

They were super popular.

我的意思是，当时有好多不同的工具都这么干。

I mean, like, so many different things did that.

但 JavaScript 其实是个挺不错的轻量级语言。

But JavaScript is actually a pretty decent little language.

只是缺了那么几样东西。

There are just some things missing.

得给布兰登·艾克一些肯定。

You gotta give credit there to Brendan Ike.

我的意思是，他真正理解函数式编程。

I mean, he he understood functional programming.

而JavaScript的创造者布兰登·艾克，

And Brendan Ike, the the creator of JavaScript.

他直接把函数作为一等公民引入了JavaScript，这简直是福音，非常优雅，但缺少类型系统。

And he got functions as first class objects right in JavaScript, which is godsend and and beautiful, but it doesn't have a type system.

没错。

And Yep.

我们从实践中早就明白，没有类型系统，就做不出好的开发工具。

We knew from experience that you cannot build good tooling without a type system.

你可以做出还不错的工具，但永远无法规模化。

You can build decent tooling, but it's never going to scale.

因为团队一大，你就没法在代码里清晰表达意图。

It's never going to scale to large teams because you can't describe your intents in the code.

这些东西都没法形式化，没法分析，也没法在IDE里实现代码补全、重构、跳转定义、查找所有引用这些功能，所有这些都做不了。

There's no way of formalizing any of this stuff, and there's no way of analyzing it, and there's no way of using it in an IDE to give you statement completion and refactoring and go to definition and find all references and blah blah blah blah, all of that stuff.

对吧？

Right?

这就催生了一个想法：我们可以创建一个 JavaScript 的超集，加上类型系统，然后把它编译掉。

That germinated the idea of, hey, we could create a superset of JavaScript that adds a type system, and then we could just compile it away.

这样一来，我们就有了打造优秀工具的基础，还能在此之上构建更好的开发体验，对吧？

But then we have, now we have the foundation for great tooling, and then we could build a great tooling on top and actually create a wonderful development experience, right?

这其实就是我们当初想做的事。

That was sort of like what we set out to do.

你们当初做这件事的时候，不仅要做它，还偏偏选择开源，这让微软以外的人都很意外，因为那时候在史蒂夫·鲍尔默领导下的微软，大家普遍觉得他们反开源，尤其是当年的 Windows 和 C 语言时代。

When you set out to do this, you not only set out to do this, but you set out for some reason to do it as open source, which took everyone outside of Microsoft as a surprise because old Microsoft under Steve Ballmer was notoriously perceived as anti open source back then, with Windows and C back in the day, of course, I'm talking about.

你知道，微软其实慢慢意识到，开源不会消失，开发者们就是想要开源，他们早就用脚投票了。

You know, Microsoft was slowly waking up to the fact that open source was not gonna go away, and open source was where developers wanted to be, and they were boating with their feet.

但公司里还是有一股根深蒂固的惯性，总在把你往相反的方向拉。

Yet, there's a collective DNA, you know, that has been trained to pull you in the other direction.

对吧？

Right?

所以我们正好处在那场斗争的中心。

And and and so that battle was we were right in the center of that.

我们很清楚，如果用微软的专有许可证推出一门编程语言，根本不可能被 JavaScript 生态系统接受。

And we we full well knew that there was absolutely zero chance that we would appeal to the JavaScript ecosystem with a proprietary programming language license from Microsoft.

不可能。

No.

根本没人会来。

No one was gonna come.

必须是开源的。

It had to be open source.

这一点毫无商量的余地。

There was just no two ways about it.

对吧？

Right?

但在微软内部推动这件事，可没少费劲，也付出了不少代价。

But getting that off the ground inside Microsoft, it took some some pulling, and we paid some taxes.

我们最后终于得到了许可，可以做开源，因为我和史蒂夫·卢科——这位TypeScript的另一位共同发明人——坚持认为我们必须这么做。

We we did eventually get the okay to do open source because we had two technical fellows, myself and Steve Luco, who was the the other co inventor of of of of TypeScript, insisting that that was what we had to do.

所以，好吧，没人会在这事上争辩了。

And so, okay, there people weren't gonna debate that.

但你当然得交‘税’，得把代码放到微软的开源平台CodePlex上，而那里根本没人去。

But of course you have to pay the tax and be on Microsoft's open source repository called Codeplex, where exactly no one was.

前两年我们就在那儿，安静得连个回音都没有。

And so we were there for the first two years, and it kind of was crickets, you know.

直到2014年我们迁到GitHub，真正开始有人使用，事情才有了起色。

And it wasn't until 2014 when we moved on to GitHub that things really started to get moving with adoption.

而且，我们的开发流程也彻底变了。

And also, it totally changed our workflow.

你知道，开源和开放开发是两回事。

You know, there's open source and there's open development.

一开始我们虽然是开源的，但并不是开放开发。

We were technically open source in the beginning, but it was not open development.

我们以前会把源代码丢进这个仓库，然后从那儿抓取问题，再导入到我们内部的问题追踪系统里，你知道的。

We would sort of lop the source code out in this repository and scrape the issues off of that and put it into our internal issue tracker, then, you know.

但一旦我们迁移到 GitHub，整个开发流程就彻底转向了开放协作。

But once we switched to GitHub, the entire workflow moved to open development also.

我特别喜欢这种开发方式。

And that I love that workflow.

我们已经在 GitHub 上待了十多年，效果非常好。

And that's we've been there now for over a decade, and it's been fantastic.

正是这一点，让这个产品变得如此出色。

And it's what made the product as good as it is.

十多年过去了，这个语言是在 2014 年搬到 GitHub 的。

Just over a decade later, so the the language moved to GitHub in 2014.

到了 2025 年 11 月，GitHub 的十月报告指出，TypeScript 已经成为 GitHub 上最受欢迎的语言。

And in November 2025, the the GitHub October's report revealed that TypeScript became the most popular language across GitHub.

除了类型系统之外，你觉得是什么让 TypeScript 如此受欢迎？

Outside of the type system, what do you think made TypeScript this popular?

当然，我们还有其他语言，比如 Python 也很受欢迎，但是什么让 TypeScript 如此俘获开发者的青睐呢？

And of course, we've had other languages, Python being the other very popular one, but what captures developers' preferences this well?

我觉得这可不是一夜之间发生的，回头看看，我们突然从第十名开始，然后逐年稳步上升，最后就跟 JavaScript 并肩了，对吧？

Well, I think, you know, it didn't just happen overnight, you know, and if you look back at that, you know, all of a sudden we we surfaced as number 10, and then we climbed slowly over the years up and and and sat next to JavaScript, right?

当然了，如果你把 JavaScript 和 TypeScript 合起来算，我们早就已经是第一了。

And of course, if you add a JavaScript and TypeScript together, then we were already number one.

关键就看用哪种语法了。

It's just which syntax?

你用不用类型注解而已。

Were you using type annotations or not?

随着时间推移，越来越多的人慢慢选择了这种方式。

And more and more people over time just decided to adopt that.

其实早期就有人用 JSDoc 之类的，就是把类型写在注释里，我们后来也支持了这些。

I mean, some early on were using JSDoc or whatever, you know, like these types in comments that we also supported.

但渐渐地，大家终于意识到，这才是正确的做法。

But gradually, I think people just realized, hey, this is the right way to do it.

他们之所以选择，我觉得完全是由于更好的开发工具。

And the reason they came, I think, is absolutely because of the better tooling.

我们当时完全想对了——加入一个可擦除的类型系统，再用它来提升工具体验，这才是真正提升程序员效率的关键。

And I think we were totally right there that, like, adding an erasable type system and then using that to enable great tooling is really where the pro where the programmer productivity boost is realized.

我想这也是我们不能不提 Visual Studio Code 的地方，它把这套强大的工具免费提供给了大多数人，至少最初是这样，这也起到了很大作用。

And I guess this is where we cannot, like, not mention Versus Code, which shipped that great tooling also as a free to use for most people, or at least initially for most people, which also made a big difference.

没错，确实如此。

Absolutely, yeah.

那是我们的姊妹项目，用 TypeScript 写的，也是我们最早的用户之一，直到今天我们也和他们保持着紧密合作。

That's our sister project, which is written in TypeScript, and so they were one of our earliest adopters, and we work pretty closely with them to this day.

这种相互促进的关系，反过来还催生了 LSP——语言服务器协议，现在几乎所有的工具厂商都用它来在 IDE 里实现交互式功能。

That whole interplay, that in turn is also what led to the invention of LSP, the language server protocol that now pretty much every tool vendor uses to enable interactive services in the IDE.

说来有趣，直到现在我们迁移到 Go 时才改用 LSP，因为当初刚把 TypeScript 集成进 Visual Studio Code 时，LSP 还不存在，我们自己先搞了个雏形。

Oddly, it isn't until this port to go now that we're switching to LSP, we had our own precursor of LSP because LSP didn't exist when we first integrated TypeScript into into Visual Studio Code.

但那段经历确实让我们学到了很多。

But there were a lot of learnings from from that.

所以，同时在开源环境下开发这两个项目，是一段极其互补且充满成就感的经历。

So it's it's been an incredibly symbiotic and and fulfilling experience to build these two projects in parallel in open source.

我觉得这彻底改变了开发者群体对微软的看法。

And I think it has totally changed people's view of Microsoft in in the developer ecosystem.

对我们这些不太熟悉编译器的开发者来说，我用 TypeScript，也知道它背后有编译过程。

For us, developers who, again, are not as familiar with compilers themselves, we, of course, like, I I use TypeScript and I I'm aware that there's some compilation going.

你能简单介绍一下，这个编译流程主要包含哪些部分？你个人更关注哪些环节？

You give us a brief overview of what the types of compiler pipeline looks like in terms of parts and what parts you specifically focus on more?

当然可以。

Sure.

它在很多方面是典型的编译器，但在很多方面又不是。

It's in many ways a fairly typical compiler and in many ways not.

几乎所有的编译器都会有一个词法分析器，也就是扫描器，负责把源代码文本转换成词法单元。

Pretty much every compiler has, you know, what's known as a lexer or a scanner that takes text and turns it into tokens.

然后在这之上，通常会有一个解析器，它接收这些词法单元，检查它们的顺序，生成抽象语法树——这是一种可以遍历的树形结构，本质上是对源代码的结构化映射，把代码拆解成语法基本单元，并验证语法是否正确。

And then typically on top of that, you have a parser that takes the tokens, checks their sequencing, and then makes abstract syntax trees, which is a, you know, a tree that you can navigate that effectively is a map of the source code, you know, but broken into syntactic primitives and checked that, you know, like syntactically everything is, or grammatically that everything is correct.

所以，这是流水线的前两个阶段。

So those are the first two stages of the pipeline.

接下来我们还有一个额外的步骤，叫作绑定器。一旦有了解析树，我们就会把符号信息关联上去，找出所有变量的声明，建立符号表，并把它们连接到对应的函数上，这样后面就能高效地查找名称了。

Then we have well, we have a a one extra pass that we call the binder, which is, you know, once we have the parse trees, then we bind symbol information to them where we find all of the declarations of variables and whatever and build symbol tables and attach them to their functions such that we can then later look up names effectively.

在绑定器阶段，我们还会生成控制流图，我可以讲讲它能帮我们做什么。

And we also build in the binder, we build a control flow graph, and I can talk about what what that helps us do.

然后就是类型检查器，这是我们流水线中最核心的部分。

And then we have the type checker, which is the largest part of our pipeline.

它负责从语义层面检查你的程序是否正确。

And that's the the thing that checks semantically that your program is correct.

它会推断类型，验证类型之间的关系是否合理，确保你把正确的值赋给正确的变量，调用的函数确实存在，诸如此类。

It's the thing that figures out types and checks that the types relate correctly and that you're assigning the right thing to the right thing, and then that, you know, that you're calling something that actually exists and so forth.

最后还有一个可选的阶段，叫作生成器。

And then we have an optional stage at the end called our emitter.

通常编译器里的生成器模块也相当庞大，因为这里要将中间表示转换成机器码或字节码。

And normally the emitter infrastructure in a compiler is also quite big because that's where you go from intermediate representation to machine code or byte code.

在我们这里，其实就是把类型信息直接去掉。

Now, in our case, we just erase types, if you will.

实际上，我们的编译器做了两件事。

Well, we kind of do two things in our compiler, actually.

早期的时候，我们主要做两件事：一是去掉类型，二是把代码降级。

Early on, it was very much about A, erasing the types, but B, also down leveling your code.

比如遇到一些运行时还不支持的新版 ECMAScript 特性，像类这样的，我们会把它转成构造函数之类的旧写法。

So we would take newer ECMAScript features that weren't yet supported by the runtimes, for example, classes, and then we would down level them to constructor functions and whatever.

所以我们得重写代码。

And so we would rewrite the code.

那时候这个功能特别受欢迎。

And that was a very popular feature early on.

现在几乎所有浏览器都自动更新了，ECMAScript 的新特性也都跟上了，所以这事儿就没那么重要了。

Now, pretty much every browser is evergreen and, you know, like ECMAScript features are caught up, so that's not as important anymore.

所以我们的输出模块本质上就是去掉类型注解，输出可以直接运行的纯 JavaScript 代码，同时还能生成声明文件，也就是对你的模块内容做一个摘要。

So our emitter is effectively, you know, a thing that just erases type annotations and spits out the JavaScript code that can run unannotated and also can spit out declaration files, which are summaries of of your modules and and so forth.

但这些基本上就是各个阶段了。

But those are sort of the stages.

不过，编译器的一个有趣之处在于，它是按高度交互的方式设计的，这正是IDE所依赖的模式。

Now the thing that's interesting about the compiler, though, is that it's built in a manner that where it can function in a highly interactive mode, which is what the IDE uses.

通常来说，命令行编译器就是一路走完这些步骤，输出要么是生成的代码，要么就是一些错误信息。

Normally, you know, command line compilers, they just run through these stages and, you know, the output is just whatever gets emitted or some error messages.

对吧？

Right?

但在IDE里，编译器其实是一个后台服务。

But in an IDE, you know, the compiler is a service.

在这个服务里，我们处理的程序其实一直处于不完整状态——因为你正在打字，但即便如此，我们还是要尝试做语法或语义分析。

And what we do in that service is we basically take a program that is perpetually broken because you're typing, and yet we try to syntactically or semantically analyze it.

因为我们得知道，当你按下点号的时候，后面可能跟什么。

And because we need to know when you press dot here, what could come next?

这就意味着，我们必须知道你点的是什么东西的类型。

Well, that means we need to know what is the type of the thing you dotted on.

为了弄清楚这一点，我们可能得解析一些内容。

In order for to figure that out, we may have to resolve stuff.

我们可能得看看这边的抽象语法树之类的东西。

We may have to look at ASTs over here and whatever.

所有这些操作都必须在两百毫秒内完成，不然用户会觉得IDE太卡了。

And all of that has to happen within two hundred milliseconds or else people think the IDE is slow.

对吧？

Right?

那如果你有五十万行代码呢？

Well, what if you have 500,000 lines of code?

你不可能在两百毫秒内编译完这么多代码。

You can't compile all of those in two hundred milliseconds.

所以你得做得特别特别延迟，而且要高度交互。

So you got to be super, super deferred and interactive.

因此你只能做最少的工作。

And so you got to do minimal amounts of work.

我们的编译器就是这样设计的，它会尽量提前处理，比如你有五十万行代码的时候。

And that's how our compiler is built is it tries to front load, like for example, like you have 500,000 lines of code.

假设分布在五百个文件里。

Well, let's say in 500 files.

我们可以先为其中四百九十九个文件生成抽象语法树，然后把它们搁在那儿不动。

Well, we could build the ASTs for 499 of the files and just sit on them.

没必要重新生成，因为你没在那些文件里做修改。

We don't have to rebuild those because you're not editing in those files.

我们只需要更新你当前正在编辑的这个文件的语法树就行了。

We just have to update the AST of the current file you're in.

这样一来，速度比全量重算快了五百倍，对吧？

So that goes 500 times faster, right, than than if we had to do all of it.

而且我们也不用去推导这里面所有的类型。

And then we don't actually have to figure out all of the types in here either.

只需要从你当前的位置开始，算出足够回答你当前问题的那部分信息就够了。

We can just start where you're at and then just resolve just enough to answer the question that you're needing an answer for right now.

所以编译器内部的一切都是惰性处理、延迟执行、函数式且可复用的。

And so everything is lazy and deferred and functional and reusable inside the compiler.

这种编写编译器的方式，跟传统教科书教的完全不同。

And it's a very different way of writing compilers than than what the textbooks will traditionally teach you.

是的。

Yeah.

因为我觉得，现在这些其实更像是交互式编译器，对吧？

Because I I guess this is now these are interactive compilers, if you will.

没错。

Right?

听起来这已经不只是一个编译器了，而是要解决一个复杂得多的问题。

It sounds like it's it's it's more than a compiler or a lot more difficult problem to solve.

底层引擎其实是一样的，但你得把它设计成能高度响应交互的形式。

The same engine is there, but but you gotta build it in a in a manner where it can be very interactive.

而这一点，过去在编译器设计里通常并不重要。

And that was not typically important for compilers.

你懂的。

You know?

所以 TypeScript 是 JavaScript 的超集。

And so TypeScript is a superset of JavaScript.

如果 JavaScript 允许的话，或者你能影响它的开发路线，你会想添加哪些功能？

What are some features you would try to add if only JavaScript would allow it or if you were able to influence JavaScript's roadmap?

你觉得有什么能大幅改进 TypeScript 的地方？

What what is something that you feel could make TypeScript a lot better?

但当然，这里是有局限的。

But, of course, there's a constraint there.

我们一直关注 ECMAScript 委员会的进展，只要新特性在标准化流程中达到第三或第四阶段，我们就会立刻实现，从一开始我们就一直跟在这个节奏上。

We track the ECMAScript committee, and and and and, you know, new language features that get developed in ECMAScript, we we implement once they reach stage three or four in the standardizations committee, and we've sort of been on that train ever since the beginning.

所以，有一套标准化的流程在持续为语言提供新特性。

So there is a pipeline that supplies new language features in a standardized manner.

我们觉得自己的职责就是在这之上构建类型系统。

We sort of see it as our purview to define the type system on top.

对吧？

Right?

所以，这么说吧，这就是我们的试验场。

So that is, if you will, our our playground.

但我还是希望语言本身能支持一些功能。

Now I still have things that I wish I could have in the language itself.

我喜欢函数式编程。

I mean, I like functional programming.

我喜欢函数式编程语言，它们的关键在于一切都是表达式。

I like functional programming languages, and and key to them is that that everything is an expression.

语句和表达式之间根本没有区别。

There's really no distinction between statements and expressions.

在我看来，JavaScript 缺少一个很重要的功能：没法给临时结果或表达式起个名字，然后重复使用。

And so one of the the features that JavaScript lacks in my in in my estimate is is the ability to give symbolic names to temporary results and expressions and then reuse them.

就像函数式语言里常见的那种写法——let x = something，在表达式里直接定义变量，像 Haskell、F# 这些语言都支持。

This is the let let blah equals whatever in some expression that functional programming languages, you know, like Camel and whatever all have.

这样挺好的，因为你完全可以停留在表达式上下文中，把各种操作连起来用，实现一种更流畅的编程风格。

And it's nice because you could just stay in an expression context, and you can just dot things together and and or whatever and sort of do this more fluent style of programming.

但突然间，你得给某个要重复用的东西命名，这时候就得跳出表达式，声明一个变量或者把它变成状态。

But then all of a sudden, you need a name for something you wanna reuse, and now you've got a pop out and declare a variable or turn it into state.

总之，这是我希望改进的一个地方。

Anyway, you know, that's one thing that I would like to fix.

现在有个叫 'do 表达式' 的东西，说不定哪天会出现，但进展太慢了。

There's there's something called do expressions that may or may not happen at some point, but it's taking a long time.

不过话说回来。

So anyway.

但总的来说，我觉得 JavaScript 是个挺不错的语言。

But, I mean, generally speaking, I think JavaScript is a is a nice little language.

它确实有些问题，不过我们用类型检查器把这些毛病都挑得挺清楚的。

It just has some issues, you know, and then and I think we're very good at teasing them out with our type checker.

对吧？

Right?

所以一旦你有了一个检查器，能提醒你‘你马上要干件蠢事了’，那问题就没那么严重了。

And so so once you have a checker that can warn you, hey, you're about to do something stupid here, then it's not so bad.

我觉得让这门语言特别的地方，也是跟其他编程语言很不一样的，就是它的渐进式类型系统。

The thing that makes it interesting, I think, and and unlike pretty much any other programming language, is the gradual typing.

也就是说，你可以用类型，但又不一定非得用。

This this notion that you can have types, but you don't have to have types.

其他语言都逼着你给所有东西都加上类型。

Other languages force you to type everything.

对吧？

Right?

因为那些语言会用类型信息来生成机器码，比如浮点数和整数用的指令不一样，但在 JavaScript 或 TypeScript 里，类型纯粹是为了开发体验和静态检查服务的。

Because they in turn use that information to generate machine code, you know, based on what the type is, you know, different instructions for float versus int versus whatever, where in JavaScript, the types or in TypeScript, the types are there purely for the development experience and the checking.

程序运行的时候，这些类型就全都没了。

When the program runs, they're all gone.

当然，类型还是存在的，只是它们都是运行时动态算出来的。

Now, of course, there are still types, but they're all dynamically computed.

但这其实挺有意思的，因为这意味着在语言里，我们不一定非得证明百分之百的正确性。

But that's kind of interesting because that means in the language, we don't necessarily have to prove 100% correctness.

我们很多语言特性，其实都做不到百分之百证明正确性。

And a lot of language features that we have, we can't 100% prove correctness.

比如在带有递归类型的结构化类型系统中，有些情况根本分析不了，因为类型会无限循环下去。

Like in a structural type system with recursive types, there are just cases that you can't analyze because the types are infinitely recurring.

你越想把两个类型关联起来，就越往深处钻，最后就直接陷进递归的深渊里了。

The more you try to relate two types, the deeper you go and you're just staring into the the recursive abyss.

你明白我的意思吧？

Do you know what I mean?

但你可以这么说，好吧，我们至少已经验证了四层。

But you can kind of go, well, well, we've proven it to four levels.

这大概就够了。

That's probably good enough.

我们就当它够好了。

We're just going to say it's good enough.

然后，如果其他都没问题，我们就会说，行吧。

And then, you know, if everything else works out, we're going to go, sure.

但如果你去生成机器码，而那玩意儿行为不确定，那就没法这么干。

That you can't do if, if you were to go generate machine code that then would have indeterminate behavior.

没错。

Right.

但 JavaScript 的运行时环境本来就把一切都定义得很清楚，所以我们哪怕只验证 99%，也比 JavaScript 那 0% 的检查强多了。

But if JavaScript has a runtime where everything is well defined already, so if we're checking 99% instead of 100%, well, heck, that's better than the 0% that JavaScript checked.

对吧？

Right?

而且它还让你能拥有其他语言根本做不到的语言特性，因为那些语言没法做到

And it gives you, like, language features that no other languages can provide because they can't get

100% 的保证。

to a 100%.

挺有意思的是，限制反而能催生创新，甚至局限也能带来更多的创新。

It's interesting how constraints lead to innovation or even limitations can lead to more innovation.

说到创新，现在最普遍的创新就是AI代理和AI编程工具，大多数软件工程师都在越来越多地使用这些AI工具。

Speaking of innovation, of the biggest innovations that is everywhere is AI agents, AI coding tools that us software engineers, most software engineers are using, increasingly using AI agents as well.

你们团队在开发比较小众的语言时，会用哪些AI工具？AI又是怎么帮助你们进行语言开发的呢？

As you're developing languages on a more, I guess, niche team, what kinds of AI tools are you using or how is AI helping your language development work?

是用TypeScript还是C语言？

May that be TypeScript or C?

我每天主要做TypeScript的工作，可以说说过去一年半我们是怎么逐步把TypeScript迁移到原生代码的。

Day to day, I work on TypeScript, and I can certainly talk about how we've been in the process of moving TypeScript to native code for the last year and a half or so.

刚开始做这个项目的时候，AI的能力远没有现在这么强，所以那时候根本用不了多少AI辅助。

In the beginning of that project, AI was nowhere near as capable as it is now, and therefore we could not really use much of it in the beginning.

不过现在，我觉得我们已经很好地把AI融入到工作中了。

At this point, though, I'd say we're using we're using AI fairly well.

当然，我们用的是GitHub。

Obviously, we're on GitHub.

我们用AI来审查代码和处理合并请求。

We use AI to code review, pull requests.

刚开始的时候效果并不好，但现在进步明显多了。

That in the beginning was not all that great, but now it's actually getting a lot better.

我们用AI来实现或修复一些简单的问题，尤其是在我们这个移植项目里，因为咱们是从一年半前的源码拷贝过来再迁移的，AI有时候还真能派上用场。

We use AI to implement issues or or fix issues, simple issues, and that it succeeds some of the time, in this port that we're doing, you know, because we snapped a copy of the source code from a year and a half ago and then ported it.

我们现在有一堆待处理的拉取请求要迁移到新的原生编译器上，所以就让AI帮忙处理这些PR。

We have a backlog of PRs that need to be moved on to the new native compiler, and so we're using AI to help us move those pull requests.

目前来看，这招效果还不错。

And that's actually going fairly well at this point.

另外，我们还用它来处理一堆繁琐的活儿，比如——

And then we use it for a bunch of drudgery drudgery work like, okay.

这个功能你看到了吧。

Here's this feature.

能按这些测试的风格，帮我写一组新的测试吗？

Please write me some tests in the same style as these other tests.

对吧？

Right?

然后一下子就搞定了。

And kaboom.

说实话，没人喜欢写测试。

It's like no one likes writing tests.

AI可喜欢写测试了，能源源不断地生成一堆，效果还挺好。

AI loves writing tests, and it'll just pump out more tests and great.

你知道的。

You know?

所以我们现在想用它来摆脱那些本来得花大量时间做的琐碎工作。

So so we're trying to use it to get rid of all the toil that otherwise we would spend our time on.

对吧？

Right?

但我觉得，离我们能完全依赖它、不用理解自己在做什么，还差得远。

But I would say we're not at a point where it absolves us from understanding what we're doing.

完全不行。

Not at all.

不对。

No.

再说，你是在构建一门语言，从技术栈的层面来看，确实需要有人真正理解这些底层原理。

Well, plus your level at the stack, if you will, because you're building a language, it might argue that someone really needs to understand at least one person.

理想情况下，整个团队都得掌握这些核心部分。

Ideally, the whole team needs to understand those fundamental parts.

对吧？

Right?

当然了。

Oh, absolutely.

而且，语言在AI领域特别有意思，就像我们现在的讨论，如果没有编程语言，根本不会有这样的对话——AI如果没有编程语言，又怎么实现确定性呢？

I mean, and and it's language is interesting in the in the world of AI because AI, like a lot of like this this conversation, we wouldn't have this conversation if it wasn't for languages because how would AI get to determinism without programming languages?

对吧？

Right?

说到底，AI本质上就是随机的、不确定的。

I mean, AI is by design stochastic and indeterminate.

你下次再问它同样的问题，它可能会给出不同的答案，要么是因为随机性，要么是因为模型更新了，或者其他原因。

It might give you a different answer the next time you ask it the same question, either just because random or because there's a new model or there's a whatever.

并不是说它完全没有确定性，而是说它本质上不是确定性的。

It's non it's not that it's there's no determinist.

但我们没法开发那些行为不确定的应用程序。

Yet we can't build applications if they're not if they have nondeterministic behavior.

你想啊，如果一个银行App动不动就胡编乱造，那会是什么样子？

I mean, what would a banking app look like if it, like, decided to hallucinate or or whatever, right?

所以你必须有个实实在在的落脚点，能让人理解、能复现行为的地方。

So you have to have something that where the rubber meets the road, and where you can reason about, and and where you can replicate the behavior.

每次运行应用，结果都得一模一样。

Every time you run the app, the same thing happens.

没错。

Absolutely.

我甚至发现，现在几乎所有AI代理或工具，只要你问它跟数据相关的问题，它往往一上来就写Python代码——我想AI的设计者们也意识到，到了某个阶段，你总得把不确定的东西变成确定的，而我们最熟悉、最高效的手段就是编程。

I mean, I even see it in a bunch I think almost all AI agents or tools these days when you ask it something to do with data, oftentimes they will start writing a Python program because I think the AI designers figured out that you at some point want to turn some non deterministic into a deterministic and what is the thing that we know most efficient.

是的

Yeah.

别问它

Don't ask it for

答案是什么。

the answer.

让它写一个计算答案的程序。

Ask it to write a program that computes the answer.

这样你就能确定结果是一致的。

And you will know that that will be deterministic.

对，就是这样。

Yes, exactly.

这真的很有趣。

It's very interesting.

但说到AI相关的语言，一个经常被提起的问题是，由于AI无处不在，它生成的代码越来越多。

But speaking of languages for AI, a question that comes up, of course because AI is everywhere, is generating a lot more code.

根据你看到的这些模式，你觉得是该调整现有语言来适应AI使用，还是干脆设计一种更适合AI代理使用的语言呢？

What is your take on either modifying existing languages for AI usage based on what you're seeing, the patterns, or potentially coming up with, would it make any sense to come up with a language that is more suited for AI agents to use?

我随便说一句，最适合AI的语言，其实就是它在训练数据里见得最多的那种语言。

Well, my flippant answer there is, you know, that the language that's most suited for AI is the language that AI has seen the most of in its training set.

对吧？

Right?

所以你可以说，AI在JavaScript、TypeScript和Python上表现这么好，就是因为这些语言它见得太多了，而且现在依然大量存在。

And that's why, you could argue, AI does really well on JavaScript and TypeScript and Python because it's seen an awful lot of it, and there's an awful lot of that still.

这其实形成了一个自我强化的循环，对吧？

That just reinforces itself, right?

你可能会说，TypeScript和JavaScript之所以流行，主要是因为浏览器，跟AI关系不大。

And you could argue, well, the reason TypeScript and JavaScript popular, well, that's mostly to do with the browser, not so much to do with AI.

但有意思的是，为什么AI更倾向于选择TypeScript而不是JavaScript呢？

But it's interesting to look at why is AI targeting TypeScript versus just JavaScript.

我觉得，类型系统其实能帮助AI写出更靠谱的代码。

And there, I think the types actually help guide the AI to producing better programs.

我觉得，既能没有上下文时手动输入类型，又能有上下文时自动推断，这种结合刚刚好。

And I think our combination of the ability to type something when there's no context, but also our ability to infer it when there is context is just the right combination.

因为如果强迫AI给每个变量都加类型注解，它反而更容易出错。

Because if you were to force AI to write a type annotation on everything, then it would probably get it wrong more often.

那样的话，它得一直记着所有这些类型，反复拆解、重复，没完没了。

Because now it has to keep track of all these types and rip and it and it has to just repeat itself over and over and over.

对吧？

Right?

所以，在没有上下文的时候类型很重要，但在避免重复、保持简洁方面，推断能力更关键。

And so types are important where there's no context, but inference is super important for for the dry or do not repeat yourself principle.

对吧？

Right?

而且，通常用的标记越少，AI的效率就越高。

And and and fewer tokens generally makes AI more efficient.

所以我觉得，我们这种做法很巧妙——只需要给最外层的参数标注类型，剩下的自然就能推出来。

And so so I think we have a very nice combo there in in how how you can just sort of type the outermost parameter and then everything

之后的所有内容都会顺理成章地推导出来。

flows from there on in.

没错。

Right.

现在AI已经在做的一件事，就是GitHub的团队统计数据显示，AI代理生成的代码量正在激增——它们不仅生成速度快，还常常写得特别啰嗦。

Now one one thing that AI is already revolting in, again, for the GitHub team share stats, so this is also open data that AI agents are generating a lot more code, I mean, they're both quick to generate, they also like to be sometimes verbose.

既然我们已经看到代码总量在各个项目、各个层面都在爆炸式增长，你觉得在这种大量代码——很多时候还是机器生成的——环境下，哪些语言特性会变得越来越重要？

Knowing that we are already seeing a lot more code pushed everywhere and at a project level, at an aggregate level, what what do you think language characteristics could become more important in this world of just a lot more code, oftentimes generated by machines?

你可以这么说，互联网上的真实信息可能早就过了峰值了，对吧？

I mean, you could argue that we're already past peak truth on the Internet, right?

现在每天都在涌进越来越多的垃圾内容。

And now there's just more and more garbage every day.

要想从海量数据里挑出真正值得放进训练集、能帮助模型变得更聪明的部分，变得越来越困难了。

It gets harder and harder to suss out the stuff that you do wanna include in the training set in order to actually make something more intelligent.

所以我觉得，这种逐步改进的过程肯定有人在做，我确信。

So I think that gradual I mean, I'm sure people are working on it.

我觉得这可能会带来问题。

I could see that as as as becoming problematic.

适合AI的语言，我觉得像类型和推断这些特性都很重要。

Languages that are suitable for AI, I I think, like I talked about types and inference.

这两点确实都很关键。

I think both of those are important.

我觉得局部性也很重要。

I think also locality is is important.

局部性？

Locality?

我的意思是，别搞一堆全局变量，让AI得去理解整个项目里那些该死的头文件。

Well, what I mean by that is, like, don't have a bunch of global stuff where AI has to grok the entire prod oh, these pound include files that are, oh my god.

谁知道这些变量到底在哪儿生效，又该怎么放进上下文窗口里呢？

Well, who knows where they're in scope and and how do I put that in the context window or not?

然后还得浪费海量的token去强行包含它们？

And then then do I burn like a gazillion tokens on on trying to include?

但如果你的代码局部性好，明确声明了每个导入的内容，就能只分析单个源文件，从中提取出它对外的接口，而不需要深入了解其他部分。

But but if you have good locality where you're you're clearly stating what you're importing and whatever, and and you can analyze just a single source file, and from that extract its protocol to the outside world without having to to know anything deeper.

你明白我的意思吗？

Do you know what I mean?

我觉得这些特性很重要，不仅能缩小上下文窗口的规模，还能让每个模块更容易被总结。

I think those are important aspects just simply to reduce the size of the of the context window and also make it easier to summarize each module in a program.

没错。

Right.

这太有意思了，我记得大概十五年前，PHP 就因为全局变量被很多人批评。

This is so fascinating because I remember this was probably fifteen years ago where PHP was very much critiqued for its globals.

那时候我还是个新手，根本不明白为什么这会是个大问题。

And early on, didn't understand as a young developer why that was a deal.

我只是随便写写 PHP，直到有一次程序出错了，才发现是某个导入覆盖了全局变量，这才明白：当变量遍布整个代码库时，全局变量可能藏在任何地方，你根本没法知道别人会不会改了你的状态——这不就是你刚才说的那个问题吗？

Was just hacking around in PHP until I had the issue of something was not working and turns out that something import overwrote a global and suddenly you realize that when things are defined across the code base, a global could be anywhere and there's no way for you to know when someone else is doing your now back to the state problem, which you just talked about.

最初的 JavaScript 也饱受这个问题困扰。

Original JavaScript suffered from this problem.

那时候根本就没有模块，对吧？

There were no modules, right?

所有东西都是全局的，谁都能随便修改别人的代码，根本没法知道你到底依赖着什么。

Everything was global, and anyone could just monkey patch anything else, And it was impossible to know really what what what am I sitting on top of here.

但现在有了 ECMAScript 模块，情况正变得越来越合理，JavaScript 生态里越来越多代码都按这种方式写了。

But now with ECMAScript modules and whatever, we're we're we're moving towards sanity, and more and more the world is written that way in the JavaScript ecosystem.

这是好事，我觉得将来对 AI 也会有帮助。

And that's a good thing, and I think that will help us down the line with AI.

AI 才刚开始意识到语言服务的存在。

AI, it's just starting to become aware of, you know, the existence of language services.

现在的智能代理喜欢用 grep、oc 之类的工具，到处找某个东西被引用的地方，但那不是语义搜索，对吧？

Agents today like to use grep and oc and whatever, you know, to find all the places where you reference a certain thing, but it's not semantic search, right?

如果你用的属性名很常见，比如 count、address 之类的，对吧？

And so if you have a common name for this property, like count or address or or whatever, right?

那它就会找到一大堆叫 address 的属性，结果根本分不清你到底要改的是哪一个。

Well, it's gonna find a whole bunch of properties named address, and then that that's not gonna work so well because now you you don't know that you're renaming the right one, right?

但这时候，语言服务和语义搜索就派上用场了。

But this is where language services come in and and semantic search.

我觉得随着人工智能的发展，这一点会变得越来越重要。

And I think that's gonna increasingly become more important with AI.

其实，这些功能已经有语言服务器协议的实现提供了，只不过可能需要稍作调整，才能让AI更方便地使用。

And really, these are services that are already provided by LSP implementations, but they may need some tweaking in order for them to be more accessible to AI.

AI喜欢命令行工具，但这些其实并不是真正的命令行工具。

AI likes command line tools, you know, and they're not really command line tools.

我也在想，性能会不会是个关键点，毕竟我们知道这些服务可以跑得更快，更快的反馈循环显然更有帮助。

And I I also wonder if if, for example, performance will be interesting because we know that these things can can run faster, so faster feedback loops will be clearly helpful.

我们现在又回到了TypeScript当年如此受欢迎的原因之一。

We're now going back to one of reasons that TypeScript was so popular.

你提到过，那两百毫秒的反馈延迟。

You said the two hundred milliseconds of getting you feedback.

对吧？

Right?

但其实有办法让服务器一直保持项目活跃，持续提供语言服务，这样AI就能随时提出语义层面的问题之类的。

But there are ways of, you know, where where you could imagine, you know, like a server keeping a project hot and giving your LSP services, you know, that AI can ask semantic questions and whatever.

一旦AI十分钟不再提问，服务器就自动释放资源，就这么简单。

Then once AI stops asking after ten minutes, the server just dumps it, you know, and whatever.

我觉得，我们完全可以通过这种方式取得一些进展。

So there are ways of putting this together, I think, where we can make some progress on on.

因为AI在生成代码的同时能语义验证代码，这种能力会变得越来越重要。

Because, like, the ability for AI to semantically validate the code that it's generating as it's generating it will increasingly become important.

那软件工程这门手艺呢？

What about the software craft?

你在这个行业几十年了，但你没法忽视这些工具正逐渐进入日常开发，就像当年图形化开发环境取代了命令行，高级语言取代了汇编一样——AI代理和AI工具终将成为开发的一部分。

You've been in this industry for many decades, but it's hard to unsee that these tools are just coming to everyday use similar to how at some point graphical IDs came before that, I guess, the higher level languages came, knowing that AI agents and AI tools will be part of the craft.

你认为软件工程师的哪些技能会变得不那么重要，又有哪些会变得更关键？

What do you think parts of software engineer craft will become less important, and what might become more important?

某种程度上，我们都在变成项目经理，对吧？

In a sense, we're all turning into project managers, right?

我们可以有一支由初级程序员组成的团队——也就是这些智能代理，它们会源源不断地生成大量代码，但总得有人把握全局，审查所有这些成果。

And we can have an army of junior programmers called agents that will just spit out reams of code, but someone's got to have the big picture and review all of that.

所以，我们的工作重心正逐渐从写代码转向审查代码、设计架构、监督整个开发流程。

And so increasingly, our craft is going from one of writing the code to one of reviewing the code and building the architecture of the code and overseeing the work, if you will.

这是一种全新的技艺。

It's a different kind of craft.

也是一种全新的成就感。

It's a different kind of enjoyment.

我一向喜欢亲手写代码。

I've always liked writing the code.

对我来说，最满足的时刻就是看到代码真正跑起来。

You know, to me, that was the fulfilling part, seeing it work.

你明白我的意思吗？

Do you know what I mean?

某种程度上，AI确实夺走了一部分这种乐趣，对吧？

And in a way, AI robs a little bit of that, right?

说实话，我对审查代码的兴趣没那么大了。

I mean, because I am less interested in reviewing code.

但我认为，我们完全可以让代码审查的过程比现在有趣得多。

But I think we could also make the process of reviewing code much more interesting than it is today.

对吧？

Right?

现在呢，你看到的是一堆按字母顺序排列的代码差异，全得靠你自己去琢磨到底改了什么。

I mean, today, you see a list of of diffs in alphabetical order, and and now it's up to you to to make heads or tails of it.

其实完全可以换种更有教学意义的方式来呈现，比如让AI自动生成说明，告诉你这些改动是干嘛的，再一步步引导你理解。

I mean, there are more pedagogical ways of presenting that, and you could have commentary generated by the AI that tells you what the changes are and whatever, and then tries to guide you along.

你明白我的意思吗？

Do know what mean?

这种人机协作的关系，我觉得还得再好好打磨，才能让其中的乐趣保留下来。

So that symbiotic relationship, I think we need to work on that more, and sort of to keep the enjoyment in there.

但我觉得，指望AI彻底取代程序员，这种想法太天真了，其实也挺好。

But I think it's foolish to think that AI will just eliminate programmers, ultimately that's great.

你知道， vibe 编程挺棒的，只要能跑起来就行。

Know, like vibe coding is wonderful as long as it works.

可一旦出问题，你就完全懵了，根本没法让 AI 把它修好。

And then the minute it goes off track, then you're like, you have no idea what's going on and you can't convince the AI to fix it.

那这时候你怎么办？

And so what do you do?

你没法把自己该懂的东西全推给 AI。

You can't absolve yourself from understanding what's going on.

那不叫编程。

That that's not That's not programming.

归根结底，程序的责任不在 AI，而在程序员身上。

And ultimately also, you know, the responsibility for a program does not lie with the AI, it lies with the programmer.

你总不能回头去怪 AI，说‘你太差了，我开除你’吧。

You're not gonna go back to the AI and say, shame on you, I'm gonna fire you.

这话听起来不觉得荒谬吗？

What does that even mean, right?

我的意思是，现在你什么都没有了，你得有人来承担这份责任。

I mean, now you have nothing, you know, it's no, you need someone to have that function of being responsible.

所以归根结底，AI 是帮我们提升效率的工具，我觉得是这样。

And so that's, you know, so ultimately AI is a tool to enable us to become more productive, I think.

但它肯定会改变我们写程序的方式，这点毫无疑问。

But it will change the way that we write our programs, for sure.

你总不能坐在那儿，一个字一个字地敲 AI 一分钟就能打完的内容吧。

I mean, there's no point in in in in sitting there and typing in stuff that AI could type a 100 times faster.

你说对吧？

You know?

你创造了三种被广泛使用的编程语言，那你从开发者身上学到了什么？他们到底在乎什么，

Having created three very widely used programming languages, what have you learned about developers, about what they care about when it comes

哪些东西他们根本不在意，压根儿想不到，但你却必须反复琢磨？

to programming languages, and stuff that maybe they don't care too much about, don't even think about it, but you might have to think

a lot about?

a lot about?

你知道吗，归根结底，开发者最在乎的是效率。

You know, I think at the end of the day, developers care about being productive.

他们希望进入那种状态——感觉一切都在顺顺利利地运转。

They care about being in the zone where they feel like, oh yeah, this thing is just clicking for me.

工具正好做对了事，就像在回应我一样。

It's doing just the right thing, and it's like answering me.

而且它就在那儿，随时待命。

But it's right there.

它就像是我指尖的延伸。

It's an extension of my fingertips.

对吧？

Right?

所以作为语言设计者，我从不只看语言本身。

So for me as a language designer, I'm never just looking at the language.

你得看全局，看整个使用体验，因为你真正创造的，是程序员一生中大部分时间都会沉浸其中的体验。

It's you're looking, you gotta look at the whole picture, the whole experience, because really what you're doing is you're creating an experience, an experience that programmers will spend the majority of their working life in.

这就是为什么程序员会对自己的工具和语言产生这么深的依恋，对吧？

Which is why programmers become so attached to their tools, you know, and their languages, right?

说真的，这几乎像一种信仰，你用什么语言、什么工具，因为它们已经深深融入你的工作流程，让你能轻松进入心流状态。

I mean, it's almost a religious thing, which language you're and which tool you're using, and because it's so ingrained in your workflow, and and it so enables you to to be in the zone.

对吧？

Right?

所以我认为，这才是关键所在，也是我这些年在工作中一直努力去实现的。

So that, I think, is the that's the key to focus on, and that's what I've tried to do with with the with the work that I've done over the years.

听起来这就是为什么从一开始，你就特别关注开发者日常使用的集成开发环境了。

And it sounds like this is why, from the very beginning, you also focus on the IDE, the the tool where developers spend their time in.

没错。

Yeah.

这两者缺一不可。

You can't have one without the other.

当然可以分开，但效果就差远了。

Well, you can, but but it's just not it's not nearly as effective.

是的。

Yeah.

我们现在开始看到一个问题，更像一个疑问：未来我们一整天到底要在IDE里待多久，还是转向那些新界面——比如能同时管理多个任务的智能代理，或者命令行，毕竟我们发现代理可以异步工作。但整个行业还在摸索，到底什么才是未来的发展方向。

One question we're starting to see, it's more of a question mark, is, well, how much are we going to be in the IDE all day versus these new interfaces, which might be agents where you can manage multiple things or command line, which is, again, just something where we found that agents can work asynchronously, but I think we're still figuring out as an industry of, like, what what will come next.

对。

Yeah.

目前我们还看不清未来的稳定状态，因为变化实在太快了。

I don't know that we can see the steady state at this point because it's it's it's evolving so much.

但我依然相信，程序员在这场变革中依然会扮演重要角色，你知道的。

But I still believe that that programmers are gonna be relevant in in in this equation, you know.

我从根本上就这么认为。

I I I fundamentally believe that.

那性能和效率呢？

What about performance and efficiency?

你提到早年你第一台电脑只有几KB内存，还得把编译器塞进12KB里，可现在，我连一个比这更小的文本文件都很难创建出来。

Early on in your career, you just mentioned that your first computer you've had on how many kilobytes it had and how you you fit your compiler into 12 kilobytes, which these days, I I cannot even create a text a text file that's smaller than that, or it's very hard to do.

对吧？

Right?

但几十年前，写高效的程序确实很重要。

But it seems in those in the, you know, like, few decades ago, writing efficient programs was important.

随着时间推移，我觉得这方面的关注在慢慢减少。

And over time, my perception is that it's becoming less of a focus.

你怎么看这个问题？

What is your take on that?

你觉得我们开发者可以完全忽略效率吗？是因为现在资源太充裕了，还是说将来情况会变？

And do you think it's kind of fine for us developers to forget about efficiency or we're just allowed to do that because of we have more resources, or maybe this will change?

我觉得这得看具体情况。

I think it's a case of it depends.

有些类型的程序，效率是绝对关键的。

There are certain classes of apps for which efficiency is absolutely key.

比如我们团队做的编译器和开发工具这类东西，大家还是很在意的。

I mean, like, the kind of program that my group works on, like compilers, tooling, and whatever, yeah, people do care.

所以我们花了整整一年半的时间迁移到原生代码。

That's why we're we're spending a year and a half moving to native code.

在云端做推理，或者处理海量数据的时候，情况就不一样了。

Inference in in the cloud or on the up against data.

我的天啊。

I mean, oh my god.

比如金融高频交易这类应用，性能才是重中之重。

You know, like financial, fast trading, whatever, it's all about perf.

对吧？

Right?

光速运行，拼命比对手快那么一丁点。

I mean, at the speed of light and, like, trying to trying to move your trade faster than the other guys.

确实有很多场景下性能是决定性的，但也有越来越多的地方，性能根本没那么重要——因为现在速度已经快到即使慢十倍，你也根本察觉不出来。

I mean, so so there are lots of places where perf is king, but there's increasingly also places where where perf doesn't really matter because, you know, it's so fast anyway that if it even if it's 10 times slower, you still can't detect the difference.

所以在这些地方，优化就没什么意义了。

And so it's just not worth optimizing there anymore.