想开始往生产环境里面上一点儿 Rust,组里面也同意了。(虽然还是实验性的,先搞一些不太重要的、容易做的部分,换成 Rust,但还是想着要做的话,不论做什么,做出来的都要尽量比原来的更可靠、能真的长期替换掉原来的)
实践中还是遇到了不少问题,最难受的还是 stable/nightly 的问题:
我们是确定了:只能使用 stable 版本的编译器,可以追最新编译器,但不能上 beta/nightly 。
但 crates.io 里面还是有不少 crate 是或直接或间接地要求 nightly 版的。(我也得承认现在的能用 stable 编译的 crat 比几年前是多了不少)
很多 nightly 的 crate 都是依赖一些新的特性吧。但某些功能,似乎 stable 也能做,只是 stable 做起来可能没 nightly 里面那么“优雅”,或者说性能不如 nightly 。但又不大好找替代的 crate 。(就是说,即使找了一个替代的,如果哪天那个 nightly 的稳定了,想切回来,成本就不低了)
而另一些 nightly crate 用到的,是一些 stable 遥遥无期的特性。比如一些密码学库、计算库的llvm_asm!
、asm!
,stable 编译器用户完全感觉看不到希望。
合着,说来说去,生产环境还是不配用 Rust 嘛。
没有人在生产环境上用 Rust,那么 Rust 岂不是只能在个人作品里面小打小闹?
难道推广 Rust,社区就这么干指望着微软 /亚马逊这些大厂来帮你搞搞?
个人认为,既然 Rust 官方都区分 stable 版和 nightly 版,crate 的开发者也应该意识到 stable 版的重要性,而不是一味地鼓动其它开发者往 nightly 版里走。Rust 生产力的未来,应该在 stable 版里面。
1
JohnSmith 2021-03-14 11:10:18 +08:00 via iPhone
可以把 nightly 当 stable 用
|
3
libook 2021-03-16 10:45:19 +08:00
人们习惯上认为 nightly 适合测试尝鲜、stable 适合生产,但其实不同的项目会因为流程、质控等差异而体现出不同的稳定性。
Rust 设计哲学之一就是可靠,所以用 Rust 写的程序可能不需要花多大功夫就能天生比 C/C++可靠很多。 另一方面生产肯定还要结合合理的开发管理制度、流程以及严格的测试来确保最终交付的质量符合预期。 任何技术选型都是要评定风险的,所以建议跟社区实际了解 Rust 的 nightly 版本的可靠性表现,然后作为风险因素来权衡选型;比如生产项目对可靠性要求极高,而 Rust 本身语言带来的可靠性综合 nightly 版本带来的不可靠性是项目可接受的,那么就用 nightly,否则就用 stable 或者其他技术选型。 |
4
hydra35 2021-06-28 11:21:25 +08:00
rust 的周边感觉不是很严谨,但和语言以及语言自带的 toolchain 没关系
|