代码经济：Rust 在项目中无法带来回报

开发经济学：为何转向内存安全语言并不划算

商业公司通过将代码质量视为产品属性而非最终目标来最大化利润。优化重点在于总拥有成本相对于收入的比例。标准软件许可证免除了开发者对用户损失的责任，消除了追求零错误水平的动力。

一系列非关键性漏洞维持着服务生态系统：客户通过定期更新和支持与开发者绑定。修复漏洞的成本仅占预算的一小部分。像Rust这样的内存安全语言所预防的错误仅占开发总投入的百分之几。

转向此类语言需要重构图结构、复杂依赖关系和架构。与编译器斗争所花费的时间超过了减少错误带来的节省，使得在商业项目时间表内无法实现投资回报。

开发工作流中的漏洞修复

在活跃项目中，缺陷修复被整合到新功能开发中。为功能修改代码自然会消除旧漏洞，无需单独投入。这是C++、Rust或任何语言的通用机制。

在处理任务时，开发者会顺便修复相关代码。重写会附带提高质量，无需针对性漏洞追踪。经济模型不鼓励完全消除错误，因为其成本由用户而非团队承担。

成本对比：C++与内存安全替代方案

| 方面 | C/C++ | Rust类语言 |

|--------|--------|---------------|

| 漏洞修复成本 | 预算的1-5% | 减少几个百分点，但+编译器开销 |

| 架构时间 | 标准 | 图结构/依赖关系增加20-50% |

| 切换投资回报率 | >5年 | 无法实现 |

| 支持生态系统 | 因漏洞而稳定 | 服务减少的风险 |

数据反映典型项目：切换不会节省资源，反而增加支出。

切换由意识形态驱动，而非经济考量。工程需考虑约束：时间、预算、人员。为“安全”忽视这些并非理性选择。

关键要点

• 利润至上：质量源于总拥有成本/收入，而非绝对标准。
• 漏洞作为商业工具：它们通过服务维持客户留存。
• 内存问题权重极低：占成本的1-5%，在开发流程中修复。
• 安全语言的开销：编译器时间 > 漏洞节省。
• 流程的普适性：代码演进在任何语言中都能提高质量。

最终，技术栈选择由实际成本决定，而非关于安全性的营销口号。

— Editorial Team