公司Rust团队全员被裁，只因把服务写得「太稳定」：“项目0故障、0报警，那养着3个Rust工程师没...

主要观点总结

文章讲述了开发者Drogus所在公司因为一个成功的Rust项目而引发的一系列事件，包括项目选型、基准测试、服务上线、运行稳定后的团队调整、服务优化的惊人成果以及最终由于管理层变动导致的Rust服务被全面封禁和重写为Node.js的历程。文章还引发了开发者们的热议，许多人有类似的经历，并对这种现状进行了讨论。

关键观点总结

关键观点1: 项目背景介绍

一个疫情期间快速成长的独角兽初创公司，主要应用采用Ruby on Rails编写，部分工具使用Node.js。考虑用户增长预期，需要开发一个实时服务来支撑大量并发用户。

关键观点2: 技术选型与基准测试

团队最初倾向使用Rust，管理层对此有疑虑，于是进行了原型服务的对比测试。最终发现Rust版本速度最快、内存占用最低，被选定为实施方案。

关键观点3: Rust项目的成功与挑战

Rust实时服务成功上线并稳定运行，支撑起大量并发用户。但随着公司战略的调整和管理层的变动，Rust服务被全面封禁，原因是服务过于稳定导致团队无事可做。

关键观点4: Rust服务的后续遭遇

管理层决定重写Rust服务为Node.js版本。但首次重写尝试失败，因为Node.js实现同类服务需要重构架构，并且性能远不达标。最后，虽然Rust服务仍在运行，但由于没有维护团队，扩展需求被放弃或替换为次优方案。

关键观点5: 开发者热议

许多开发者分享了类似的经历，认为这种事情几乎在所有公司都会发生。有开发者指出，这不仅仅是管理决策的问题，更是决策者对技术认知的不足和对新技术的抵触情绪。