Microsoft TypeScript 开发人员解释为什么选择 Go 而不是 Rust、C#

360影视 欧美动漫 2025-04-02 14:01 2

摘要:Microsoft 的 Anders Hejlsberg 解释说,选择 Go 作为其 TypeScript 编译器端口,是因为其原生代码、垃圾回收以及对内存和数据布局的出色控制。

Microsoft 的 Anders Hejlsberg 解释说,选择 Go 作为其 TypeScript 编译器端口,是因为其原生代码、垃圾回收以及对内存和数据布局的出色控制。

前不久,Microsoft 宣布 TypeScript 的编译器将被移植到一种新的编程语言 — Go 上。然后一轮讨论在网上拉开了序幕......每个人都对他们高风险的决定感兴趣,一些评论者忍不住对开发团队选择的新编程语言进行了二次猜测。

为什么 Go?为什么不使用 Microsoft 自己的 C# 或当时的热门语言 Rust?

TypeScript 的开发人员很快就发现自己参加了 GitHub、Reddit、YouTube 和 Hacker News 上举行的一种临时座谈会,解释了他们的决策过程以及 Go 的所有明显和不可否认的优势。在所有来回讨论中,他们一起对几种不同编程语言的各种优点进行了令人惊讶的教育探索。

在此过程中,他们甚至详细解释了为什么他们决定将 TypeScript 的编译器移植到 Go...

TypeScript 的当前编译器是用 TypeScript 语言编写的。但在 Reddit 上,当一位评论者建议 C#“几乎拥有你所需要的一切”来重写 TypeScript 代码时,出现了一个有趣但无可辩驳的反击。

“嗯,你可以告诉创建 Typescript 和 C# 的人,但他不同意你的看法。”

事实上,这是 Anders Hejlsberg 在宣布此举的视频中谈到的一个问题。“你们中的一些人可能会问,'为什么不是我最喜欢的语言呢?为什么不是 C#?为什么不是 Rust?为什么不是 C++?”

Hejlsberg 回答说,Go 是“我们能接触到的最低级语言,它为所有平台提供了完整的、优化的原生代码支持,对数据布局有很好的控制,能够拥有循环数据结构等等。它通过垃圾回收器为您提供自动内存管理,并很好地访问并发。

Hejlsberg 还在密歇根州安娜堡举行的每月 TypeScript 聚会的 YouTube 频道的特别 Zoom 采访中回答了这个问题。Hejlsberg 将 C# 描述为“字节码优先,如果你愿意的话”。此外,在性能方面,C# 的提前编译并非在所有平台上都可用,而且“它没有十年或更长时间的强化......”

“然后我认为 Go 在数据结构布局和内联结构等方面更具表现力。”

但是,Microsoft 编译器的原始 TypeScript 代码库也有一些独特之处。虽然 C# 是一种面向对象的语言,但 TypeScript 使用“很少的类”,Hejlsberg 在 Zoom 采访中说。“事实上,核心编译器根本不使用类......”

“Go 是函数和数据结构,而 C# 则主要面向面向对象编程 (OOP)。我们不得不切换到 OOP 范式才能迁移到 C#......这种过渡中的摩擦比向 Go 的过渡中的摩擦要多。”

在 Reddit 上,一位评论者甚至将 Microsoft 的所有官方答案收集到一个方便的图表中 ——Go 有一个经过充分测试的原生优先选项,支持他们想要的所有平台(与 C# 不同)。

在一条获得 1,305 个赞的 Reddit 评论中,TypeScript 开发主管 Ryan Cavanaugh 承认好奇心激增。“我们肯定知道,在选择 Go 时,会有人质疑我们为什么不选择 Rust(或其他)。”

“这是个好问题,因为 Rust 是一门优秀的语言,除了其他限制之外,它是编写新的原生代码时的首选。”

Cavanaugh 写道,Rust 和 Go 都擅长表示数据,拥有“出色的”代码生成工具,并且在单核系统上表现良好。“在我们看来,Rust 在其设计目标上取得了巨大的成功,但'从这个特定的 JavaScript 代码库可以直接移植到 Rust'非常合理地不是它的设计目标之一。”

“它也不是 Go 的,但就我们而言,考虑到我们目前编写代码的方式,它确实非常擅长它。”

Cavanaugh 分享了一些内幕信息:他们确实尝试了 Rust。但他们希望新代码库 “在算法上与当前代码库相似”,而 Rust 并不适合。“我们尝试了大量的方法,以达到一种在 Rust 中易于处理的端口方法的表示,但所有这些方法要么有不可接受的权衡(性能、人体工程学等),要么沦为'编写你自己的垃圾回收'风格的策略。其中一些接近,但经常需要进入大量不安全的代码......”

Cavanaugh 在 GitHub 上的项目常见问题解答中解释说,他们还尝试了其他语言,甚至“对现有的原生 TypeScript 解析器(如 swcoxcesbuild)使用的方法进行了深入调查”。卡瓦诺说,他们得出了两个重要的结论。

“许多语言都适合从头开始重写的情况。”“Go 在考虑特定于这种情况的多个标准时做得最好...”

在 Reddit 上,有人指出 Go 提供了“对内存的更细粒度的控制”——Ryan Cavanaugh 跳出来同意 Go 对内存分配“有很好的控制”。使用池分配器绕过 Go 的内置分配器“非常简单(并且很容易在不改变下游用法的情况下进行试验)”。

相比之下,Cavanaugh 补充说,“Rust 可以更好地控制'何时释放内存',但在类型检查器中,在完成整个批处理之前,你几乎无法释放任何东西,因此在这种情况下,你不会真正获得任何超过 GC 模型的东西。”

在常见问题解答中 Cavanaugh 还称赞Go 对内存布局的控制——它做到了这一切,“不需要整个代码库持续关注内存管理”。

因此,当谈到 Rust 时,Cavanaugh 在 Reddit 上解释说,他们将面临两个选择:

“用 Rust 从头开始做一个完整的重写,这可能需要数年时间,并产生一个不兼容的 TypeScript 版本,没有人能真正使用......”“只需在 Go 中做一个移植,在一年左右的时间里得到一些可用的东西,并且拥有在语义方面非常兼容,在性能方面也非常有竞争力的东西。”

在 Hacker News 的评论中,Cavanaugh 提醒读者,2022 年 SWC(Speedy Web Compiler)项目也选择了 Go 作为 TypeScript 类型检查器 tsc 的一个端口。(项目创始人 DongYoon Kang 指出,tsc“使用了很多共享可变性,很多部分都依赖于垃圾回收。尽管我是 Rust 的倡导者和信徒,但感觉它并不适合这里的工作。)

“kdy1 在他的初始 Go 端口中绝对找到了正确的通用方法,”Cavanaugh 在 Reddit 上的一条评论中说。

在 Zoom 采访中,Anders 承认 TypeScript 的类型系统比 Go 中可用的系统“丰富得多”。但另一方面,Go“实际上确实对位调整和将标志打包到 ints 中提供了很好的支持。事实上,它对所有各种数据类型的支持都比 JavaScript 好得多......你可以有 bytesshortints 和 ints 和 64 位 int, 以及你拥有的任何东西,包括有符号和无符号......在 JavaScript 中,一切都是一个浮点数。时期。他笑了。“我的意思是,你想代表真还是假?是的,那是给你的 8 个字节......”

Hejlsberg 说,不仅仅是利用 Go 中的所有位。“我们还可以将它们布局为结构体 — 你知道的,内联的,以数组的形式。它表明了!我们的内存消耗大约是旧编译器的一半......如果你能压缩你的数据结构,你就会走得更快。”

在这里,Hejlsberg 停下来反思这是一次多么漫长而奇怪的旅程,他说他经常笑着说,如果人们告诉他,“Anders,你将用 JavaScript 编写编译器十年”......

“你疯了。”

“JavaScript 从来没有真正打算成为计算密集型系统级工作负载的语言...”他说。“虽然 Go 的初衷......Go 是一个系统级工具,而我们是一个系统级程序。”

Hejlsberg 还发现自己参与了 GitHub 上关于“Why Go”的讨论 ,他强调使用 Go 的决定“强调了我们对实用工程选择的承诺”。

“在 Microsoft,我们利用多种编程语言,包括 C#、Go、Java、Rust、C++、TypeScript 等,每种语言都根据技术适用性和团队工作效率精心选择。”

作为 C# 的原始设计者,Hejlsberg 一定很自豪地指出,“到目前为止,C# 仍然恰好是内部最流行的语言。“他甚至强调,Microsoft 仍然投资于 C# 和 .NET,”因为它们具有无与伦比的生产力、强大的生态系统和强大的可扩展性”。

他说,他们甚至尝试过 TypeScript 编译器的 C# 原型,但“Go 成为最佳选择,它为树遍历提供了出色的人体工程学设计,易于内存分配,并且代码结构与现有编译器紧密对应,从而更容易维护和兼容。

Hejlsberg 补充道,从头开始将是一个完全不同的问题,但“这不是一个绿地——它是现有代码库的移植,需要 100 个人年的投资......”Go 的代码库是 “所有函数和数据结构” — 没有类 — 结果证明 Go “在映射中更加一对一...... Go 看起来就像我们现有的代码库,因此移植大大简化了。”

Hejlsberg 利用这一时刻指出,“在 Microsoft,我们庆祝编程语言多样性所带来的力量。”

他的评论也以一些历史视角结束。“让我们面对现实。Microsoft 使用 Go 为 TypeScript 编写编译器在过去几年是不可能的,也是不可能的。但是,“在过去的几十年里,我们看到了 Microsoft 对开源软件的坚定和持续承诺,将开发人员的生产力和社区协作放在首位。”Hejlsberg 认为,今天,Microsoft 寻求“为开发人员提供可用的最佳工具,不受内部政治或狭隘限制的阻碍。

“这种为每项特定工作选择正确工具的自由最终使整个开发人员社区受益,推动创新、效率和改善结果。而且你不能用 10 倍的结果争论!”

来源:AI中国一点号

相关推荐