EP75 TypeScript 7：十倍性能的升级之外，为什么选 Go？

[00:00] 大家好这里是 AsyncTalk我是 AsyncTalk 主播 Annatar今天想跟大家来聊一聊前段时间发布的一个 typescript 7我相信大家在去年的时候就已经收到这个比较爆炸性的新闻了就是 typescript 它去拿 go 来去做重写今年它终于把这个端上来了那 typescript 7它有非常巨大的一个性能提升它的性能提升达到 10 倍左右的样子

[00:21] 首先一点Vscode 它的 一个 TSC 的这个类型检查从 78 秒降低到了 7.5 秒这是一个非常巨大的提升尤其是像 VSCode这样一个超大的项目来说那其实我公司那边也有个项目它是一个大概 58 万行代码的一个量级那这个量级代码检查速度它是一个 TS 6 是 14 秒左右当我把它升到 TS7 的时候它只有大概3秒钟左右的一个检查

[00:48] 它效果是非常明显的虽然我们代码仓库没有达到十倍的这个效果但是它已经让人非常的惊艳了最主要的是这个升级过程是几乎无痛的如果你的产品比如说普通的一个 Web 开发的一个产品其实对你来说它是完完完全全无痛的基本上像我们代码写完之后我们有一些 lint有一些类型检查

[01:09] 那类型检查我们基本上是去调 TSC 的这个命令行去做的如果你也是这样一种普通的项目的情况你今天就可以完全直接无痛替换了因为对于这种 CLI 使用的场景来说基本上是没有任何变化它只是一个内部代码的重写它去拿 go 去重写用了一些多线程的一些技术来去加速整个检查的过程其实对我来说最重要的是关于编辑器的使用

[01:36] 但我知道大家现在基本上可能已经去拿 coding agent 来去做可能相当一部分人都已经不怎么看代码了但对于我这种稍微有些传统的人来说我还是有时候去拿这些编辑器来去做一些事情来去检查一些代码自己要手动微调一些代码的场景那在这种场景下TS7 它所带来的变化对我来说是最为重要的

[02:00] 我在工作的时候有一个项目是从前几年大概 200 万行代码的规模拓展到最近大概开始有一个 300 万行代码的一个级别了当你在维护一个如此量级的代码库的时候你会发现里面有很多各种各样的问题它都放大了像我之前有跟大家在 Oxlint 里边提到过的说一个编译速

[02:24] 一个速度的提升同样在这样一个巨大项目的情况之下你的代码编译器承担的任务是非常庞大的那你就像我那个项目我一天打开编辑器基本上编辑器里边的typescript language Protocol LSP基本一天是要 crash 个五六七八次的因为里边要么就是代码占用太高要么就是 CPU 太高当然

[02:45] 我没有细查过问题了但情况就是这样它就是会 crash 非常多的次数我相信是因为我们的代码量级有些过于庞大了当我们迁移到 TS7 的时候它带来的效果不仅仅是这个项目并不 crash 了而是当在进行一些 TS 类型提示的时候它会响应的更快这个快是随着你这个代码量级越大它越明显的

[03:09] 当然了300 万那个项目我并没有去做这个升级因为它的升级有点可怕但是对于 58 万行的那个项目这边有做升级那升级之后我自己体感效果是相当不错的应该是没有再 crash 过了它的代码的类型的提示速度我体感上也有一些提升但是我前面说的那种项目

[03:28] 都是一个非常标准的 Web 开发项目它都是一些 TSC 的命令行的工具如果你的项目就有用到 typescript 的 API那情况就会变得有点麻烦了比如说至少在 next 13.2 的一个版本之前它实际上 lint 是通过typescript 里边的 API 来去做的那它就需要去调用typescript 这个包里边的 API来去做一些事情

[03:54] 那这种情况它在于 TS7 还是没有原生支持的像一些大的开源库目前据我所知是已经支持了那比如说像 next 13.3其实可以通过 next config 里面的一个 experimental use typescript 的 CLI 的这样一个参数去开启那这样你的项目如果只有 nextjs它就可以升级到 7 了然后正常的去使用但是如果你有一些其它的项目

[04:20] 比如说我之前有推荐过的 hey API它去通过有一些typescript 里面 API 的调用对于这样的项目来说你可能就要去观察它们的仓库的这个兼容情况了据我了解到的消息typescript 的 7.1 版本它会去支持到 API 这样的东西所以如果你的项目有重度依赖 typescript API 的那你可能并不能这么丝滑的升级

[04:43] 你可能要再去看一看其它的方案或者说稍微再等一等接下来其实我想聊一个关于并不 typescript 的东西因为 typescript 7 这个版本在我看来它是一个没有什么好讨论的一个版本因为它就是很好 很快功能也很正常你如果只是 CLI 版本你就直接无脑升级就好这个在我看来是没什么有疑虑的地方

[05:05] 因为社区上以及包括一些公司都已经在用了那如果说你的项目有重度依赖 API 的那就再等等呗等到 7.1 版本去看看其实在之前typescript 7 Preview 的版本刚发的时候在外网是引起了相当大的舆论风波的目前来说在程序的一种重写的这种ZZ正确它是拿 rust 来去重写一切

[05:26] 像我们都知道的前段时间比较火的 Bun当然我们也上一期有聊了Bun 是拿 rust 来去重写的那效果看起来也还不错像更之前的一些 CLI 的系统工具里边有更多的拿 rust 来去写的项目比如说我自己比较喜欢用的 cat它用 bat 来去替换这样的 rust 工具但为什么 typescript 拿 go 来去重写呢有很多采访有很多各种各样的想法了但我觉得这里我想自己

[05:58] 来去尝试解读一下这个事情其实我自己有用 go我自己写 go 大约有个七八年的经验如果有关注我的一些项目可以发现除了前端项目基本上都是拿 go 来去实现的无论是 CLI 还是 Web Server还是说一些 Desktop 的工具我基本上是拿 go 来去写的那另一方面其实我也有试过 rust

[06:19] 我拿 rust 写过一些简单的 HTTP 工具一些 CLI 的项目代码量级应该不算高我估计大概几万行左右的样子对 我自己的观点其实是我个人更偏好于 go我和 typescript 它们的想法是一样的如果是我来去重写 typescript我相信我大概也会拿 go 来去重写其实我认为这是你个人的选择对我来说go 语言

[06:44] 它的平衡性是做的非常好的那首先一点是它的一个性能go 的性能绝对不差我要和互联网上可能没写过代码的程序员来 battle 一下go 的性能绝对不算差Go 的性能实际上它就是机器的那种基本的性能你如果只是拿像是 sum 1+ 2 2+ 3这种简单的项目来去做对比我并不能同意你可以去拿一些项目

[07:07] 一些场景来去看看Go 的性能绝对是不算差的毕竟它是一种静态语言静态语言的性能是不太可能差的它编译成机器码它又不需要像是 VM 这种东西那另一方面还是它的学习曲线像 go 语言它的设计是非常克制的c 的指针我要说确实非常的复杂有各种的骚操作小技巧在但是 go 它就克制了非常多你可以看像泛型这样一个

[07:32] 几乎广为人知的概念在 go 里边也是经过非常慎重的考虑它才去做的在 go 里边我印象非常深的就是它一个 error 的一个判定error 的这样一个处理因为像我们现在普通的语言基本上都是拿 try catch这样的方式来去做的它有没有好处呢有它很方便

[07:52] 它会一层一层向上抛但它有没有另外的问题它最大的问题就是 surprise有时候你并不知道哪里会抛错从上层抛出来一个错它可能下面 200 层的一个才触发当然如果你的同事说你的 Coding agent写代码骚一点的话它甚至可以让你的系统 crash但是并不知道真实的 crash 原因是什么这是一个非常痛苦的点

[08:17] 我相信只要你维护过一个稍微大一点的系统你都会理解到 try catch它并不是一个很好的设计但是 go 里边它对于这个的做法非常的坚持它要求每一个函数都需要去显示的去返回 error这样当你在写代码的时候你就知道这个地方它可能会有 error你要么处理一下或者说你非常明确的表示说我不处理

[08:39] 那另一点我认为 go 它对于这个平衡性做的很好的一点是在于几乎所有语言都有的一个三目运算符go 里面是没有的你去学 go 的语法你会发现它是没有的它是一个非常简单你只能拿 if else 来去做这件事情我认为这是 go 里边非常勇敢的一个设计之一

[08:56] 我相信你如果写过一段时间的代码你就知道 AI 它其实很喜欢写这种三目运算符但三目运算符有个非常大的问题就在于它的可读性非常差它每多一层的三目运算符它的可读性就急速下降我可以很确定的说地球上没有人能够理解四层的三目运算符因为这个三目运算符它一个 if else

[09:20] 它如果能叠 4 层它的这个可能性就已经变得 2 的 4 次方 是吧它就已经变成 16 种可能性了你在短短的这么几行代码里面你有 16 种可能性我不知道这个人脑的构造要到何等的层次才可以说轻易的理解这个事情在我看来三目运算符它就是一个很大的糟粕go 里边它就明确的说它们不支持

[09:44] 像是泛型的话我当然是蛮喜欢泛型这个设计因为泛型它可以有一定高程度的一个抽象但我相信大家如果写过泛型你也会同意一件事情就是泛型它把很多问题变得很复杂当然写的好的人是可以拿泛型写出来花的写出来一个短短的几行代码写出来一些非常高深的一些操作

[10:06] 一些技巧但我也要说大多数人并不是那种神仙大多数人是不会做那种TS 的这种类型体操的同样我其实也不认为我们应该学习这种类型体操因为它不是一个正常人的思维同样我也不认为它是一个 AI 应该理解的东西一段逻辑它就应该简简单单可读性第一的前提下

[10:29] 我们才可以谈其它的东西那我们回到另一个问题就是 rust rust 它的性能好不好呢它非常的好它甚至能够自己控制 GC因为 GC 它不可避免的是会影响性能的而且它也有一定的不可预测的性质在那里rust 它就可以让你控制 GC那这样你就可以去写一些极端的高性能的场景

[10:52] 一些计算可以不用被 GC 打断它的好处就是极端的性能同样的话它的坏处就是就是你需要自己去手动控制rust 这个语言我用下来的给我的感觉就是我每次都要重新学习一下这个语言它的语言体系太复杂了如果说你到现在你很喜欢 rust我其实建议你去搜索一下pin unpin unbox unwrapper 这些概念

[11:15] 我觉得对我来说是比较复杂的但是它最复杂还是一个生命周期因为像我前文说的你可以自己去控制 GC 的时候当然它的这个 GC 控制也并不像我们 c 或者 c ++你自己去写 malloc 或者 free 这样方法而是它是通过生命周期的方法来去做的这样一个事我只能说它有点太难了那如果说你到今天你还认为rust 它是一门很好的语言

[11:39] 你会更倾向于拿 rust 来去重写 typescript有没有这种可能呢我认为是有的因为毕竟 typescript 其实其实和 bun 是比较像的因为它有（相对）非常充足的测试用例它也有非常大的使用量所以我认为如果拿 AI 来去拿 rust 来去重写 typescript应该是一个非常有可能的项目而且它很有可能在短短

[12:01] 认为两周之内就做完这件事情但我想到的可能是关于可读性关于可拓展性关于将来的维护那我认为 go 的它可能是一门更加适合人类去维护的一个语言Rust 是吗它当然也是但是我认为它对于这种平衡的把握也许它更加偏向于性能一点如果到这里你还是十分不同意我的说法

[12:28] 我当然欢迎你在评论区来谈谈你的看法但我更建议的做法就是我们可以尝试拿 rust 来去写一个大概 1万量级的一个项目我相信当很多人真的去拿 rust来去写过 1万行以上代码来去尝试 rust 的拥趸应该就会冷静一些当然你写完之后也欢迎在评论区来去聊一聊你的看法聊一聊对于 rust 这个语言是不是该去重写万物

[12:54] 是不是说 typescript 的团队的决策是一个错误的行为OK那我们今天的节目就到这里我们下期节目再见拜拜