Linux.中国 - 开源社区

 找回密码
 骑士注册

QQ登录

微博登录


为什么我说 Rust 是靠谱的编程语言

2015-5-19 10:19       

7. 十分重视并认真对待1.0版本

Rust 1.0被开发者视为第一个稳定可靠的可用于生产环境的版本。也就是要承诺:现有的大部分语言特性和标准库API要稳定下来,以后不能轻易改变,非得要变得话也得保持向后兼容;功能上要基本全面,至少要满足基本的软件开发需求,不能有明显的欠缺;质量上要有可靠性保证,不能动不动就这里有问题那里有问题。此外,还要给语言将来的发展留足余地。官方博客Road to Rust 1.0 对于 1.0 有详细的阐述。

任何认真的新编程语言面临“何时发布1.0版”这个问题时都会感到纠结。发布的越早吧,初级产品没经过多少实际检验,用户量一上来用的人多了,很可能爆出基础设计缺陷,不得已大幅翻修,导致口碑不佳,然后无人问津,项目就算失败了;发布的越晚吧,影响力小用户量一直上不去,也得不到太多实际检验,始终达不到1.0的水平,可能就一直默默无闻下去了。Rust在1.0发布时机上把握的还算比较到位:诞生快十年,高速发展三五年,吸引了一大批用户,自身也经过的“两个半”大型项目的实际检验。要说早,肯定是不早了。Rust没有盲目的早早发布1.0(例如在2012年),是因为他们对1.0期待很高,他们对自己要求很高,他们心里有一杆秤。因为他们是认真的。

为了在2015年5月保质保量发布Rust 1.0,他们提前做了哪些工作?

7.1. 标准库API的稳定性

Rust为标准库内所有API,即所有fn、所有type(struct/enum/trait)、所有method、所有impl、所有const/static、所有macro_rules!,都逐一标注了稳定性标签:stable、unstable或deprecated。并且声明,1.0版本内包含的所有stable API,都将在SemVer 2.0规范下得到向后兼容性保证,今后所有1.x版本都不会破坏其稳定性(除非遇到重大BUG不得已而为之)。

我们去查Rust开发组公开的会议记录,会发现在2014年6月23日到10月1日,共有8次API review专题会议(012345 67),逐一审查确定各API的稳定性标签。此后更长的时间里,又不定期的将更多API标注为stable或unstable/deprecated,在rust repo里搜索"stabilize" 可以得到大批提交记录,显示出这项系统工程显然不是一朝一夕所能完成的。

目前标准库名下stable API大约有2500条,占总数的80%。新生编程语言中能做到这个程度的,很少见。

7.2. 精益求精的API设计

7.3. 精益求精的类型系统设计

7.4. 精益求精的文档和代码复审

  • "Guide: Hello Cargo"经过仔细review: PR #15183

  • "Guide: Strings"经过仔细review: PR #15593

  • "Guide: Pointers"经过仔细review: PR #15789

  • "Guide: macros and unsafe"经过仔细review: PR #16331

  • "A 30-minute Introduction to Rust"经过仔细review: PR #16641

  • "Rust book: guessing game"经过仔细review: PR #25080

  • "Rust book: stack and heap"经过仔细review: PR #25292

  • "Rust book: dining philosophers"经过仔细review: PR #25321

  • "Rust book: concurrency"经过仔细review: PR #21152

  • "cross-compiling for iOS"经过仔细review: PR #14751

  • "regex crate"经过仔细review: PR #13700

  • "flexible target specification"经过仔细review: PR #16156

  • "RingBuf"经过仔细review: PR #18747 PR #19569

  • "HashMap"经过仔细review: PR #16628 PR #19946

  • "Rustdoc: sidebar tooltips"经过仔细review: PR #20021

  • "Rewrite associated types"经过仔细review: PR #20307

  • "new std::path"经过仔细review: PR #21759

  • "String patterns"经过仔细review: PR #22466

  • "primitives inherent methods"经过仔细review: PR #23104

  • "floating-to-decimal formatting"经过仔细review: PR #24612

  • "Vec::drain"经过仔细review: PR #24781

  • "Redesign Duration"经过仔细review: PR #24920

7.5. 1.0之后的开发计划

1.0是起点而不是终点,1.0之后Rust还将持续不断地开发新的语言特性,打造更完善的标准库。

核心开发者Niko Matsakis在今年4月份发表 Priorities after 1.0 一文,详细阐述了1.0之后的开发任务、计划、优先级,内容很多却安排有序,体现了他们对这些问题的深度思考。此文在开发者社区中引起强烈反响,获得热烈讨论。Niko还发表了系列博客文章的第一篇"Virtual Structs Part 1: Where Rust’s Enum Shines"

8. 精心设计的规范透明的开发流程

在2014年3月之前,Rust开发组并没有十分规范的开发流程,基本过程是这样:修改代码,提交PR,Review,Merger。这样导致的问题是,没有形成设计文档,一旦遇到较大规模的代码改动,别人想理解他的设计思路,首先要读懂他的代码,这给方案评估、代码评审制造了困难,而且容易形成无人理解或难于维护的代码。

从2014年3月开始,Rust引入了规范化的RFC流程。规定,对语言重大改动之前,需先提交RFC文档,写明包括意图、详细设计、优缺点等在内的完整技术方案,供社区集体讨论,最后提交到Rust核心开发组每周的专题会议上评估审核,获得批准之后才进入实施阶段(代码实现)。规范化RFC的好处是,首先形成了完整的技术文档,利于集体讨论、评估(进而优化方案),利于方案实施、后期维护,而且利于核心开发组主导项目进展方向。RFC流程实施一年来,在Rust发展过程中发挥了极其深远的作用,先后通过了一大批十分重要的RFC,有力地推动了Rust语言的革新。

举一个例子,说明社区会主动监督开发流程的规范性和透明度:2014年8月,官方人员aturon居然想偷偷摸摸地把unwrap方法改名为assert, PR #16436: API conventions cleanup(80+),被网友 发现(120+) 后引起极大争议。争议的起因是他们工作透明度不够,事先 公示(50+) 范围不足,未得到充分讨论。最终这一改动被迫撤消。

查看其它分页:

发表评论


最新评论

我也要发表评论

返回顶部

分享到微信朋友圈

打开微信,点击底部的“发现”,
使用“扫一扫”将网页分享至朋友圈。