技术选型与项目背景 - 公司是一家疫情期间快速成长的独角兽初创公司，主力应用采用Ruby on Rails编写，视频处理工具使用Node.js实现，初期未采用高性能编译型语言如Rust或Go [2] - 公司计划开发实时服务以显示用户在线状态和操作行为，初期需支撑10万并发用户，团队普遍认为Ruby不适合实现此类系统 [2] - 技术选型阶段团队倾向Rust，但管理层要求进行多语言原型对比测试，最终测试语言包括Elixir、Rust、Ruby和Node.js [3] Rust技术表现 - 基准测试结果显示Rust版本速度最快、内存占用最低，Elixir次之，Node.js受限于单线程运行时，Ruby表现最慢 [3] - Rust原型虽存在小bug（高负载下阻塞运行时几秒），但对熟悉Rust的开发者来说易于修复 [3] - 团队综合考虑性能、易用性和公司适配性后最终选择Rust实现实时服务，原本偏好Elixir的开发者实际使用后也投票支持Rust [4] - Rust服务MVP版本仅用两周完成，再花两周部署上线，稳定支撑10万并发用户无压力，后续功能扩展也未出现故障 [5] 项目发展与团队变动 - 公司战略调整导致实时功能被搁置，Rust服务转入维护模式，原开发团队解散 [6] - 公司筹备大型活动时预计需支撑50万并发用户，管理层招聘3名Rust工程师优化服务，调整系统配置后性能显著提升：支持100万并发（p99延迟10ms）和200万并发（p99延迟25ms） [6] - 服务过于稳定导致Rust工程师无事可做，新管理层上任后认为团队冗余，强制要求Rust工程师转岗或离职 [7][8] - 3名Rust开发者全部离职，公司放弃推广Rust的宝贵机会，尽管存在多个业务场景亟需高性能组件 [8] 技术重写与行业反响 - 管理层决定将Rust服务重写为Node.js版本以便现有团队维护，但首次重写尝试失败 [9] - Node.js受限于单线程运行时，需重构架构（多进程、多节点、队列或数据库中转）才能支撑百万连接，实现复杂度远高于Rust方案 [9][10] - 目前Rust服务仍在运行但缺乏维护团队，扩展需求被放弃或改用次优方案替代 [10] - 开发者社区普遍反映类似情况在各公司常见，新管理层常因不理解技术价值而做出破坏创新能力的决策 [10]