diff --git a/public/subtitles/ep75.srt b/public/subtitles/ep75.srt new file mode 100644 index 0000000..09765dd --- /dev/null +++ b/public/subtitles/ep75.srt @@ -0,0 +1,1608 @@ +1 +00:00:00,000 --> 00:00:00,300 +大家好 + +2 +00:00:00,366 --> 00:00:01,633 +这里是 AsyncTalk + +3 +00:00:01,666 --> 00:00:03,466 +我是 AsyncTalk 主播 Annatar + +4 +00:00:03,533 --> 00:00:05,233 +今天想跟大家来聊一聊 + +5 +00:00:05,233 --> 00:00:07,133 +前段时间发布的一个 typescript 7 + +6 +00:00:07,166 --> 00:00:08,700 +我相信大家在去年的时候就已经 + +7 +00:00:08,700 --> 00:00:10,966 +收到这个比较爆炸性的新闻了 + +8 +00:00:11,000 --> 00:00:13,433 +就是 typescript 它去拿 go 来去做重写 + +9 +00:00:13,466 --> 00:00:15,733 +今年它终于把这个端上来了 + +10 +00:00:15,800 --> 00:00:16,633 +那 typescript 7 + +11 +00:00:16,633 --> 00:00:19,200 +它有非常巨大的一个性能提升 + +12 +00:00:19,266 --> 00:00:21,700 +它的性能提升达到 10 倍左右的样子 + +13 +00:00:21,733 --> 00:00:22,166 +首先一点 + +14 +00:00:22,233 --> 00:00:25,333 +Vscode 它的 一个 TSC 的这个类型检查 + +15 +00:00:25,366 --> 00:00:27,666 +从 78 秒降低到了 7.5 秒 + +16 +00:00:27,766 --> 00:00:29,433 +这是一个非常巨大的提升 + +17 +00:00:29,466 --> 00:00:30,766 +尤其是像 VSCode + +18 +00:00:30,766 --> 00:00:32,433 +这样一个超大的项目来说 + +19 +00:00:32,466 --> 00:00:35,033 +那其实我公司那边也有个项目 + +20 +00:00:35,033 --> 00:00:38,466 +它是一个大概 58 万行代码的一个量级 + +21 +00:00:38,500 --> 00:00:40,466 +那这个量级代码检查速度 + +22 +00:00:40,633 --> 00:00:43,533 +它是一个 TS 6 是 14 秒左右 + +23 +00:00:43,533 --> 00:00:45,800 +当我把它升到 TS7 的时候 + +24 +00:00:45,866 --> 00:00:48,633 +它只有大概3秒钟左右的一个检查 + +25 +00:00:48,666 --> 00:00:50,333 +它效果是非常明显的 + +26 +00:00:50,366 --> 00:00:51,200 +虽然我们代码仓库 + +27 +00:00:51,200 --> 00:00:52,733 +没有达到十倍的这个效果 + +28 +00:00:52,766 --> 00:00:56,966 +但是它已经让人非常的惊艳了 + +29 +00:00:57,000 --> 00:00:58,033 +最主要的是这个 + +30 +00:00:58,033 --> 00:01:00,666 +升级过程是几乎无痛的 + +31 +00:01:00,733 --> 00:01:02,066 +如果你的产品比如说 + +32 +00:01:02,066 --> 00:01:03,633 +普通的一个 Web 开发的一个产品 + +33 +00:01:03,700 --> 00:01:06,166 +其实对你来说它是完完完全全无痛的 + +34 +00:01:06,200 --> 00:01:07,666 +基本上像我们代码写完之后 + +35 +00:01:07,733 --> 00:01:08,733 +我们有一些 lint + +36 +00:01:08,766 --> 00:01:09,800 +有一些类型检查 + +37 +00:01:09,866 --> 00:01:11,366 +那类型检查我们基本上 + +38 +00:01:11,366 --> 00:01:14,100 +是去调 TSC 的这个命令行去做的 + +39 +00:01:14,133 --> 00:01:17,333 +如果你也是这样一种普通的项目的情况 + +40 +00:01:17,366 --> 00:01:20,000 +你今天就可以完全直接无痛替换了 + +41 +00:01:20,066 --> 00:01:22,266 +因为对于这种 CLI 使用的场景来说 + +42 +00:01:22,300 --> 00:01:24,200 +基本上是没有任何变化 + +43 +00:01:24,266 --> 00:01:27,133 +它只是一个内部代码的重写 + +44 +00:01:27,166 --> 00:01:28,433 +它去拿 go 去重写 + +45 +00:01:28,500 --> 00:01:30,266 +用了一些多线程的一些技术 + +46 +00:01:30,266 --> 00:01:33,200 +来去加速整个检查的过程 + +47 +00:01:33,266 --> 00:01:34,466 +其实对我来说最重要的是 + +48 +00:01:34,466 --> 00:01:36,433 +关于编辑器的使用 + +49 +00:01:36,466 --> 00:01:37,733 +但我知道大家现在基本上 + +50 +00:01:37,733 --> 00:01:40,533 +可能已经去拿 coding agent 来去做 + +51 +00:01:40,566 --> 00:01:41,900 +可能相当一部分人 + +52 +00:01:41,900 --> 00:01:44,400 +都已经不怎么看代码了 + +53 +00:01:44,466 --> 00:01:46,833 +但对于我这种稍微有些传统的人来说 + +54 +00:01:46,866 --> 00:01:48,966 +我还是有时候去拿这些编辑器 + +55 +00:01:48,966 --> 00:01:50,500 +来去做一些事情 + +56 +00:01:50,533 --> 00:01:51,733 +来去检查一些代码 + +57 +00:01:51,766 --> 00:01:54,200 +自己要手动微调一些代码的场景 + +58 +00:01:54,266 --> 00:01:55,866 +那在这种场景下 + +59 +00:01:55,900 --> 00:01:58,233 +TS7 它所带来的变化 + +60 +00:01:58,233 --> 00:02:00,200 +对我来说是最为重要的 + +61 +00:02:00,266 --> 00:02:01,333 +我在工作的时候 + +62 +00:02:01,366 --> 00:02:03,733 +有一个项目是从前几年 + +63 +00:02:03,733 --> 00:02:06,300 +大概 200 万行代码的规模 + +64 +00:02:06,300 --> 00:02:08,133 +拓展到最近大概开始 + +65 +00:02:08,133 --> 00:02:10,466 +有一个 300 万行代码的一个级别了 + +66 +00:02:10,533 --> 00:02:11,700 +当你在维护 + +67 +00:02:11,700 --> 00:02:16,100 +一个如此量级的代码库的时候 + +68 +00:02:16,133 --> 00:02:18,500 +你会发现里面有很多各种各样的问题 + +69 +00:02:18,533 --> 00:02:19,333 +它都放大了 + +70 +00:02:19,366 --> 00:02:20,533 +像我之前有跟大家 + +71 +00:02:20,533 --> 00:02:22,466 +在 Oxlint 里边提到过的 + +72 +00:02:22,466 --> 00:02:24,100 +说一个编译速 + +73 +00:02:24,133 --> 00:02:25,400 +一个速度的提升 + +74 +00:02:25,466 --> 00:02:28,100 +同样在这样一个巨大项目的情况之下 + +75 +00:02:28,133 --> 00:02:30,433 +你的代码编译器承担的任务 + +76 +00:02:30,433 --> 00:02:31,733 +是非常庞大的 + +77 +00:02:31,800 --> 00:02:33,300 +那你就像我那个项目 + +78 +00:02:33,333 --> 00:02:34,966 +我一天打开编辑器 + +79 +00:02:35,033 --> 00:02:36,666 +基本上编辑器里边的 + +80 +00:02:36,666 --> 00:02:38,833 + typescript language Protocol LSP + +81 +00:02:38,833 --> 00:02:42,000 +基本一天是要 crash 个五六七八次的 + +82 +00:02:42,033 --> 00:02:44,233 +因为里边要么就是代码占用太高 + +83 +00:02:44,266 --> 00:02:45,500 +要么就是 CPU 太高 + +84 +00:02:45,533 --> 00:02:45,633 +当然 + +85 +00:02:45,700 --> 00:02:46,766 +我没有细查过问题了 + +86 +00:02:46,833 --> 00:02:48,333 +但情况就是这样 + +87 +00:02:48,400 --> 00:02:50,600 +它就是会 crash 非常多的次数 + +88 +00:02:50,633 --> 00:02:52,266 +我相信是因为我们的代码量级 + +89 +00:02:52,266 --> 00:02:54,733 +有些过于庞大了 + +90 +00:02:54,800 --> 00:02:56,966 +当我们迁移到 TS7 的时候 + +91 +00:02:57,000 --> 00:02:58,366 +它带来的效果不仅仅是 + +92 +00:02:58,366 --> 00:03:00,200 +这个项目并不 crash 了 + +93 +00:03:00,233 --> 00:03:03,900 +而是当在进行一些 TS 类型提示的时候 + +94 +00:03:03,900 --> 00:03:05,366 +它会响应的更快 + +95 +00:03:05,400 --> 00:03:08,033 +这个快是随着你这个代码量级越大 + +96 +00:03:08,100 --> 00:03:09,000 +它越明显的 + +97 +00:03:09,066 --> 00:03:09,466 +当然了 + +98 +00:03:09,500 --> 00:03:10,500 +300 万那个项目 + +99 +00:03:10,533 --> 00:03:12,333 +我并没有去做这个升级 + +100 +00:03:12,366 --> 00:03:14,233 +因为它的升级有点可怕 + +101 +00:03:14,300 --> 00:03:16,400 +但是对于 58 万行的那个项目 + +102 +00:03:16,466 --> 00:03:17,533 +这边有做升级 + +103 +00:03:17,566 --> 00:03:18,533 +那升级之后 + +104 +00:03:18,566 --> 00:03:20,566 +我自己体感效果是相当不错的 + +105 +00:03:20,566 --> 00:03:22,266 +应该是没有再 crash 过了 + +106 +00:03:22,300 --> 00:03:24,633 +它的代码的类型的提示速度 + +107 +00:03:24,633 --> 00:03:26,800 +我体感上也有一些提升 + +108 +00:03:26,866 --> 00:03:28,800 +但是我前面说的那种项目 + +109 +00:03:28,800 --> 00:03:31,133 +都是一个非常标准的 Web 开发项目 + +110 +00:03:31,200 --> 00:03:34,066 +它都是一些 TSC 的命令行的工具 + +111 +00:03:34,100 --> 00:03:34,933 +如果你的项目就有 + +112 +00:03:34,933 --> 00:03:37,333 +用到 typescript 的 API + +113 +00:03:37,333 --> 00:03:39,433 +那情况就会变得有点麻烦了 + +114 +00:03:39,500 --> 00:03:40,166 +比如说 + +115 +00:03:40,166 --> 00:03:44,966 +至少在 next 13.2 的一个版本之前 + +116 +00:03:45,000 --> 00:03:46,366 +它实际上 lint 是通过 + +117 +00:03:46,366 --> 00:03:49,033 +typescript 里边的 API 来去做的 + +118 +00:03:49,100 --> 00:03:50,833 +那它就需要去调用 + +119 +00:03:50,833 --> 00:03:52,733 +typescript 这个包里边的 API + +120 +00:03:52,733 --> 00:03:54,133 +来去做一些事情 + +121 +00:03:54,166 --> 00:03:54,933 +那这种情况 + +122 +00:03:54,966 --> 00:03:57,800 +它在于 TS7 还是没有原生支持的 + +123 +00:03:57,800 --> 00:03:59,766 +像一些大的开源库 + +124 +00:03:59,933 --> 00:04:03,200 +目前据我所知是已经支持了 + +125 +00:04:03,233 --> 00:04:05,166 +那比如说像 next 13.3 + +126 +00:04:05,166 --> 00:04:06,500 +其实可以通过 next config 里面的 + +127 +00:04:06,500 --> 00:04:10,066 +一个 experimental use typescript 的 CLI 的 + +128 +00:04:10,066 --> 00:04:11,833 +这样一个参数去开启 + +129 +00:04:11,866 --> 00:04:14,133 +那这样你的项目如果只有 nextjs + +130 +00:04:14,200 --> 00:04:16,433 +它就可以升级到 7 了 + +131 +00:04:16,466 --> 00:04:18,233 +然后正常的去使用 + +132 +00:04:18,266 --> 00:04:20,566 +但是如果你有一些其它的项目 + +133 +00:04:20,633 --> 00:04:23,266 +比如说我之前有推荐过的 hey API + +134 +00:04:23,300 --> 00:04:25,666 +它去通过有一些 + +135 +00:04:25,666 --> 00:04:27,866 +typescript 里面 API 的调用 + +136 +00:04:27,900 --> 00:04:29,000 +对于这样的项目来说 + +137 +00:04:29,066 --> 00:04:30,266 +你可能就要去观察 + +138 +00:04:30,266 --> 00:04:32,566 +它们的仓库的这个兼容情况了 + +139 +00:04:32,633 --> 00:04:33,633 +据我了解到的消息 + +140 +00:04:33,666 --> 00:04:35,133 +typescript 的 7.1 版本 + +141 +00:04:35,200 --> 00:04:38,066 +它会去支持到 API 这样的东西 + +142 +00:04:38,100 --> 00:04:39,033 +所以如果你的项目 + +143 +00:04:39,033 --> 00:04:40,900 +有重度依赖 typescript API 的 + +144 +00:04:40,966 --> 00:04:43,000 +那你可能并不能这么丝滑的升级 + +145 +00:04:43,033 --> 00:04:44,933 +你可能要再去看一看其它的方案 + +146 +00:04:45,000 --> 00:04:46,800 +或者说稍微再等一等 + +147 +00:04:46,833 --> 00:04:48,166 +接下来其实我想聊一个 + +148 +00:04:48,166 --> 00:04:51,133 +关于并不 typescript 的东西 + +149 +00:04:51,200 --> 00:04:52,666 +因为 typescript 7 这个版本 + +150 +00:04:52,666 --> 00:04:53,866 +在我看来它是一个 + +151 +00:04:53,866 --> 00:04:55,966 +没有什么好讨论的一个版本 + +152 +00:04:56,000 --> 00:04:58,633 +因为它就是很好 很快 + +153 +00:04:58,700 --> 00:04:59,866 +功能也很正常 + +154 +00:04:59,900 --> 00:05:01,300 +你如果只是 CLI 版本 + +155 +00:05:01,333 --> 00:05:02,800 +你就直接无脑升级就好 + +156 +00:05:02,833 --> 00:05:04,933 +这个在我看来是没什么有疑虑的地方 + +157 +00:05:05,000 --> 00:05:06,600 +因为社区上以及包括一些公司 + +158 +00:05:06,600 --> 00:05:08,033 +都已经在用了 + +159 +00:05:08,100 --> 00:05:10,700 +那如果说你的项目有重度依赖 API 的 + +160 +00:05:10,733 --> 00:05:11,900 +那就再等等呗 + +161 +00:05:11,933 --> 00:05:13,566 +等到 7.1 版本去看看 + +162 +00:05:13,600 --> 00:05:14,400 +其实在之前 + +163 +00:05:14,400 --> 00:05:16,000 +typescript 7 Preview 的版本 + +164 +00:05:16,000 --> 00:05:17,200 +刚发的时候 + +165 +00:05:17,233 --> 00:05:20,333 +在外网是引起了相当大的舆论风波的 + +166 +00:05:20,400 --> 00:05:20,866 +目前来说 + +167 +00:05:20,933 --> 00:05:23,833 +在程序的一种重写的这种ZZ正确 + +168 +00:05:23,900 --> 00:05:26,366 +它是拿 rust 来去重写一切 + +169 +00:05:26,400 --> 00:05:29,966 +像我们都知道的前段时间比较火的 Bun + +170 +00:05:30,000 --> 00:05:32,000 +当然我们也上一期有聊了 + +171 +00:05:32,033 --> 00:05:34,066 +Bun 是拿 rust 来去重写的 + +172 +00:05:34,133 --> 00:05:36,100 +那效果看起来也还不错 + +173 +00:05:36,133 --> 00:05:39,100 +像更之前的一些 CLI 的系统工具里边 + +174 +00:05:39,100 --> 00:05:43,133 +有更多的拿 rust 来去写的项目 + +175 +00:05:43,166 --> 00:05:45,333 +比如说我自己比较喜欢用的 cat + +176 +00:05:45,366 --> 00:05:48,933 +它用 bat 来去替换这样的 rust 工具 + +177 +00:05:48,966 --> 00:05:53,666 +但为什么 typescript 拿 go 来去重写呢 + +178 +00:05:53,733 --> 00:05:54,600 +有很多采访 + +179 +00:05:54,633 --> 00:05:56,066 +有很多各种各样的想法了 + +180 +00:05:56,133 --> 00:05:58,066 +但我觉得这里我想自己 + +181 +00:05:58,066 --> 00:06:00,133 +来去尝试解读一下这个事情 + +182 +00:06:00,166 --> 00:06:01,933 +其实我自己有用 go + +183 +00:06:01,966 --> 00:06:04,733 +我自己写 go 大约有个七八年的经验 + +184 +00:06:04,733 --> 00:06:06,400 +如果有关注我的一些项目 + +185 +00:06:06,466 --> 00:06:06,933 +可以发现 + +186 +00:06:06,966 --> 00:06:08,600 +除了前端项目 + +187 +00:06:08,666 --> 00:06:10,133 +基本上都是拿 go 来去实现的 + +188 +00:06:10,166 --> 00:06:13,233 +无论是 CLI 还是 Web Server + +189 +00:06:13,300 --> 00:06:15,200 +还是说一些 Desktop 的工具 + +190 +00:06:15,266 --> 00:06:17,033 +我基本上是拿 go 来去写的 + +191 +00:06:17,066 --> 00:06:17,900 +那另一方面 + +192 +00:06:17,933 --> 00:06:19,200 +其实我也有试过 rust + +193 +00:06:19,266 --> 00:06:21,966 +我拿 rust 写过一些简单的 HTTP 工具 + +194 +00:06:22,000 --> 00:06:23,366 +一些 CLI 的项目 + +195 +00:06:23,400 --> 00:06:24,500 +代码量级应该不算高 + +196 +00:06:24,566 --> 00:06:26,933 +我估计大概几万行左右的样子 + +197 +00:06:26,966 --> 00:06:28,433 +对 我自己的观点 + +198 +00:06:28,500 --> 00:06:30,733 +其实是我个人更偏好于 go + +199 +00:06:30,766 --> 00:06:33,966 +我和 typescript 它们的想法是一样的 + +200 +00:06:34,000 --> 00:06:36,500 +如果是我来去重写 typescript + +201 +00:06:36,566 --> 00:06:40,066 +我相信我大概也会拿 go 来去重写 + +202 +00:06:40,100 --> 00:06:42,833 +其实我认为这是你个人的选择 + +203 +00:06:42,866 --> 00:06:43,500 +对我来说 + +204 +00:06:43,566 --> 00:06:43,966 +go 语言 + +205 +00:06:44,000 --> 00:06:45,633 +它的平衡性是做的非常好的 + +206 +00:06:45,666 --> 00:06:47,866 +那首先一点是它的一个性能 + +207 +00:06:47,900 --> 00:06:49,266 +go 的性能绝对不差 + +208 +00:06:49,300 --> 00:06:50,900 +我要和互联网上 + +209 +00:06:50,900 --> 00:06:53,300 +可能没写过代码的程序员来 battle 一下 + +210 +00:06:53,366 --> 00:06:54,833 +go 的性能绝对不算差 + +211 +00:06:54,866 --> 00:06:56,466 +Go 的性能实际上 + +212 +00:06:56,466 --> 00:07:00,133 +它就是机器的那种基本的性能 + +213 +00:07:00,200 --> 00:07:03,066 +你如果只是拿像是 sum 1+ 2 2+ 3 + +214 +00:07:03,066 --> 00:07:05,366 + 这种简单的项目来去做对比 + +215 +00:07:05,400 --> 00:07:06,233 +我并不能同意 + +216 +00:07:06,266 --> 00:07:07,433 +你可以去拿一些项目 + +217 +00:07:07,466 --> 00:07:08,566 +一些场景来去看看 + +218 +00:07:08,633 --> 00:07:10,233 +Go 的性能绝对是不算差的 + +219 +00:07:10,233 --> 00:07:11,666 +毕竟它是一种静态语言 + +220 +00:07:11,833 --> 00:07:14,066 +静态语言的性能是不太可能差的 + +221 +00:07:14,133 --> 00:07:15,133 +它编译成机器码 + +222 +00:07:15,166 --> 00:07:17,833 +它又不需要像是 VM 这种东西 + +223 +00:07:17,833 --> 00:07:19,400 +那另一方面还是它的学习曲线 + +224 +00:07:19,400 --> 00:07:22,466 +像 go 语言它的设计是非常克制的 + +225 +00:07:22,500 --> 00:07:25,100 + c 的指针我要说确实非常的复杂 + +226 +00:07:25,166 --> 00:07:27,400 +有各种的骚操作小技巧在 + +227 +00:07:27,433 --> 00:07:29,466 +但是 go 它就克制了非常多 + +228 +00:07:29,533 --> 00:07:32,133 +你可以看像泛型这样一个 + +229 +00:07:32,133 --> 00:07:35,566 +几乎广为人知的概念 + +230 +00:07:35,600 --> 00:07:36,800 +在 go 里边也是经过 + +231 +00:07:36,800 --> 00:07:39,466 +非常慎重的考虑它才去做的 + +232 +00:07:39,533 --> 00:07:40,866 +在 go 里边我印象非常深的 + +233 +00:07:40,866 --> 00:07:43,733 +就是它一个 error 的一个判定 + +234 +00:07:43,733 --> 00:07:45,566 + error 的这样一个处理 + +235 +00:07:45,600 --> 00:07:47,300 +因为像我们现在普通的语言 + +236 +00:07:47,300 --> 00:07:49,133 +基本上都是拿 try catch + +237 +00:07:49,133 --> 00:07:50,400 +这样的方式来去做的 + +238 +00:07:50,433 --> 00:07:51,133 +它有没有好处呢 + +239 +00:07:51,200 --> 00:07:51,466 +有 + +240 +00:07:51,533 --> 00:07:52,833 +它很方便 + +241 +00:07:52,900 --> 00:07:54,300 +它会一层一层向上抛 + +242 +00:07:54,333 --> 00:07:55,633 +但它有没有另外的问题 + +243 +00:07:55,700 --> 00:07:57,700 +它最大的问题就是 surprise + +244 +00:07:57,700 --> 00:07:59,766 +有时候你并不知道哪里会抛错 + +245 +00:07:59,800 --> 00:08:01,166 +从上层抛出来一个错 + +246 +00:08:01,200 --> 00:08:04,466 +它可能下面 200 层的一个才触发 + +247 +00:08:04,466 --> 00:08:06,033 +当然如果你的同事 + +248 +00:08:06,033 --> 00:08:07,100 +说你的 Coding agent + +249 +00:08:07,100 --> 00:08:08,866 +写代码骚一点的话 + +250 +00:08:08,933 --> 00:08:11,700 +它甚至可以让你的系统 crash + +251 +00:08:11,733 --> 00:08:15,133 +但是并不知道真实的 crash 原因是什么 + +252 +00:08:15,166 --> 00:08:17,133 +这是一个非常痛苦的点 + +253 +00:08:17,166 --> 00:08:18,600 +我相信只要你维护过 + +254 +00:08:18,600 --> 00:08:20,000 +一个稍微大一点的系统 + +255 +00:08:20,066 --> 00:08:21,966 +你都会理解到 try catch + +256 +00:08:21,966 --> 00:08:23,900 +它并不是一个很好的设计 + +257 +00:08:23,933 --> 00:08:25,900 +但是 go 里边它对于 + +258 +00:08:25,900 --> 00:08:27,733 +这个的做法非常的坚持 + +259 +00:08:27,766 --> 00:08:29,166 +它要求每一个函数 + +260 +00:08:29,166 --> 00:08:31,933 +都需要去显示的去返回 error + +261 +00:08:31,966 --> 00:08:33,966 +这样当你在写代码的时候 + +262 +00:08:34,000 --> 00:08:36,000 +你就知道这个地方它可能会有 error + +263 +00:08:36,066 --> 00:08:37,166 +你要么处理一下 + +264 +00:08:37,200 --> 00:08:39,700 +或者说你非常明确的表示说我不处理 + +265 +00:08:39,766 --> 00:08:40,266 +那另一点 + +266 +00:08:40,333 --> 00:08:41,700 +我认为 go 它对于 + +267 +00:08:41,700 --> 00:08:43,200 +这个平衡性做的很好的一点 + +268 +00:08:43,200 --> 00:08:44,733 +是在于几乎所有语言 + +269 +00:08:44,733 --> 00:08:46,700 +都有的一个三目运算符 + +270 +00:08:46,766 --> 00:08:47,800 +go 里面是没有的 + +271 +00:08:47,833 --> 00:08:49,400 +你去学 go 的语法 + +272 +00:08:49,433 --> 00:08:50,333 +你会发现它是没有的 + +273 +00:08:50,400 --> 00:08:51,266 +它是一个非常简单 + +274 +00:08:51,333 --> 00:08:53,933 +你只能拿 if else 来去做这件事情 + +275 +00:08:53,966 --> 00:08:55,000 +我认为这是 go 里边 + +276 +00:08:55,000 --> 00:08:56,800 +非常勇敢的一个设计之一 + +277 +00:08:56,833 --> 00:08:59,333 +我相信你如果写过一段时间的代码 + +278 +00:08:59,400 --> 00:09:01,133 +你就知道 AI 它其实很喜欢 + +279 +00:09:01,133 --> 00:09:02,500 +写这种三目运算符 + +280 +00:09:02,566 --> 00:09:04,233 +但三目运算符有个非常大的问题 + +281 +00:09:04,233 --> 00:09:06,966 +就在于它的可读性非常差 + +282 +00:09:07,000 --> 00:09:09,066 +它每多一层的三目运算符 + +283 +00:09:09,133 --> 00:09:12,433 +它的可读性就急速下降 + +284 +00:09:12,500 --> 00:09:14,766 +我可以很确定的说 + +285 +00:09:14,800 --> 00:09:16,200 +地球上没有人能够理解 + +286 +00:09:16,200 --> 00:09:18,433 +四层的三目运算符 + +287 +00:09:18,500 --> 00:09:19,566 +因为这个三目运算符 + +288 +00:09:19,600 --> 00:09:20,766 +它一个 if else + +289 +00:09:20,800 --> 00:09:21,966 +它如果能叠 4 层 + +290 +00:09:22,000 --> 00:09:23,033 +它的这个可能性 + +291 +00:09:23,033 --> 00:09:25,800 +就已经变得 2 的 4 次方 是吧 + +292 +00:09:25,833 --> 00:09:27,666 +它就已经变成 16 种可能性了 + +293 +00:09:27,733 --> 00:09:30,166 +你在短短的这么几行代码里面 + +294 +00:09:30,200 --> 00:09:31,500 +你有 16 种可能性 + +295 +00:09:31,566 --> 00:09:33,033 +我不知道这个人脑的构造 + +296 +00:09:33,033 --> 00:09:34,700 +要到何等的层次 + +297 +00:09:34,700 --> 00:09:38,333 +才可以说轻易的理解这个事情 + +298 +00:09:38,366 --> 00:09:39,400 +在我看来三目运算符 + +299 +00:09:39,400 --> 00:09:40,833 +它就是一个很大的糟粕 + +300 +00:09:40,900 --> 00:09:44,100 +go 里边它就明确的说它们不支持 + +301 +00:09:44,100 --> 00:09:46,266 +像是泛型的话 + +302 +00:09:46,266 --> 00:09:48,433 +我当然是蛮喜欢泛型这个设计 + +303 +00:09:48,466 --> 00:09:49,333 +因为泛型它可以 + +304 +00:09:49,333 --> 00:09:52,133 +有一定高程度的一个抽象 + +305 +00:09:52,200 --> 00:09:54,200 +但我相信大家如果写过泛型 + +306 +00:09:54,233 --> 00:09:56,033 +你也会同意一件事情 + +307 +00:09:56,066 --> 00:09:56,566 +就是泛型 + +308 +00:09:56,633 --> 00:09:58,600 +它把很多问题变得很复杂 + +309 +00:09:58,633 --> 00:09:59,400 +当然写的好的人 + +310 +00:09:59,400 --> 00:10:01,066 +是可以拿泛型写出来花的 + +311 +00:10:01,100 --> 00:10:03,533 +写出来一个短短的几行代码 + +312 +00:10:03,600 --> 00:10:06,666 +写出来一些非常高深的一些操作 + +313 +00:10:06,700 --> 00:10:08,100 +一些技巧 + +314 +00:10:08,133 --> 00:10:09,100 +但我也要说 + +315 +00:10:09,133 --> 00:10:11,333 +大多数人并不是那种神仙 + +316 +00:10:11,400 --> 00:10:12,733 +大多数人是不会做那种 + +317 +00:10:12,733 --> 00:10:14,966 +TS 的这种类型体操的 + +318 +00:10:15,000 --> 00:10:16,433 +同样我其实也不认为 + +319 +00:10:16,433 --> 00:10:19,666 +我们应该学习这种类型体操 + +320 +00:10:19,700 --> 00:10:21,666 +因为它不是一个正常人的思维 + +321 +00:10:21,700 --> 00:10:22,400 +同样我也不认为 + +322 +00:10:22,400 --> 00:10:25,533 +它是一个 AI 应该理解的东西 + +323 +00:10:25,600 --> 00:10:27,633 +一段逻辑它就应该简简单单 + +324 +00:10:27,666 --> 00:10:29,566 +可读性第一的前提下 + +325 +00:10:29,633 --> 00:10:32,066 +我们才可以谈其它的东西 + +326 +00:10:32,100 --> 00:10:34,200 +那我们回到另一个问题 + +327 +00:10:34,266 --> 00:10:35,533 +就是 rust + +328 +00:10:35,600 --> 00:10:36,866 +rust 它的性能好不好呢 + +329 +00:10:36,900 --> 00:10:37,700 +它非常的好 + +330 +00:10:37,733 --> 00:10:40,200 +它甚至能够自己控制 GC + +331 +00:10:40,266 --> 00:10:43,333 +因为 GC 它不可避免的是会影响性能的 + +332 +00:10:43,400 --> 00:10:44,633 +而且它也有一定的 + +333 +00:10:44,633 --> 00:10:46,666 +不可预测的性质在那里 + +334 +00:10:46,666 --> 00:10:48,800 + rust 它就可以让你控制 GC + +335 +00:10:48,833 --> 00:10:50,000 +那这样你就可以去 + +336 +00:10:50,000 --> 00:10:52,300 +写一些极端的高性能的场景 + +337 +00:10:52,333 --> 00:10:54,733 +一些计算可以不用被 GC 打断 + +338 +00:10:54,800 --> 00:10:56,666 +它的好处就是极端的性能 + +339 +00:10:56,700 --> 00:10:57,400 +同样的话 + +340 +00:10:57,466 --> 00:10:58,500 +它的坏处就是 + +341 +00:10:58,500 --> 00:11:00,533 +就是你需要自己去手动控制 + +342 +00:11:00,533 --> 00:11:01,733 +rust 这个语言 + +343 +00:11:01,733 --> 00:11:03,366 +我用下来的给我的感觉就是 + +344 +00:11:03,366 --> 00:11:05,733 +我每次都要重新学习一下这个语言 + +345 +00:11:05,800 --> 00:11:08,600 +它的语言体系太复杂了 + +346 +00:11:08,633 --> 00:11:11,033 +如果说你到现在你很喜欢 rust + +347 +00:11:11,066 --> 00:11:12,400 +我其实建议你去搜索一下 + +348 +00:11:12,400 --> 00:11:15,833 + pin unpin unbox unwrapper 这些概念 + +349 +00:11:15,866 --> 00:11:17,700 +我觉得对我来说是比较复杂的 + +350 +00:11:17,733 --> 00:11:19,566 +但是它最复杂还是一个生命周期 + +351 +00:11:19,633 --> 00:11:20,800 +因为像我前文说的 + +352 +00:11:20,800 --> 00:11:22,466 +你可以自己去控制 GC 的时候 + +353 +00:11:22,500 --> 00:11:24,066 +当然它的这个 GC 控制 + +354 +00:11:24,066 --> 00:11:25,866 +也并不像我们 c 或者 c ++ + +355 +00:11:25,866 --> 00:11:28,933 +你自己去写 malloc 或者 free 这样方法 + +356 +00:11:29,000 --> 00:11:31,200 +而是它是通过生命周期的方法 + +357 +00:11:31,200 --> 00:11:32,966 +来去做的这样一个事 + +358 +00:11:33,000 --> 00:11:35,600 +我只能说它有点太难了 + +359 +00:11:35,666 --> 00:11:37,333 +那如果说你到今天你还认为 + +360 +00:11:37,333 --> 00:11:39,500 +rust 它是一门很好的语言 + +361 +00:11:39,533 --> 00:11:40,866 +你会更倾向于 + +362 +00:11:40,866 --> 00:11:43,033 +拿 rust 来去重写 typescript + +363 +00:11:43,100 --> 00:11:43,933 +有没有这种可能呢 + +364 +00:11:44,000 --> 00:11:45,233 +我认为是有的 + +365 +00:11:45,266 --> 00:11:46,700 +因为毕竟 typescript 其实 + +366 +00:11:46,700 --> 00:11:48,866 +其实和 bun 是比较像的 + +367 +00:11:48,900 --> 00:11:50,866 +因为它有（相对）非常充足的测试用例 + +368 +00:11:50,900 --> 00:11:53,333 +它也有非常大的使用量 + +369 +00:11:53,400 --> 00:11:55,433 +所以我认为如果拿 AI 来去 + +370 +00:11:55,466 --> 00:11:57,700 +拿 rust 来去重写 typescript + +371 +00:11:57,733 --> 00:11:59,766 +应该是一个非常有可能的项目 + +372 +00:11:59,833 --> 00:12:01,866 +而且它很有可能在短短 + +373 +00:12:01,866 --> 00:12:05,533 +认为两周之内就做完这件事情 + +374 +00:12:05,600 --> 00:12:08,633 +但我想到的可能是关于可读性 + +375 +00:12:08,666 --> 00:12:10,033 +关于可拓展性 + +376 +00:12:10,066 --> 00:12:11,833 +关于将来的维护 + +377 +00:12:11,833 --> 00:12:13,366 +那我认为 go 的它可能是一门 + +378 +00:12:13,400 --> 00:12:17,233 +更加适合人类去维护的一个语言 + +379 +00:12:17,266 --> 00:12:18,333 +Rust 是吗 + +380 +00:12:18,400 --> 00:12:19,900 +它当然也是 + +381 +00:12:19,966 --> 00:12:23,566 +但是我认为它对于这种平衡的把握 + +382 +00:12:23,600 --> 00:12:25,800 +也许它更加偏向于性能一点 + +383 +00:12:25,833 --> 00:12:27,266 +如果到这里 + +384 +00:12:27,266 --> 00:12:28,366 +你还是十分不同意我的说法 + +385 +00:12:28,400 --> 00:12:31,066 +我当然欢迎你在评论区来谈谈你的看法 + +386 +00:12:31,133 --> 00:12:32,766 +但我更建议的做法就是 + +387 +00:12:32,800 --> 00:12:34,200 +我们可以尝试拿 rust 来去 + +388 +00:12:34,200 --> 00:12:36,700 +写一个大概 1万量级的一个项目 + +389 +00:12:36,766 --> 00:12:39,666 +我相信当很多人真的去拿 rust + +390 +00:12:39,666 --> 00:12:41,833 + 来去写过 1万行以上代码 + +391 +00:12:41,833 --> 00:12:44,566 +来去尝试 rust 的拥趸 + +392 +00:12:44,600 --> 00:12:47,300 +应该就会冷静一些 + +393 +00:12:47,366 --> 00:12:48,233 +当然你写完之后 + +394 +00:12:48,300 --> 00:12:50,500 +也欢迎在评论区来去聊一聊你的看法 + +395 +00:12:50,533 --> 00:12:51,933 +聊一聊对于 rust 这个语言 + +396 +00:12:51,966 --> 00:12:54,266 +是不是该去重写万物 + +397 +00:12:54,333 --> 00:12:56,666 +是不是说 typescript 的团队的决策 + +398 +00:12:56,666 --> 00:12:58,166 +是一个错误的行为 + +399 +00:12:58,200 --> 00:12:58,433 +OK + +400 +00:12:58,500 --> 00:12:59,800 +那我们今天的节目就到这里 + +401 +00:12:59,800 --> 00:13:00,966 +我们下期节目再见 + +402 +00:13:00,966 --> 00:13:01,466 +拜拜 + diff --git a/src/assets/ep75/cover.png b/src/assets/ep75/cover.png new file mode 100644 index 0000000..3901072 Binary files /dev/null and b/src/assets/ep75/cover.png differ diff --git a/src/content/posts/ep75.mdx b/src/content/posts/ep75.mdx new file mode 100644 index 0000000..6ef04e5 --- /dev/null +++ b/src/content/posts/ep75.mdx @@ -0,0 +1,52 @@ +--- +type: podcast-episode +status: published +slug: /posts/ep75 +guid: 75 +title: "EP75 TypeScript 7：十倍性能的升级之外，为什么选 Go？" +subtitle: "TypeScript 7：十倍性能的升级之外，为什么选 Go？" +publicationDate: 2026-09-14 +author: AnnatarHe +season: 3 +episodeNumber: 75 +episodeType: full +excerpt: "TypeScript 7 用 Go 重写后带来显著性能提升。本期从大型项目的升级体验出发，聊聊为什么选择 Go 而不是 Rust，以及性能、开发效率和长期可维护性之间的取舍。" +url: https://youtu.be/OMIfl3o8Z0g +size: 0 +duration: 0 +explicit: false +xyzLink: https://www.xiaoyuzhoufm.com/episode/6aa91677817d148207aef549 +youtubeId: OMIfl3o8Z0g +biliUrl: //player.bilibili.com/player.html?isOutside=true&aid=117270172931735&bvid=BV1jreV6HEWm&cid=41895921039&p=1 +cover: ../../assets/ep75/cover.png +srt: /subtitles/ep75.srt +categories: + - TypeScript + - TypeScript7 + - Go语言 + - Rust + - 前端开发 + - 编程语言 + - 技术选型 + - 软件工程 + - 程序员 + - 开发者 + - Web开发 + - AsyncTalk +--- + +### 📕 Shownotes + +TypeScript 7 终于来了。 + +这次最直观的变化不是新语法，而是 Go 重写之后带来的性能提升：VS Code 的类型检查从 78 秒降到 7.5 秒；我自己的一个 58 万行 TypeScript 项目，也从大约 14 秒降到了 3 秒左右。 + +但这期我更想聊的是另一个问题： + +**为什么 TypeScript 选择了 Go，而不是 Rust？** + +从 TS7 的实际升级体验出发，聊聊大型项目里的类型检查和编辑器性能，也聊聊 Go、Rust 在性能、复杂度、可读性和长期维护上的取舍。 + +我自己写了七八年 Go，也实际用 Rust 写过一些项目。相比“Rust 重写一切”，我越来越觉得：工程技术选型追求的从来不只是极致性能，而是在性能、开发效率和可维护性之间找到平衡。 + +所以，TypeScript 团队这次选 Go，你怎么看？