要不要选择 “小众不成熟” 的 Rust 作为公司技术栈？

周四在 OSPO Summit 现场的多位朋友都给我发来了一张图片，让我看看 Rust 是如此 "小众不成熟" 的编程语言被当作反面教育的案例，着实让我震惊。我可以想出来 100 个理由或者案例来反驳这个观点，最后我还是简单写了一句把图片发到 X 。 这几天正是 RustNation 在伦敦的会议，Google 讲到了使用 Rust 的生产效率。正好在我的页面上两个 Tweet 并排在一起，于是我截图发到朋友圈，成功引发了一众讨论。

这里我想表达的不是 Rust 成熟不成熟的问题，而是我们如何选择一个技术栈的思路。首先我非常同意研发团队使用某项技术（不管是不是开源）是需要纪律的，不是某团队同学自己喜好就决定使用或不使用的，但这是技术团队管理者来决定的么？

在国内公司的大多数团队，都缺乏一个具有商业意识、财务经验、丰富技术背景、运营经验和大局观良好的产品经理（VP），对产品思考的缺乏造成技术决策和产品设计的混乱。有的技术团队 Leader 按照自己的喜好、经验和团队的技术背景来决定技术栈，通常这种情况下选择是比较保守的，虽然风险比较低但是收益也相对较低。

所以我觉得选择什么技术栈是要按照商业、产品等综合因素来综合确定。任何一个公司的生存都是首要的问题，选择什么样的技术栈取决于公司的商业模式、产品形态和当前（未来）面对的商业环境情况。现在国内几家大型的云计算平台都是选择 Golang 作为主力的开发语言，字节跳动内部后端服务在大量使用 Golang ，Docker / Kubernetes 也是用 Golang 开发的。我倒是不想分析选择 Golang 的具体原因，我只想说 Golang 作为一个编程语言被选择的时候也相当的 "小众不成熟" 。

这个成熟不成熟的直接表现是选择所带来的商业风险大小。如果为了商业利益选择风险大的技术也是正常的，黄东旭、刘奇当年选 Golang 和 Rust 都是风险很大，PingCAP 收益如何一目了然。敢不敢选小众不成熟的技术栈考研的是决策者的能力，能不能应对带来的风险，敢不敢追求更高的收益。所以如何选择是基于商业和产品逻辑来决定的，不应是一个团队的同学、或者团队管理者单方面决定。

写这篇公众号文章的时候，我正在 TuGraph 在北京 Meetup 现场，TuGraph 用 Rust 编写了一个图存储的引擎 CStore 。我相信选择 Rust 的公司会越来越多，这是一个非常有前景的语言，这也是我投入在 Rust 中国生态工作的原因和信念来源。