GC - Tony Bai

标签 GC 下的文章

金融级基础设施重构：放弃 Rust 拥抱 Go，务实主义的最终胜利？

二月 23, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/02/23/financial-infrastructure-rust-to-go-pragmatism-victory

大家好，我是Tony Bai。

在系统级编程语言的版图上，Go 与 Rust 的对比与争论从未停歇。一个是崇尚大道至简、开发效率极高的“云原生时代王者”；另一个则是以内存安全、零成本抽象和极致性能著称的“极客新宠”。当这两种哲学碰撞在对安全性、稳定性和低延迟要求极高的金融/交易基础设施领域时，开发者该如何抉择？

近日，在 Reddit 的 r/golang 社区中，一场由 Python 开发者发起的关于“金融基础设施长期演进：Go 还是 Rust？”的技术讨论引发了广泛关注。这位开发者试图为机器学习（ML）流水线、分布式后端和内部 DevOps 工具选择一门强类型语言，并一度陷入了“是否应该同时学习两者”的焦虑中。

这场社区讨论不仅揭示了两种语言在现代架构中的真实定位，更展现了 Go 社区一贯的“务实主义”工程哲学。本文将深度提炼这场讨论的核心观点，为正处于技术选型十字路口的架构师和开发者提供极具价值的参考。

核心探讨：金融系统中的“快”与“对”

在金融科技（FinTech）和交易系统中，有两个指标至关重要：性能（Performance/Latency）与正确性（Correctness）。这恰好对应了系统级语言常常被审视的两个维度。

Rust 的诱惑：绝对的控制与“编译即正确”

许多开发者最初被 Rust 吸引，正是因为其在金融领域展现出的“绝对严谨”。

代数数据类型与状态机：社区用户指出，Rust 的表达能力极强。在处理复杂的金融业务逻辑（如订单状态流转、复杂的税务和结算规则）时，Rust 的枚举（Enum）和模式匹配可以迫使开发者在编译期处理所有可能的边缘情况，实现所谓的“使无效状态不可表达”（Make invalid states unrepresentable）。
无数据竞争（Data Race Free）：借用检查器（Borrow Checker）和所有权模型在根本上杜绝了多线程环境下的数据竞争。对于处理资金流水的并发程序而言，这种内存安全性能够极大地降低睡眠被报警惊醒的概率。
无 GC 延迟：针对极度敏感的场景（如做市商系统），Rust 摆脱了垃圾回收器（Garbage Collector）的不可预测性，能够提供稳定、可预测的尾部延迟（Tail Latency）。

然而，正如资深工程师在讨论中指出的：“Rust 的高壁垒不仅体现在初始学习成本上，更体现在它持续要求你的大脑处于高速运转状态。” 在编写普通业务代码时，开发者需要不断与编译器“搏斗”，这在无形中拖慢了业务交付（Shipping）的速度。

Go 的底气：“80% 的性能，20% 的精力”

面对 Rust 强大的理论优势，Go 社区给出的回应并不是在极限性能上去硬碰硬，而是打出了一张工程学上的王牌：投入产出比（ROI）。

极速的开发与迭代：“如果你的目标是尽快发布产品（Ship fast），同时保持系统的可靠性，Go 是完美的折中。” Go 语言的语法极简，没有复杂的生命周期标注，这使得开发者可以把 100% 的精力放在业务逻辑和系统架构上，而不是讨好编译器。
完美的 I/O 并发模型：金融系统的很大一部分工作并非重度 CPU 计算，而是网络 I/O（如对接外部交易所 API、读取数据库、微服务间通信）。Go 内置的 goroutine 提供了极其廉价的上下文切换机制。一位用户精辟地总结：“在处理高度并发或重度 I/O 阻塞的操作时，Go 是无敌的。而在 Rust 中构建高并发的异步（Async）应用，需要极高的经验值，但在 Go 中这就像呼吸一样自然。”
足够好的性能与 GC：虽然 Go 有垃圾回收机制，但经过十多年的演进，Go 的 GC 停顿时间已经达到了亚毫秒级。对于 99% 的金融应用（如支付网关、账单系统、风控后端）来说，Go 的性能已经“快到了性能盈余”的地步。社区用户坦言：“除非你是在证券交易所做内部的高频交易（HFT），否则 Go 的速度绝对绰绰有余。”

领域决定边界：基础设施与业务逻辑的解耦

讨论中一个非常核心的洞见是：不要试图用一种语言解决所有问题，而是要看清具体领域的边界。楼主的背景是 Python，主要涉及 ML 流水线。这引出了现代架构中非常经典的一种组合模式。

Python + Go：现代数据驱动架构的“王炸”组合

Python 主宰数据与模型：在机器学习、量化分析和数据科学领域，Python 的生态（Pandas, NumPy, PyTorch）具有不可撼动的统治地位。强行用 Go 或 Rust 去重写模型训练或复杂的矩阵运算，被社区公认为“过早优化”和“重复造轮子”。
Go 主宰服务与编排：当模型训练完成需要部署上线，或者需要构建处理海量请求的 API 网关、数据搬运管道、以及后端微服务时，Python 的 GIL（全局解释器锁）和性能瓶颈就会显现。此时，引入 Go 作为基础设施层（Infrastructure Layer）是最完美的互补。

这种架构下，系统被清晰地划分为：Go 负责将数据又快又稳地搬运和路由，Python（在底层 C/C++ 的加持下）负责纯粹的数学和模型计算。这种解耦使得整个系统既享受了 Python 的生态红利，又获得了 Go 在分布式系统上的强悍工程能力。

真正的 HFT（高频交易）属于谁？

不可忽视的是，当讨论深入到金融领域的最底端——高频交易（HFT）时，社区展现出了极度客观的技术视野。

多位业内人士指出，在纳秒必争的超低延迟交易领域，C++ 依然是绝对的霸主。尽管 Rust 在试图切入这一市场，但 C++ 在传统金融领域积累的庞大库、成熟的生态以及直接操作硬件的能力，短期内难以被撼动。因此，如果业务的核心真的是 HFT，那么 Go 和 Rust 可能都不是最优解。这就进一步确认了 Go 的主战场：高吞吐的分布式后端与云原生基础设施。

隐性成本：认知负荷、团队建设与代码维护

在架构决策中，语言的特性往往只占 50%，另外 50% 则是关于人的管理。这也是本次社区讨论中，Go 获得压倒性支持的关键原因。

代码的生命周期与可修改性

“在商业应用中，我更看重随着时间的推移，修改代码有多难。业务需求在不断变化，代码也必须随之改变。”

Go 的修改成本极低：Go 的代码结构扁平，没有复杂的隐式抽象。这使得重构和修改极其快速。Go 的接口（Interface）设计是隐式的（Duck Typing），在拆分微服务或调整模块时，不需要像严格继承体系那样大动干戈。
Rust 的“牵一发而动全身”：Rust 高度严格的类型系统是一把双刃剑。虽然它保证了修改后的代码几乎不会出错，但在快速迭代期，添加一个新功能往往意味着要重构一大部分的生命周期标注和类型关系，这对于需要快速响应市场变化的初创项目来说是致命的。

团队招聘与代码交接

“如果你用 Rust 构建了一个工具，当系统在半夜发生故障时，团队里的其他人能轻易地看懂代码并修复它吗？”

Go 的创造者之一 Rob Pike 曾明确表示，Go 的设计初衷就是为了解决 Google 内部大型团队的协作问题。Go 的语法少、规范统一（gofmt），被称为“没有魔法的语言”。一个有其他语言基础的程序员，通常只需一两周就能熟练上手 Go 并提交生产代码。

相比之下，熟练的 Rust 开发者在市场上不仅稀缺，而且薪资高昂。对于一家非底层技术驱动的金融公司而言，使用 Go 可以极大地降低招聘门槛和团队代码交接的风险。

小结：务实主义的胜利

回到这位发帖者的终极问题：“我应该同时深入学习 Go 和 Rust 吗？”

社区给出的答案异常一致：绝对不要。 尤其是在项目初期。同时学习两门底层逻辑截然不同的语言，不仅会带来巨大的认知撕裂，还会严重拖慢项目进度（Shipping speed）。

最终，这位发帖者更新了他的决定：选择 Go。

“我不想在开始阶段就陷入困境，既然我是独立开发，我开始觉得 Go 才是正道。对于沉重的数学计算，我会继续让 Python 负责。我意识到 Go 真的非常好用，只要我懂得正确使用它，它能在所有的用例中大显身手。此外，Go 社区是我见过最友好的社区之一，你们太棒了！”

在 AI、区块链、量化金融等技术泡沫层出不穷的今天，技术选型很容易陷入“追逐时髦”（Hype Driven Development）的陷阱。Rust 无疑是一门伟大的语言，代表了系统编程的未来探索。然而，Go 语言的伟大之处在于它始终保持着极其清醒的工程边界感。

它不追求类型理论的极致完美，也不苛求消除最后百分之一的性能损耗，它追求的是：在开发者心智负担、编译速度、运行性能、并发模型和部署便利性之间，找到一个无可挑剔的全局最优解。

对于现代分布式系统、网络服务和金融后端基础设施而言，Go 依然是那个能够让你“早点下班、安心睡觉”的最优选择。这也是务实主义在工程世界里，又一次漂亮的胜利。

资料链接：https://www.reddit.com/r/golang/comments/1ra0dza/go_vs_rust_for_longterm_systemsfinance/

你怎么选？

软件工程永远是权衡的艺术。在你看来，对于非高频交易的后端业务，Rust 带来的安全性是否足以抵消它的开发成本？如果你现在接手一个新项目，你会优先选择“能让你早点下班”的 Go 吗？

欢迎在评论区分享你的选型“心法”！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

TypeScript 编译器 Go 重写版提速 10 倍：微软团队深度揭秘幕后工程细节

一月 27, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/01/27/typescript-compiler-go-rewrite-10x-speed-microsoft-details

大家好，我是Tony Bai。

“JavaScript 是一门很棒的语言，但它并不是为了编写编译器而设计的。”

备受瞩目的 TypeScript 编译器 Go 重写版（代号 TypeScript 7.0）已经取得了惊人的 10 倍性能提升。在最近的 GopherCon 2025 上，来自 Microsoft TypeScript 团队的 Jake Bailey 带来了一场干货满满的分享，深度揭秘了这场跨语言大迁徙背后的工程挑战与技术细节。

为什么最终选择了 Go？庞大的 AST 如何在 Go 中高效表达？又是如何通过并发设计打破 Node.js 的性能枷锁的？本文将带你深入编译器内部，一探究竟。

img{512x368}

缘起：当 JavaScript 触碰到天花板

TypeScript 自 2012 年发布以来，一直采用“自举” (Self-hosting) 的方式，即用 TypeScript 编写 TypeScript 编译器。这带来了巨大的好处：团队能第一时间吃自己的狗粮，社区贡献也极其方便。

然而，JavaScript 并不是为了编写高性能编译器而设计的。随着代码库规模的爆炸式增长（如 VS Code 的 150 万行代码），基于 Node.js 的编译器逐渐触碰到了性能天花板：

单线程与内存限制：JavaScript 无法高效利用多核 CPU，且 Node.js 构建环境（如 Electron）常常面临 4GB 内存上限，导致大型项目编译时频繁 OOM。
昂贵的对象模型：JavaScript 的对象模型开销巨大，而编译器需要创建数以百万计的 AST 节点，这对内存和 GC 都是沉重的负担。
异步的代价：async/await 虽然方便，但带来了著名的“函数着色”问题，且 Promise 对象的分配本身就有非零的运行时开销。

尽管团队已经用尽了 JIT 优化、缓存、单态化 (monomorphization) 等高级手段，但性能提升的边际效应越来越小，OOM 问题依然挥之不去。移植到另外一种语言，成为了打破僵局的唯一选择。

明确目标：新编译器的硬性指标

既然决定要移植到新语言，那么新语言必须解决 JavaScript 的痛点，同时不能丢失现有的优势。团队列出了几条不可妥协的硬性指标：

极致速度：必须编译为原生机器码 (Native Code)，摆脱解释器和 JIT 的预热开销。
共享内存并发：这是性能翻盘的关键。新语言必须对多线程共享内存有强力支持，以便充分压榨多核性能。
跨平台支持：必须能运行在所有主流操作系统上，最重要的是——必须能编译为 WebAssembly，以确保在浏览器环境（如 vscode.dev）中的体验。
无缝移植：鉴于 TypeScript 没有正式的语言规范（Spec），现有的编译器实现就是事实上的规范。因此，新语言必须能够最大程度地保留原有代码的结构和逻辑，以确保行为的一致性。

正是这几条苛刻的标准，将选型的范围迅速缩小。

选型：为什么是 Go？

在考察了 Rust、C#、Zig 等语言后，Go 脱颖而出。Jake 透露了核心的决策逻辑：

带 GC 的内存管理：编译器涉及大量复杂的、循环引用的数据结构（如 AST 节点），“手动”管理内存（如 Rust）会带来巨大的心智负担和开发成本。Go 的 GC 完美契合这一需求。
结构相似性：TypeScript 的代码风格（无类、大量函数和接口）与 Go 非常相似。这使得“移植”而非“重写”成为可能。
学习曲线平缓：团队中大部分是 TypeScript 专家而非系统编程专家。Go 的简单性让团队能迅速上手。
跨平台与性能：Go 编译为原生机器码，天生支持高并发，且能轻松跨平台（包括编译为 WASM）。

Go完美地契合了TypeScript编译器移植的需求！

早期验证：手写原型与意外惊喜

在决定全面转向 Go 之前，团队并未贸然行动，而是采取了稳健的“原型验证”策略。

他们从编译器的最底层——扫描器 (Scanner) 和解析器 (Parser)——开始，尝试手工将 TypeScript 代码逐行“翻译”为 Go 代码。与此同时，为了确保决策万无一失，还有几位成员试探性地尝试了其他语言方案。

结果令人振奋：即使是初步的手写 Go 代码，解析速度也达到了原版的 5 倍左右！

更重要的是，团队惊喜地发现，手写的 Go 代码在结构和逻辑上与原始的 TypeScript 代码惊人地相似。这种代码形态上的高度一致性，不仅验证了 Go 是正确的选择，更为后续大规模自动化工具的开发注入了强心剂。

移植实战：从 ts-to-go 到并发革命

1. 自动化移植工具：ts-to-go

为了加速迁移，Jake 编写了一个 ts-to-go 工具，能将 TypeScript 代码“直译”为 Go 代码。

TS 的 interface -> Go 的 interface
TS 的 class -> Go 的 struct + methods
复杂的位运算和逻辑判断 -> 自动转换为 Go 的等价写法

虽然不能 100% 完美转换，但这让团队在初期就能获得一个“虽然丑但能跑”的版本，极大加速了进程。

2. 数据结构的重新设计

在 JavaScript 中，对象是动态的；在 Go 中，一切皆有类型。团队不得不对 AST 的数据结构进行大刀阔斧的改革。

消除 interface 滥用：最初的移植版本大量使用 interface 来模拟 TS 的多态，导致了巨大的内存开销（胖指针）和 nil 检查地狱。
拥抱 struct 嵌入：最终，他们设计了一个基础 Node 结构体，并将其嵌入到所有具体的 AST 节点中。这不仅减少了内存占用，还彻底解决了 nil 接口的问题。

3. 并发：性能提升的核心引擎

这是 Go 带来的最大红利。旧的 TS 编译器是单线程的，解析、绑定、检查、生成都在一条线上排队。

而在 Go 版本中：

解析 (Parsing)：每个文件可以独立解析，完全并行。
绑定 (Binding)：每个文件的符号绑定也是独立的，完全并行。
类型检查 (Type Checking)：这是最难的部分，因为文件间存在复杂的依赖。团队采用了“独立检查器” (Independent Checkers) 的模式，为每组文件分配一个独立的检查器，虽然会有少量重复工作，但实现了高度的并行化。

结果是惊人的：VS Code 的编译时间从 80 秒缩短到了 7 秒，速度提升超过 10 倍！

踩坑与优化：Go 也没那么简单

当然，移植过程并非一帆风顺。Jake 分享了几个典型的“水土不服”案例：

影子变量 (Shadowing)：Go 允许在内层作用域遮蔽外层变量（如 err、result等），这导致了无数隐蔽的 Bug。Jake 甚至为此专门写了一个静态分析工具(https://jakebailey.dev/posts/go-shadowing)来抓这些虫子。
方法值的分配：在 Go 中，将方法作为值传递（如 parser.LookAhead）会产生一次内存分配。在一个频繁调用的紧密循环中，这带来了 17% 的性能损耗。解决方案是改回显式的函数调用。
字符串拼接：JavaScript 引擎对字符串拼接有深度优化（Cons-string），而 Go 的 + 操作符则是实打实的内存拷贝。这导致初期的移植版本在处理大量字符串时性能惨不忍睹。

遗憾与取舍：那些我们怀念的 TypeScript 特性

正如 Jake 在演讲中所言，这次迁移是一场巨大的工程胜利，但也是一次充满妥协的旅程。从表达力丰富的 TypeScript 转向“极简主义”的 Go，团队不得不忍痛割爱，放弃了许多令人怀念的语言特性：

编译期空值安全 (Compile-time nil safety)：这是团队最怀念的特性。在 Go 中，空指针异常（Panic）依然是悬在头顶的达摩克利斯之剑，而在 TypeScript 中，null/undefined 是类型系统的一部分，能被编译器严格检查。
空值合并与链式调用 (??, ?.)：Go 缺乏这些语法糖，使得代码中充斥着冗长的 if x != nil 检查，远不如 TypeScript 优雅。
联合类型与类型收窄 (Union types, narrowing)：TypeScript 强大的联合类型让数据建模极其灵活，而在 Go 中，这不得不退化为接口或带有大量字段的结构体。
泛型方法与三元运算符：这些“现代化”特性的缺失，让从前端背景转过来的工程师们颇感不适。

然而，对于编译器团队来说，为了性能，这一切“阵痛”都是值得的。他们用语法的繁琐换取了运行时的极速，这正是工程世界中最经典的“等价交换”。