题目假设任何决议通过后都能立即 100%执行到位，如果这个假设成立，五年内实现人类命运共同体都不是问题。

前端工具链领域的优化空间是真的大。用 Rust 写过一轮后，未来也不太可能有几百倍的速度提升了。换句话说，像这样悬殊的性能对比是空前绝后的。

实在没有的话，可以把别的语言的包移植过来用

rust 不会自动清除无用的编译产物，要定期删掉 target 。
一些编译设置(高等级优化，增量编译，lto 等)会保存额外的中间信息。
debug 和 release 会产生两遍编译产物，有的 c/c++绑定会下载两遍预编译文件，没事可以删删 target/debug 。
交叉编译时对每个目标平台分别编译，有多少个就乘几倍……
有工具(sccache)可以跨工作区复用编译产物。上面有人说的透明压缩也能缓解。
rust 默认全部静态链接，手动设成动态链接可以减少中间产物体积，不过既麻烦又对泛型没用。
rust 的包管理和 nodejs 一样鼓励复用，导致动不动上百个间接依赖，也是膨胀得很厉害。

@dbskcnc
@mirrorman

Cloudflare 团队选择 Rust 是因为它可以在不妥协性能的前提下以内存安全的方式完成 C 语言所能做的事情。

"We chose Rust as the language of the project because it can do what C can do in a memory safe way without compromising performance."

快速安全地发布功能很困难，尤其是在我们的规模下。很难预测在每秒处理数百万个请求的分布式环境中可能发生的每个边缘情况。模糊测试和静态分析只能缓解这么多。Rust 的内存安全语义保护我们免受未定义行为的影响，让我们确信我们的服务将正确运行。
有了这些保证，我们可以更多地关注我们的服务更改将如何与其他服务或客户来源进行交互。我们可以以更高的节奏开发功能，而不会受到内存安全问题和难以诊断崩溃的负担。
当崩溃确实发生时，工程师需要花时间来诊断它是如何发生的以及是什么原因造成的。自 Pingora 成立以来，我们已经处理了数百万亿个请求，并且还没有因为我们的服务代码而崩溃。
事实上，Pingora 崩溃是如此罕见，当我们遇到一个问题时，我们通常会发现不相关的问题。最近，我们的服务开始崩溃后不久，我们发现了一个内核错误。我们还发现了一些机器上的硬件问题，过去排除了由我们的软件引起的罕见内存错误，即使在几乎不可能进行重大调试之后也是如此。

"Shipping features quickly and safely is difficult, especially at our scale. It's hard to predict every edge case that can occur in a distributed environment processing millions of requests a second. Fuzzing and static analysis can only mitigate so much. Rust's memory-safe semantics guard us from undefined behavior and give us confidence our service will run correctly.
With those assurances we can focus more on how a change to our service will interact with other services or a customer's origin. We can develop features at a higher cadence and not be burdened by memory safety and hard to diagnose crashes.
When crashes do occur an engineer needs to spend time to diagnose how it happened and what caused it. Since Pingora's inception we’ve served a few hundred trillion requests and have yet to crash due to our service code.
In fact, Pingora crashes are so rare we usually find unrelated issues when we do encounter one. Recently we discovered a kernel bug soon after our service started crashing. We've also discovered hardware issues on a few machines, in the past ruling out rare memory bugs caused by our software even after significant debugging was nearly impossible."

国内首个基于 Rust 语言的 RPC 框架 — Volo 正式开源！

https://mp.weixin.qq.com/s/XcceLyKxWOVtoMIJBuwXWQ

Volo 是字节跳动服务框架团队研发的轻量级、高性能、可扩展性强、易用性好的 Rust RPC 框架，使用了 Rust 最新的 GAT 和 TAIT 特性。

在字节内部，Volo 已经落地多个业务和基础组件，并且取得了超预期的性能收益（与 Go 版本对比，不那么公平）。

……

Cloudflare 将 Nginx 替换为用 Rust 编写的 http 代理服务 Pingora ，将 CPU 和内存消耗分别减少了约 70% 和 67%。Pingora 自部署以来已处理了数百万亿个请求，从未因为本身代码而崩溃。

https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/

cython ，rust pyo3 ，c++，nodejs ，c 语言动态库，都可以试试。
如果只需要一次性转换，还可以开好点的临时云服务器，大力出奇迹。

@HugoChao 这是战斗刚开始，等后期什么招式都能用出来

同意 2 楼，不同意 12 楼。
我定义理论上能够自举的编程语言就是独立的编程语言，不管它有没有真的实现自举。

试试 dprint

@FrankHB 你这么长篇大论下来，虽然确实说了很多知识，但还是在不断回避我关注的问题……
建议把你的观点整理起来发篇技术文章，比这样在评论区打转更有效率。后面我不再回复了。

@FrankHB 你说开销是实现细节，对不对呢，当然对，但很多时候调用方确实有理由去关注一个 API 在不同 path 的性能表现。和类型与 Monad 能做到以多占一个寄存器的代价(先不管 go 这个用积类型的奇葩)，去消除错误路径的额外开销，这时异常(unwind)的开销就成了劣势。给和类型与 Monad 提供对应的语法糖，也能解决啰嗦的问题。
至于函数签名，有人认为一个函数会不会出错应当体现在签名中，有人认为应当透明，这在各自场景里都是对的，但不能说哪边就是绝对正确。硬要无视场景区别去推行所谓“大多数”的决策，我觉得只会收到一大堆黑人问号。

@FrankHB 我认为根据特定场景去全面肯定或否定某种技术方案也是不妥的。“大多数”和“正确性”并没有必然联系，事实上很多工程决策后来都变成了历史遗留问题。
既然你这么推崇异常，评价一下另一种异常方案 herbception ？

@FrankHB 你说的“注定不可能克服”的“问题”当然是存在的，但在某些场景中就不算问题，不然谷歌为什么禁用 C++异常呢？
从其他错误处理方案的视角看，异常也存在注定不可能克服的问题，比如开销大、不能跨语言兼容、不适合嵌入式系统等。
总之就是一句话，没有银弹。

@FrankHB
首先改变 API 行为本身就是有风险的，下游不用改源码不代表没有行为会被破坏。你说的“工程劣势”在我看来不算什么问题。
其次异常的实现方式不止 unwind 一种，也不一定能保证二进制兼容。而且 unwind 在非 happy path 的开销非常大，不一定值得冒着性能退化的风险去优化 happy path 。
我只能说异常也不是银弹，用什么错误处理方式要根据具体场景决定。

一般有三种可能
1. 查询用户成功，取得有效值
2. 查询用户成功，但用户不存在
3. 查询用户失败

第 2 类是否算作错误，要根据业务决定。
通常情况下在出错时不可使用返回值，所以选 1 更好。

@FrankHB 所谓的 error neutrality 就是指默认向上传播错误？那 Rust 的问号运算符在这些语言中应该是最简单的，毕竟只要打一个字符。

@novolunt 然而用 zig 写的 bun 正苦于修 segfault