项目背景与技术选型 - 一家快速成长的独角兽初创公司主力应用采用Ruby on Rails和Node.js，未使用高性能编译型语言如Rust或Go [3] - 公司计划开发实时在线状态服务，初期需支撑10万并发用户，团队认为Ruby不适合此场景 [3] - 技术选型阶段，团队用Elixir、Rust、Ruby和Node.js编写原型进行性能测试，Rust因灵活性和性能脱颖而出 [4][6][7] Rust项目开发与性能表现 - Rust版本在基准测试中速度最快、内存占用最低，Elixir次之，Node.js受限于单线程，Ruby最慢 [10] - MVP版本仅用两周开发完成，两周部署上线，采用内存哈希表和Kafka事件推送的极简设计 [8][9] - 服务稳定支撑10万并发用户，后续扩展功能也未出现故障 [11] - 优化后性能显著提升：支持100万并发（p99延迟10ms）和200万并发（p99延迟25ms） [12] 管理决策与Rust团队解散 - 公司战略调整导致实时功能搁置，Rust团队解散，服务转入低维护状态 [12] - 新管理层认为Rust工程师"冗余"，要求其转岗至Ruby/Node.js或离职，3名Rust开发者全部离开 [14][15] - 决策层未采纳推广Rust的建议，尽管已有成熟服务、工程师和多个适用业务场景 [15] 技术重写与后续影响 - 管理层强制用Node.js重写Rust服务，首次尝试因架构复杂性失败，需依赖第三方平台Ably但性能不达标 [16] - 最终Rust服务虽仍在运行，但因缺乏维护团队，扩展需求被放弃或采用次优方案 [17] - 开发者社区反馈此类事件普遍存在，管理层常因不理解技术价值而抵触非主流技术 [18] 行业现象与开发者观点 - 类似案例常见：技术成功反导致团队被裁，因"无维护需求"难以向管理层证明价值 [17][18] - 企业扩张中管理更替易破坏技术创新，决策者倾向选择主流技术而非最优方案 [18] - Rust等高性能语言面临推广困境，尤其在非技术驱动型组织中 [15][18]