事件起因是 AWS 前几天发布的一篇博客：《Sustainability with Rust》。
在这篇文章里，AWS 举例的时候将 Rust 和 Go 进行了对比。文章提到了早期 Discord 的一项关键 Go 服务存在问题，原本这是一个非常简单的服务，但它的尾部延迟 (Tail Latency) 非常慢。AWS 认为原因在于 Go 是一种垃圾回收 (GC) 语言，因此当对象被创建和释放时，垃圾回收器每隔一段时间就需要停止程序的执行并运行一次垃圾回收。当垃圾回收器运行时，会导致进程无法响应请求。
为了解决此问题，Discord 决定尝试用 Rust 重写这个服务。测试结果显示，使用 Rust 重写后的速度提升超 10 倍，最慢的尾部延迟时间也降低至为原来的约 1%。
下图是运行过程中 CPU 和响应时间的峰值，左边为 Go 实现的版本，右边为 Rust 实现的版本。
Go 开发团队 leader Russ Cox (rsc) 认为 AWS 在这里的比较对 Go 存在严重的误导。他认为，AWS 的文章将两者进行对比时，将 Go 版本的数据与在使用新的数据结构和更多内存后的 Rust 版本数据放在了一起，还特意圈出“ms”和“µs”时间刻度。rsc 表示，这要么是 AWS 对 Discord 的原贴存在误解，要么就是公然地说谎。
因为在 Discord 的原文中，他们展示 Go 服务器和同级别 Rust 服务器的对比时，图表数据来源既有原始的版本，也包括重写数据结构和提供额外内存后的情况。AWS 的文章却对此进行了故意的歪曲。
而且 AWS 引用的 Discord 数据当时使用的 Go 版本还是 Go 1.10，但现在 1.18 版本很快就推出了。在这 8 个重要版本的迭代过程中，Go 团队改进了许多功能，对因 GC 而引起的中断也提供了极大的改善（这正是当时 Discord 面临的问题）。
除了这个，rsc 认为 AWS 引用的一份“非常有趣”的研究的真实性也十分可疑。
rsc 表示，AWS 的文章对 Rust 的描述公正客观，但对 Go 却存在误导性的描述。他认为 Rust 和 Go 不是零和的博弈关系。Rust 十分优秀，所以他更愿意关注 Go 和 Rust 相互补充并进行良好合作的方式。比如这个案例：https://thenewstack.io/rust-vs-go-why-theyre-better-together/
猜你喜欢: