Rust 与 Web 后端的适用边界

前一段时间 Westar 的 Rust meetup 里，有个议题专门介绍当前 Rust 的各种 Web 框架。看下来我的感觉还是一样：Rust 当然很强，但它并不是大多数 Web 开发场景里的最优先语言，除非你的主要目标是技术栈统一，或者只是给一个非 Web 项目顺手暴露一个 HTTP 接口。

有人会问，既然 Rust 的目标是解决并发安全的问题，并且 Web 也属于高并发要求的应用，那为什么 Rust 在这个领域没发挥出来呢？实际上 Web 的并发安全难题主要是通过状态的外部存储来解决的。大多数 Web 程序本身都是无状态的，接收请求后，通过缓存或者数据库读写数据，然后返回出去，至于状态会不会冲突，这个由数据库来解决。如果需要维护状态，也仅仅是连接池之类的，或者很少的一些静态变量。再或者像 PHP 这样的，连接池都不需要，可以理解成整个应用的生命周期都和 request 一致，执行完成后销毁掉资源，也不存在内存泄露啥的。但在 Rust 里，这些生命周期的问题需要在编译阶段解决，新手写 Rust Web，Hello world 几分钟就搞定了，觉得很简单，但让输出个全局计数器，就蒙了。

有人还会问，那 Web 服务如果长期运行，用 Rust 能不能一定程度避免内存泄露？这个当然有帮助。

但现实问题是，一个互联网服务如果不能频繁上线、快速重启，它往往也称不上真正的持续交付系统。很多疑难的内存问题，甚至还没来得及暴露，就已经被日常重启策略顺手消掉了。有些团队干脆还会安排夜深人静的时候自动重启服务，避免周末没人值守时出问题。

所以我对这个问题的判断一直是：Rust 在 Web 领域不是没有价值，而是它最核心的价值，恰好不一定落在大多数 Web 团队当前最痛的点上。

原微博中的媒体