
11 月 2 日 · 8 分钟

TypeScript 7 终于来了。
这次最直观的变化不是新语法,而是 Go 重写之后带来的性能提升:VS Code 的类型检查从 78 秒降到 7.5 秒;我自己的一个 58 万行 TypeScript 项目,也从大约 14 秒降到了 3 秒左右。
但这期我更想聊的是另一个问题:
为什么 TypeScript 选择了 Go,而不是 Rust?
从 TS7 的实际升级体验出发,聊聊大型项目里的类型检查和编辑器性能,也聊聊 Go、Rust 在性能、复杂度、可读性和长期维护上的取舍。
我自己写了七八年 Go,也实际用 Rust 写过一些项目。相比“Rust 重写一切”,我越来越觉得:工程技术选型追求的从来不只是极致性能,而是在性能、开发效率和可维护性之间找到平衡。
所以,TypeScript 团队这次选 Go,你怎么看?
#TypeScript #TypeScript7 #Go语言 #Rust #前端开发 #编程语言 #技术选型 #软件工程 #程序员 #开发者 #Web开发 #AsyncTalkAI 从整集转写里归纳的,不是节目方的宣传语
一个 58 万行项目从 TS 6 的 64 秒检查降到 TS 7 的约 3 秒,以及标准 CLI 项目几乎无痛升级的判断依据。
主播维护过 300 万行代码库,TypeScript Language Server 一天崩溃五六次,迁移后不再崩溃的一手体感。
结尾那句挑战:拿 Rust 去写一个一万行级别的项目,写完之后拥趸应该就会冷静一些。
AI 读完整集转写后给出的推荐理由
TypeScript 7 用 Go 重写,VS Code 的类型检查从 18 秒降到 7.5 秒,一个 58 万行项目从 64 秒降到约 3 秒。但真正有意思的是后半段:在「用 Rust 重写一切」几乎成为政治正确的当下,主播用自己七八年 Go 经验和约一万行 Rust 实践,解释为什么 Go 的错误处理、没有三目运算符、克制的泛型设计,反而更适合人类长期维护。他还给不同意的人留了一个具体挑战。
由 AI 从整集转写生成,是创作者说明之外的补充
TypeScript 7 用 Go 重写带来约十倍性能提升:VS Code 的 TSC 类型检查从 18 秒降到 7.5 秒,一个 58 万行项目从 64 秒降到约 3 秒,标准 CLI 项目几乎无痛升级。但重度依赖 TypeScript API 的项目(如 Next.js 13.2 之前)需要等待 7.1 版本。节目重点讨论「为什么不是 Rust」:主播结合自己七八年 Go 经验和约一万行 Rust 实践,从性能、语言克制程度、错误处理设计、三目运算符与泛型的取舍、生命周期复杂度等角度,论证 Go 在可读性与长期可维护性上的平衡更适合重写 TypeScript,并建议质疑者亲手用 Rust 写一万行代码再下判断。
点一章从那里开始播 · 与上面创作者标的时间点各自独立
TypeScript 7 的十倍性能与无痛升级
主播介绍 TypeScript 7 用 Go 重写带来的性能提升:VS Code 的 TSC 类型检查从 18 秒降到 7.5 秒,公司一个 58 万行项目从 64 秒降到约 3 秒。标准 CLI 项目升级几乎无痛,今天就能直接替换。
三百万行代码库里的编辑器崩溃
主播讲述自己维护的项目从 250 万行扩展到 300 万行后,TypeScript Language Server 一天崩溃五六七八次,原因是内存或 CPU 占用过高。迁移到 TS 7 后不再崩溃,类型提示响应也更快,且代码量越大提升越明显。
重度依赖 TypeScript API 的项目怎么办
如果项目通过 TypeScript 包里的 API 做类型检查(如 Next.js 13.2 之前),升级会变麻烦。Next.js 13.3 可通过 experimental 参数开启 TS 7 CLI 支持,TypeScript 7.1 将支持 API,重度依赖者建议再等等。
为什么不是 Rust:一个被舆论风波带出的问题
TS 7 preview 发布时外网引起舆论风波,因为当下「用 Rust 重写一切」几乎是政治正确。主播结合自己七八年 Go 经验和约一万行 Rust 实践,表示如果由他重写也会选 Go,因为 Go 的平衡性做得非常好。
Go 的性能与克制:错误处理与三目运算符
主播反驳「Go 性能差」的说法,指出静态语言编译成机器码性能不会差。他赞赏 Go 的设计克制:泛型经过慎重考虑才加入,错误处理坚持每个函数显式返回 error,避免 try-catch 带来的 surprise。
三目运算符与泛型:可读性优先的取舍
Go 没有三目运算符,主播认为这是勇敢的设计:三目运算符每多一层可读性急速下降,四层就是 16 种可能性,没人能轻易理解。泛型同理,类型体操不是正常人的思维,逻辑应在可读性第一的前提下再谈其他。
Rust 的代价:生命周期与复杂度
Rust 性能极好,能自己控制 GC,适合极端高性能场景。但代价是语言体系太复杂,主播每次用都要重新学习,pin、pin box、worker 等概念复杂,最难的还是生命周期——「我只能说他有点太难了」。
用 Rust 重写 TypeScript 有可能,但 Go 更适合人类维护
主播承认用 AI 加 Rust 重写 TypeScript 很可能两周就能做完,但考虑到可读性、可扩展性和长期维护,Go 更适合人类维护。他建议不同意的人亲手用 Rust 写一万行代码,再回来评论区讨论。

11 月 2 日 · 8 分钟

10 月 26 日 · 6 分钟

10 月 16 日 · 12 分钟

10 月 8 日 · 6 分钟

AsyncTalk · 9 月 15 日 · 13 分钟
TypeScript 7 终于来了。
这次最直观的变化不是新语法,而是 Go 重写之后带来的性能提升:VS Code 的类型检查从 78 秒降到 7.5 秒;我自己的一个 58 万行 TypeScript 项目,也从大约 14 秒降到了 3 秒左右。
但这期我更想聊的是另一个问题:
为什么 TypeScript 选择了 Go,而不是 Rust?
从 TS7 的实际升级体验出发,聊聊大型项目里的类型检查和编辑器性能,也聊聊 Go、Rust 在性能、复杂度、可读性和长期维护上的取舍。
我自己写了七八年 Go,也实际用 Rust 写过一些项目。相比“Rust 重写一切”,我越来越觉得:工程技术选型追求的从来不只是极致性能,而是在性能、开发效率和可维护性之间找到平衡。
所以,TypeScript 团队这次选 Go,你怎么看?
#TypeScript #TypeScript7 #Go语言 #Rust #前端开发 #编程语言 #技术选型 #软件工程 #程序员 #开发者 #Web开发 #AsyncTalkAI 从整集转写里归纳的,不是节目方的宣传语
一个 58 万行项目从 TS 6 的 64 秒检查降到 TS 7 的约 3 秒,以及标准 CLI 项目几乎无痛升级的判断依据。
主播维护过 300 万行代码库,TypeScript Language Server 一天崩溃五六次,迁移后不再崩溃的一手体感。
结尾那句挑战:拿 Rust 去写一个一万行级别的项目,写完之后拥趸应该就会冷静一些。
AI 读完整集转写后给出的推荐理由
TypeScript 7 用 Go 重写,VS Code 的类型检查从 18 秒降到 7.5 秒,一个 58 万行项目从 64 秒降到约 3 秒。但真正有意思的是后半段:在「用 Rust 重写一切」几乎成为政治正确的当下,主播用自己七八年 Go 经验和约一万行 Rust 实践,解释为什么 Go 的错误处理、没有三目运算符、克制的泛型设计,反而更适合人类长期维护。他还给不同意的人留了一个具体挑战。
由 AI 从整集转写生成,是创作者说明之外的补充
TypeScript 7 用 Go 重写带来约十倍性能提升:VS Code 的 TSC 类型检查从 18 秒降到 7.5 秒,一个 58 万行项目从 64 秒降到约 3 秒,标准 CLI 项目几乎无痛升级。但重度依赖 TypeScript API 的项目(如 Next.js 13.2 之前)需要等待 7.1 版本。节目重点讨论「为什么不是 Rust」:主播结合自己七八年 Go 经验和约一万行 Rust 实践,从性能、语言克制程度、错误处理设计、三目运算符与泛型的取舍、生命周期复杂度等角度,论证 Go 在可读性与长期可维护性上的平衡更适合重写 TypeScript,并建议质疑者亲手用 Rust 写一万行代码再下判断。
点一章从那里开始播 · 与创作者标的时间点各自独立
TypeScript 7 的十倍性能与无痛升级
三百万行代码库里的编辑器崩溃
重度依赖 TypeScript API 的项目怎么办
为什么不是 Rust:一个被舆论风波带出的问题
Go 的性能与克制:错误处理与三目运算符
三目运算符与泛型:可读性优先的取舍
Rust 的代价:生命周期与复杂度
用 Rust 重写 TypeScript 有可能,但 Go 更适合人类维护
节目里自然聊到的,不是广告

AI 对内容的推测
☕🧄 这个比喻出自 2009 年周立波的一句「喝咖啡的怎么能和吃大蒜的呆在一起呢」;郭德纲后来在《你要高雅》里回了一句「雅和俗分不开,喝着咖啡就着大蒜,秋水共长天一色」。我们借它标注风格取向 —— 两端没有高下,编辑部式与熟人局式都能做出极好的节目。
http://www.ximalaya.com/album/53875103.xml复制概要、章节、提及与推广标注由 AI 生成,可能有误;内容版权归创作者,声湃按创作者开放的 RSS 收录。了解收录与 RSS →

11 月 2 日 · 8 分钟

10 月 26 日 · 6 分钟

10 月 16 日 · 12 分钟