主要观点总结
文章讲述了开发者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: 开发者热议
许多开发者分享了类似的经历，认为这种事情几乎在所有公司都会发生。有开发者指出，这不仅仅是管理决策的问题，更是决策者对技术认知的不足和对新技术的抵触情绪。
正文
技术选型与基准测试：Rust 脱颖而出
起初，
负责该项目的团队倾向用 Rust，
不过管理层
对此
有疑虑，便要求用不同的语言写几个原型服务做个对比测试。
于是，
团队
决定
用 Elixir、Rust、Ruby 和 Node.js 分别写一个原型
——
不知为何
，当时
Go 没有列入候选
，
Drogus
猜测可能是因为那时他在休假所以没人提。
几天后，四个原型都写完了，他们
开始对
其
进行性能测试。
而
测试结果
属于是意料之中
：
值得注意的是，Rust 版本最初存在也一个小 bug：开发者用 async futures 给客户端发消息时，会遍历所有客户端来获取发送通道列表，这在高负载下会阻塞运行时几秒。
不过这个问题属于实现细节，对熟悉 Rust 的人来说并不难修复。
但由于写这个 Rust 原型的人是第一次写 Rust，经验不足，
而其他语言的原型都是由有经验的开发者完成的——
所以，即使有些小
bug
，也不是不能理解
。
从原型到正式上线，Rust 表现亮眼
测试完成后，团队成员讨论了各种语言的性能表现、易用性、在公司内部的适配性等等，最终再次选择了 Rust。很有意思的一点是，写 Rust 原型的那位开发者原本更偏好 Elixir（因为他用过），但实际写完后，
他
投票支持了 Rust。
原因很简单：
Rust 太灵活了。
基于评估结果和团队判断，公司最终决定由 Rust 实现该实时服务。而出于项目进度考虑，原本应由独立团队开发的任务，转交给了有 Rust
经验
的
Drogus
，并由他与 Rust 原型作者合作开发。
为了赶进度，
Drogus
决定
采用一个类似于数据库的极简设计。
在 Rust 中处理 10 万
个
连接不算难事，MVP（
最小可行产品
）
阶段也只需要实现基础功能：
查询某个用户是否在线、
用户在
应用的哪个区域；
