概述
回顾在创业时，基于对性能、安全性、并发控制等特性的追求，决定把 Rust 作为后端的主要语言。认为 Rust 是一门“现代、安全又高效”的语言，兼顾性能与内存安全，因此看起来是非常理性的选择。然而，随着项目推进、团队扩张、业务变化，发现选择 Rust 作为主力语言带来了很多没有预料到的问题，最终使得开发效率、团队协作、演进灵活性等方面都受很大牵制。
主要问题与挑战
列举一系列他认为 Rust 在初创公司、产品开发过程中存在的不足或代价。以下是作者的关键反思和挑战点（并非全部，但最具代表性）：
| 问题类别 | 作者的观点 / 体验 | 具体表现 / 影响 |
|---|---|---|
| 上手学习曲线 & 语言复杂性 | Rust 的所有权、借用（ownership / borrowing）、生命周期（lifetimes）等概念，需要开发者深入理解，否则容易卡壳。 | 团队新成员上手困难、代码写起来较繁琐、很多边界情况需要显式处理。 |
| 开发速度 / 迭代速度受限 | 在创业初期最重要的是快速迭代、验证业务假设，而 Rust 对这些极端变化的适应性差。 | 每当接口、数据结构调整时，需要在多个模块、多个调用处同步修改类型与借用约束，耗费大量时间。 |
| 生态 / 库支持与成熟度 | 对于某些业务常见的模块（如 ORM、web 框架、通用中间件等），Rust 的库相比于成熟语言还不够丰富或成熟。 | 某些功能不得不自己实现或花更多精力去处理边界情况。 |
| 团队成员多样性 / 人才梯度 | 很难保证所有开发者都熟练 Rust，团队中可能有人更擅长其他语言。 | 新人、兼职、外包参与者的上手难度高，代码一致性和质量控制困难。 |
| 重构 / 演化成本高 | 随着业务发展，需求变动频繁。Rust 强类型、显式约束，使重构成本高。 | 小的改动可能牵一发而动全身，在多个地方都要做配套更新。 |
| 工具链 / 编译 /调试体验 | 编译时间、编译错误的可理解性、开发工具（如 IDE 支持、调试器等）对团队生产力的影响比预期大。 | 编译等待、错误提示阅读、调试困难成为日常阻力。 |
如果项目并不是什么极端高性能需求或系统编程场景，而是相对普通的 CRUD、业务逻辑驱动型服务，原本不需要 Rust 那么多“底层”保障。正因为他用了“过度工具”（over-engineering），在业务快速变化阶段反而吃亏
核心 “教训 / 反思 / 建议”
一些对后来者有借鉴意义的观点：
-
技术选型要符合业务阶段与团队能力
在早期阶段，速度和灵活性往往比极致性能更重要。技术栈应该是“够用且容易上手”的，而不是最优但难以驾驭的。 -
不要因为趋势/声浪而盲目采用“热门语言”
虽然 Rust 在社区中备受推崇，但这并不意味它适合所有场景。Rust 的优势在于系统编程、对性能/内存安全苛刻要求的场景，而不是通用业务逻辑服务。 -
分层使用 Rust 是更合理的路径
对于性能敏感或关键路径模块，可以考虑单独用 Rust 实现，而不是把整个业务都用 Rust 重写。这样可以在关键性能点发挥 Rust 的优势，而不因为整体系统都用 Rust 而带来沉重代价。 -
重视人员培训、团队能力与一致性
选择语言时要考虑团队成员的技能背景、接纳新人的难度以及未来维护成本。团队成员间的技术鸿沟可能成为日后瓶颈。 -
不要过早优化 / 过早复杂化
在还没验证市场、还没稳定业务模型时，过度追求技术上的安全、性能、严谨，反而可能拖慢进度、增加风险。 -
在演进阶段留出足够余地 / 设计良好的抽象层
技术栈、模块边界、接口层要足够灵活，以便在未来可能替换或调整。不要让语言选型成为不能换血的锁。
总结
简而言之，在创业早期把 Rust 作为主语言，是一个“听起来很理性但实则错误”的技术决策。后悔的是：Rust 给他带来了过高的复杂度、过低的迭代效率、重构难度，以及团队适配的痛苦。在普通业务服务（CRUD、API 层）这类需求下，用 Rust 全面“搞定”反而是一种负担。
创业者：选择语言/技术栈时，应更多从业务、团队和阶段需求出发，而不是从语言本身的“高级特性”出发；不要被技术潮流带偏。
