前言
Rust 1.0 发布刚刚一周年(2015.5~2016.5),这一年来 Rust 又取得了长足的进步。笔者尝试从多个方面总结过去一年来 Rust 领域的重要动作、进度和成就。本文内容丰富,信息量大,总结比较全面。读者从中可以看到:开发者的辛勤努力和 Rust 语言的快速成长,Dropbox 等公司在生产环境中的核心模块应用 Rust,社区成员积极参与社区活动,Rust 在国内的发展状况,等等。
Rust 语言 / 编译器 / 标准库升级
一些零散的升级,像添加 Stable API、局部提升性能、修改某些 BUG 等等,在这里就不提了。我将要说的,都是影响深远的重大升级。当然,还有很多工作未最终完成,要等以后的版本问世。但是前期的研究、讨论、设计等步骤基本走完,剩下的无非就是编码实现、实验性应用、标准化等步骤,只要没有意外,后面的一切都顺理成章。
本文多次提及的 RFCs ,后面将有专门章节介绍,此处不展开叙述。
impl specialization (RFC 1210)
这一特性类似 C++ 的模板特化和偏特化。允许为接口或类型定义多个可重叠的impl
实现,最终由编译器依据上下文自动选择其中一个最具体、最 specific(general 的对立面)的实现。它能帮助程序员更好的优化性能、重用代码,还为将来实现规划已久的"efficient inheritance"提供基础支持。
举个简单的例子。Rust 从1.0 开始就为 “实现了 Display
接口的任意类型 T”
实现了ToString
接口。这是一个泛型实现,涉及大量类型,覆盖面很广。从代码实现细节上看,用到格式化文本输出( fmt::Write::write_fmt )。
#[stable(feature = "rust1", since = "1.0.0")] impl<T: fmt::Display + ?Sized> ToString for T { #[inline] default fn to_string(&self) -> String { use core::fmt::Write; let mut buf = String::new(); let _ = buf.write_fmt(format_args!("{}", self)); buf.shrink_to_fit(); buf } }
具体到基础字符串类型str
,它当然也属于上面提及的 “实现了Display
接口的任意类型 T”,因而自动实现ToString
接口,拥有to_string
方法。然而上面的实现代码里的格式化输出功能对于 str 转换至 String 来说是多余的,带来额外的运行时开销,因而导致"str".to_string()
比"str".to_owned()
更慢这种很尴尬的局面,持续了一年多时间。
Rust 语言支持 impl specialization 特性之后,就可以在标准库里为str
类型添加一个更具体、更 specific 的 ToString 实现:
impl ToString for str { #[inline] fn to_string(&self) -> String { String::from(self) } }
impl specialization (RFC 1210) 设计稿自 2015 年 6 月推出第一版,至 2016 年 2 月,期间经过及其广泛而深入的高质量的公开的设计讨论,数易其稿,最终被正式批准采纳。2016 年3 月,该设计稿被部分实现。 impl ToString for str
已经成为现实。
foo?.bar()?
(RFC 243)
Rust 现有的错误处理机制( try! + Result )虽然还不错,但是使用有些繁琐,对链式调用不友好。try!
不是语言内置特性,而只是标准库里定义的一个很简单的宏。长期以来,Rust 开发者一直在寻找更好更简洁的错误处理机制,进行了许多探索和讨论。2014 年 9 月 RFC 243 被提出,2015 年 10 月经过重大设计改进,2016 年 2 月被正式采纳,3 月被初步实现,期间经过大量设计讨论。至今 foo?.bar()?
语法已经待在 nightly 版本里被内部测试三个月时间,如果不出意外估计不久就会进入 stable 版本跟大家正式见面。发布之前要做的其中一项工作将是把标准库里面的try!
全面切换到?
(已经有自动化工具 untry 可用)。这一特性毫无疑问将改变所有人编写代码的方式。
MIR (RFC 1211)
现在的 Rust 编译器,是从 2010 年开始开发的,是用 2010 年的 Rust 语言编写的。那个时候,Rust 的 0.1 版本都还没出娘胎呢。此后的 5 年时间里,Rust 语言在进化过程中不断地发生天翻地覆的变动。Rust 编译器正是在这样动荡的环境下逐步迭代完成开发。我们认为,Rust 编译器是由许多个不同版本的 Rust 语言写成的;甚至可以说,Rust 编译器是由许多不同的编程语言写成的(因为每个版本的变化都非常大)。结果就是,在编译器源代码的角落里,难免存在一些陈旧代码和历史遗留问题,并在一定程度上阻碍了编译器的维护和升级。
MIR 计划正是在这样的背景下诞生的。通过在编译器内部引入中层中间表示码(Mid-level Intermediate Representation,介于上层 HIR 和底层 LLVM IR 之间),对编译器代码进行大型重构、改造。这一基础性的改进,对编译器今后的维护、升级,具有深远的影响。许多新特性可在 MIR 的基础上更方便的实现。例如,增量编译、代码优化、更精确的类型检查等等( Non-zeroing drop , Non-lexical lifetimes ),都依赖于 MIR 计划的实施。开发者甚至在计划借助 MIR 直接生成WebAssembly 字节码并已着手行动(WebAssembly:JavaScript 垄断地位的终结者)。
2015 年 7、8 月份完成 MIR 的设计,此后很快进入长达十个月的编码实施阶段。任务量非常大,但进展有条不紊,Github 忠实记录了一切。到2016 年5 月份,MIR 代码生成工作基本完成,基于MIR 的进一步优化和应用,尚在进行中。
alloctors (RFC 1398 1183)
2014 年 4 月提出的 RFC PR 39 未获通过,同年 9 月的 RFC PR 224 也未获通过,直到 2015 年 12 月的 RFC 1398 终于有所斩获,在历经数十次修订后,于 2016 年 4 月修成正果,成为内存分配器标准接口的正式规范,为今后开发者自行实现各种类型的内存分配器扫清了障碍。其背后的动机是,系统默认提供的内存分配器(例如jemalloc)不可能适合所有应用场景,第三方内存分配器的引入是必要的。
从整个漫长过程我们看到设计的艰难、设计者的不懈努力,和坚持追求高质量设计的严肃态度。
于此同时,允许变更系统默认内存分配器的设计工作也被提上日程。 RFC 1183 在 2015 年 7 月推出设计稿,一个月后获得官方审核批准。8 月份修改编译器,完成编码工作,完整地实现了此 RFC。jemalloc 不再是强制使用的内存分配器,程序员有机会选择使用其他内存分配器作为默认内存分配器。这一功能已被内部测试了将近一年,预计不久之后将会正式发布。
编译错误提示
编译错误提示更加简洁和人性化。
以前:
(点击放大图像)
现在:
(点击放大图像)
2016 年 5 月初,此功能已经在 nightly 版本中实现。再经过一段时间的培育,确认其稳定工作之后,将会进入 stable 版本正式面世。(注,上面的附图是稍早的版本,后面又有所调整和改进。)
其他
- 增量编译( Incremental compilation ):2015 年 8 月至 11 月完成增量编译的设计文档( RFC 1298 )。相关编码实现工作缓慢进展,部分依赖于 MIR。
- Macro 2.0:新一代宏 2.0 的规划和设计取得较大进展, nrc 做了大量的前期研究工作,提出了设计稿 RFC PR 1566 。接下去的进展有待观察。
- impl Trait: 取得了许多探索和研究成果( 1 2 3 ), RFC PR 1522 得到了比较广泛的认同,很快会有下一步的动作。完成之后将改善“函数返回迭代器”的现状(struct 扎堆)。
- 单指令多数据( SIMD ): Rust 对 SIMD 硬件加速支持取得初步进展,huonw 做了大量前期工作,提出 RFC 1199 (2015 年 9 月获得批准),提交基础实现和扩展库。属于实验性支持阶段,已在 regex 库中得到应用(性能提升十分明显)。
Rust 周边开发工具升级
Cargo
- cargo install : 只需一个很简单的命令(
cargo install xxx
)就能编译安装可执行程序到本地.cargo/bin
目录(此目录一般都在 PATH 环境变量内)。设计和实现均已完成。像 clippy , rustfmt , cargo-edit 等都能通过它安装,十分方便。 - cargo workspace : 让 Rust 项目的源代码目录结构和布局更加灵活。设计完成但尚未实现(在本文创作后期已经实现)。
- cargo concurrently : 允许多个 Cargo 实例并发执行。已经初步完成。
- cargo namespacing : 官方开发者始终持有主动排斥的不作为态度,因而一年来没有任何进展。跟 Go 语言泛型面临的悲催处境惊人的相似。
clippy
clippy 得到了许多人发自内心的喜爱。它会分析审查你的源代码,并提出许多贴心的改进意见。它像良师益友,安静地坐在你身边,面对面指导你编写代码。经常使用它,有助于改善代码质量、提升开发者的编程经验和水平,无论新手老手都能从中受益。
Thanks rust-clippy . We do love the great project.
安装方法:cargo install clippy
;使用方法:cargo clippy
。
rustfmt
格式化 Rust 源代码的工具,已经基本成熟、稳定可用,许多官方库用它格式化代码。不过它存在的意义相比clippy 弱暴了。 rustfmt 只是辅助修整一些皮面而已,对语意几乎一窍不通,我想不通某些哥们经常对这类工具推崇备至。安装方法:cargo install rustfmt
;使用方法:cargo fmt
或rustfmt
。
rustup
Rust 安装和更新工具,可以方便的切换 stable 和 nightly 版本,可以下载和使用各种平台交叉编译工具链。前身是 Shell 脚本,现在已经是纯 Rust 开发 ( rustup.rs )。开发者首选的 Rust 安装方式。这里还要顺便提及 brson 为方便各操作系统打包 Rust 所付出的努力。
rustbuild
专为 Rust 编译器和标准库定制的基于 Cargo 的编译工具,用于取代之前基于 Makefile 的编译系统(已经过于庞大和复杂难以维护)。已经做了大量前期工作。
Editors & IDEs
各主流代码编辑器 /IDE 都对 Rust 提供或多或少的某种程度的支持。语法高亮着色、代码自动完成等基本功能都已实现。 RFC 1317 (讨论)还进行了深入的思考和规划,未来 Rust 编译器和其他工具将主动对 IDE 提供更友好的支持(但是目前还没有看到具体的动作)。
- Visual Studio Code (VSCode) + RustyCode
- Atom + Tokamak
- Sublime Text 3 + RustAutoComplete
- IntelliJ IDEA + intellij-rust
- Vim + rust.vim + YouCompleteMe
- Emacs + rust-mode
详情可参考 Are we IDE yet ,或参见 Reddit 网友讨论帖: Show me your programming environment 。官方网站也有总结。
以上几乎所有编辑器&IDE 及其插件的背后都离不开大功臣 Racer :Rust“代码提示 & 自动完成”工具。
我现在感觉用 VSCode v1.2 比较顺手,比 Atom v1.8 反应快还更稳定。作为通用的代码编辑器,我原本对 Atom 寄予厚望,但现在来看 VSCode 有后来居上的趋势。
Rust 第三方应用升级
Dropbox Magic-Pocket
2016 年 3 月份, Dropbox 公司脱离 Amazon 云存储平台的战略规划和实施细节浮出水面(低调做事之后高调发布,这风格我喜欢)。国际新闻报道标题是:“The Epic Story of Dropbox’s Exodus From the Amazon Cloud Empire”(英文讨论)。国内新闻报道标题是:“Dropbox 用 Rust 取代 Go 精简内存占用”(中文讨论)。Dropbox 这一计划的核心是自己开发云存储系统,并逐步过渡。一开始是用Golang 语言开发,后来上线后发现系统占用内存太厉害,于是改用Rust 语言开发该系统的核心模块 Magic Pocket 。对外报道时,新系统已经上线一段时间,运行状况良好。
Redox OS
Redox OS 是真撸啊。想搞另一个 Linux 出来。
用 Rust 语言开发的 Redox 操作系统,2015 年 9 月一经面世就拥有图形用户界面,现已实现文件系统(ZFS WIP)、网络系统、多线程、文本编辑器等等。微内核设计,硬件驱动运行在用户空间。兼容大多数Linux系统调用和常见的 Unix 命令。
它可在 Linux、Windows、OS X 上编译,可在真实硬件上 (Panasonic TOUGHBOOK CF-18、IBM Thinkpad T-420、ASUS eeePC 900) 启动并运行 GUI 应用和 Console 应用。一个团队还在不断的开发完善 Redox 系统。开发活跃,进展很快,文档较全。
个人或小团队开发出来的绝大多数所谓的操作系统,都是习作、玩具。那些借助 BootLoader 启动起来并在屏幕上输出文字的所谓内核,除了作为新手入门练习之外没有任何应用价值。Redox 显然不属于此类,Redox 有更高的追求。Redox 的作者也不是新手,而是资深的 OS 开发专家。
- Announce Redox
- Redox is Serious
- Redox vs Linux in 10 years
- Rust’s Redox OS could show Linux a few new tricks
Redox OS 固然牛逼,可它也不是一个人在战斗,用Rust 开发的操作系统有好几个呢。
TiKV 分布式存储引擎
PingCAP 公司推出的 TiDB 是开源的分布式数据库,参考 Google F1/Spanner 实现了水平伸缩,一致性的分布式事务,多副本同步复制等重要 NewSQL 特性。结合了 RDBMS 和 NoSQL 的优点,同时完全兼容 MySQL。前期用 Go 语言实现了 SQL Layer,后来 (2015 年底) 考虑到“Go 的 GC 和 Runtime 对底层存储非常不友好”,再加上对运行效率的极致要求,决定采用 Rust 语言开发 TiDB 的核心存储模块 TiKV 。2016 年 1 月份至今,TiKV 项目的开发十分活跃,至少有 4 位软件工程师全职参与开发。4 月份刚刚开源。
Diesel ORM
作者 Sean Griffin 是 Ruby Rails ActiveRecord 的现任活跃维护者,是ORM 领域的专家。他在2015 年9 月启动 Diesel 项目。来自 ActiveRecord 的优秀设计、经验和教训,有助于他设计实现这个全新的 ORM 项目。Diesel 项目的设计充分发挥 Rust 类型安全的优势,还特别注重性能和可扩展性,文档也不错。是颇受关注、值得期待的项目。
在生产环境中使用 Rust
Rust 官方网站专门有一个页面, Friends of Rust (2016 年 4 月底上线,持续更新),列出了在生产环境中使用 Rust 语言的组织和项目。
其中 MaidSafe 是有野心的项目,这一年来一直持续开发。 Servo 也是;而且会有越来越多的 Rust 开发的 Servo 组件迁入 Firefox 浏览器。
其他潜力股项目
- https://github.com/kbknapp/clap-rs
- https://github.com/sebcrozet/ncollide
- https://github.com/google/xi-editor
- https://github.com/nikomatsakis/lalrpop
I would like to nominate lalrpop . It’s an LR(1) parser generator, where the syntax is written using a nice, quite Rust like language, and it’s compiled into Rust code as a part of the build process. There’s also the option to use your own token type and tokenizer, which is very nice for more advanced projects. ( ogeon )
- https://github.com/tailhook/vagga
- https://github.com/das-labor/panopticon
- https://github.com/aturon/crossbeam
Libraries like crossbeam are probably more appropriate for the std. Lock-free containers(data structures). ( LilianMoraru )
Ok, if only 1 crate, I nominate rayon .
This crate is so good that I think that most applications should have a dependency on it.
Very easy to plug some concurrency into your application, and that it does very well. ( LilianMoraru )
I would like to nominate eventual . It’s a library that provides Future and Stream like abstractions and has a very easy to use interface. ( maximih )
注: xi-editor 项目虽然挂在 google 名下,却不是 Google 公司官方项目; hat-backup 项目的情况也类似。说明 Google 公司至少有两位作者在持续或深度使用 Rust 语言。以后在 Google 公司内部安利 Rust 就靠这哥俩了……
重量级 PR(Pull Request)
- Regex #164: Add a lazy DFA (性能颇具竞争力)
- Url #176: Version 1.0, rewrite the data structure and API
- Hyper #778: Async IO
- Mio #239: Preliminary Windows TCP/UDP support
- Redox #552: Big IO change
- Rust #32756: Overhaul borrowck error messages and compiler error formatting generally
- Gtk-rs #221: Object reform
Rust 社区生态系统升级
Crates.io 中心仓库持续发展
crates.io 下载量 Top 10
- libc 共 190 万次下载
- winapi 共 120 万次下载
- rustc-serialize 共 109 万次下载
- rand 共 101 万次下载
- winapi-build 共 99 万次下载
- bitflags 共 98 万次下载
- log 共 86 万次下载
- kernel32-sys 共 80 万次下载
- gcc 共 72 万次下载
- time 共 68 万次下载
说明它们处于依赖链的顶层或接近顶层,大量项目直接或间接地依赖之。任意项目每次全新的编译都可能增加其下载次数,自动化的集成测试也贡献了许多下载量。
通过 Cargo 和 crates.io 网站把大大小小的第三方库聚合在一起,形成健康的生态系统,让项目依赖管理变得对开发者透明。
线上线下同性交友网络蓬勃发展
Github 号称全球最大的线上同性交友网,名副其实。单单一个 Rust 仓库,就汇集了 5.3 万 commits,1.7 万 issues,1.6 万 PRs,1.6 万 stars,3 千 forks,1 千 contributors。还有 RFCs 仓库几百个精华的设计文档和精彩的讨论细节。
大概从 2015 年 8 月起,在 reddit.com/r/rust 论坛上,每周都会发布两个置顶的新帖:
- “兄弟们这周都忙啥了?”(“What’s everyone working on this week?”)后面的回复中网友纷纷踊跃发言说自己本周在用 Rust 写什么代码或做什么项目。
- “哥们有事您说话!”(“Hey Rustaceans! Got an easy question? Ask here!”)下面的回复有问有答,提出并解决各个技术问题。
这情景很和谐。真的就像一帮有情有义的光棍汉哥们围着电脑坐在一起认真的闲聊,聊工作,聊技术。虽然彼此之间隔着网络,心却是在一起的,相互有信任感和亲近感。
他们不把自己喜爱的语言当神供着,该吐槽的时候比谁都积极。在诸如 “Rust 哪些地方最垃圾” “为何不在工作中使用Rust” 这类问题下面你会看到几百条回复。
线上火热,线下也不闲着。2016 年1 月份,全球Rust 开发者共举办了13 次有据可查的同性聚会;2 月份15 次;3 月14 次,4 月份14 次;5 月份(刚过半)16 次。活该没有女朋友,哼! (此数据为粗略统计,截止到2016 年5 月中旬。)
以上数据部分来自 https://github.com/rust-lang/rust 和 https://this-week-in-rust.org/ 。
Rust 价值观输出升级
以下列举的情况,有些可以证实是 Rust 输出了价值观,有些则不能证实。然而即使不能证实,至少也说明对方持有和 Rust 相类似的价值观,这也是我们喜闻乐见的。
简短的类型名称被 WebAssembly 采纳
由 Mozilla, Microsoft, Google 等几大浏览器巨头联合发起的 WebAssembly 项目(JS 垄断地位的终结者),其 value types 从 2015 年 9 月开始直接使用跟 Rust 基本类型完全一致的命名:i32, i64, f32, f64。但变更记录并未提及是否借鉴于Rust。此前他们的value types 命名曾几经变更。或许只是一个巧合也未可知。
另外,WebAssembly 的 block 也是有值的,block 的值就是 block 内最后一条 expression 的值。同样跟 Rust 不谋而合。
动力火车版本发布机制被 Github Atom 和 Ethcore Parity 采纳
Rust 的 Release channels 机制原本是借鉴于 Chrome,进而又影响了 Github Atom 和 Ethcore Parity 项目。Atom 和 Parity 均声明受 Rust 影响而采用此发布机制。
这一机制可以表述为三列火车(nightly, beta, stable)在各自轨道上并驾齐驱。nightly 火车,每天都往上装货(commit code),内容是最新的,但是可能不太稳定;beta 火车,每隔 6 周从 nightly 火车上卸下一部分经过时间沉淀的货物装到自己车上(merge code),内容比较新,稳定性比较好;stable 火车,每隔 6 周从 beta 火车上卸下一部分经过时间沉淀的货物,经过列车长人工过滤,确认检验无误之后装到自己车上,测试时间最长,测试最完整,稳定性最好,内容相对滞后。一个新特性从提交代码进入仓库到进入 Stable 版本,至少要经历 nightly->beta、beta->stable 两个周期,约 3 个月时间,才能跟最终用户相见;期间经历各种测试,一旦发现问题就会延迟进入 Stable 版本。但无论如何,最终用户总会每 6 周得到一次 Stable 版本升级。
Atom 提供的这幅图十分形象的揭示了这一机制工作原理。
(点击放大图像)
这种机制的好处是,在保证产品稳定性的前提下提供较频繁且平滑的升级体验。让用户没有心理负担地升级,乐于使用最新稳定版本,而不是像Java 那样总想着憋N 年搞一个大新闻出来,反而让某些用户有升级恐惧症。喜欢尝鲜的Rust 用户,可以选用每日更新的nightly 版本(或beta 版本)。两边都不耽误。
RFCs
Rust 早在 2014 年就开始逐步实施 RFC 机制。要求对代码做出重大改动或提议增加重要特性之前,发起者需要首先写出设计文档(即所谓“请求讨论稿” - Request For Comments),经过公开讨论逐步修正完善,并得到核心专家组批准之后,才能进入下一步编写代码实现功能阶段,最后还有一个标准化步骤,直至进入正式发行版 (stable)。
这一机制的好处是:
- 强调设计在编码之前
- 强调公开的设计、公开的讨论、广泛地征求意见
- 强调核心专家组对设计方向和质量的把控
- 有利于积累专业的技术设计文档
- 避免某些模块的设计仅有个别人理解
- 提高代码的可审查性和可维护性
- 保证项目的高质量和发展方向
- 配合 Feature-gate 确保实验性项目在实验期间不流出实验室
这对开源软件的健康发展是至关重要的。别的项目也开始认可这一点,并参考实施,例如:
- https://github.com/emberjs/rfcs
- https://github.com/maidsafe/rfcs
- https://github.com/intermezzOS/rfcs
- https://github.com/rebuild-lang/rfcs
- https://github.com/fsharp/FSharpLangDesign
注:目前不能证实微软 F#项目的 RFC 机制源于 Rust。运作机制虽有所不同,但设计在前、公开讨论、官方审核等核心内容是一致的;RFC 文本结构相似度很高。多讲一句,说起来 F#和 Rust 还是亲戚呢,语言设计层面都跟 OCaml 语言有很深的渊源,Rust 最初版本的编译器还是用 OCaml 开发的(当然现在早就换成 Rust 开发了)。
本周更新公告 (This Week In XX)
“ This Week In Rust ”每周推出一期,总结介绍上一周 Rust 发生的重要事件,如功能增加或变动,新的设计文档 (RFC) 得到批准,谁发表了重要文章,谁举行了聚会等等。从 2013 年 6 月 Rust 推出第一期“This Week In Rust”开始,三年来共发布 130 期(其中在 1.0 之后发布约 50 期)。可以当作新闻报纸摘要来读,用户花少量的时间就能了解 Rust 重要开发动态。
后来有些项目开始学习这种公告形式:
- This week in Servo
- This week in Redox
- This week in Ruma
- This week in Rust Docs
- This week in intermezzOS
- This week in TiDB
- This week in Parity
这种事情最难得的就是持之以恒。Rust 出到第 130 期了,Servo 出到第 62 期了,Redox 出到第 14 期了,加油吧。(注:因本文创作时间跨度较大,以上数据可能稍有过时。)
别的项目没有(各种形式的)每周(或每月)更新公告,其中一个理由可以理解为:开发活跃度低,每周更新的内容少,不好意思写出来;或者被关注度低,写出来也没多少人看,所以干脆不写了;再或者开发透明度低,不能写出来给人看。(唉,人艰不拆,说出实话就要得罪人!)
支援兄弟语言项目
本着共建和谐开源大家庭原则,Rust 社区充分发扬共产主义精神,积极参与其他社区活动,为各兄弟语言项目送温暖、献爱心,共享发展理念,致力于实现共同富裕。Rust 在安全和性能方面优势非常突出,尤其适合为其他语言编写 Native 扩展库。下面提到的项目多是名家作品。
Lua
有过 Lua 本地模块开发经历( htmlua iedom )的我,第一次看到 hlua 就有眼前一亮的感觉,眼珠子都快掉下来了,惊叹居然可以这样写 Lua 的本地扩展模块,完全突破了 Lua C API 的死板接口:
#![feature(phase)] #[!plugin(rust-hl-lua-modules)] #[export_lua_module] pub mod mylib { // <-- must be the name of the Lua module static PI: f32 = 3.141592; fn function1(a: int, b: int) -> int { a + b } fn function2(a: int) -> int { a + 5 } #[lua_module_init] fn init() { println!("module initialized!") } }
hlua 的作者是何方大神?这里先卖个关子。后面他还会出现。
Ruby
借助 helix 项目,让 Rust 语言编写 Ruby 本地库变得很简单, 消除了大量胶水代码。
declare_types! { class Console { def log(self, string: &str) { println!("LOG: {}", string); } } }
$ irb >> require "console/native" >> Console.new.log("I'm in your rust") LOG: I'm in your Rust
Helix 的作者是 Rust 核心开发者 Yehuda Katz 和 Ruby on Rails 核心开发者 Godfrey Chan 。这个阵容够强大吧?
Node.js
通过 neon 项目,用 Rust 语言编写 Node.js 本地扩展包,既简化了代码编写,又简化了编译过程。看看它的 demo ,让人印象深刻:静态编译 + 并发计算,性能远超 JavaScript,强到没朋友。简单贴一段代码:
fn search(call: Call) -> JsResult<JsInteger> { let scope = call.scope; let buffer: Handle<JsBuffer> = try!(try!(call.arguments.require(scope, 0)).check::<JsBuffer>()); let string: Handle<JsString> = try!(try!(call.arguments.require(scope, 1)).check::<JsString>()); let search = &string.data()[..]; let total = vm::lock(buffer, |data| { let corpus = data.as_str().unwrap(); wc_parallel(&lines(corpus), search) }); Ok(JsInteger::new(scope, total)) } {1} register_module!(m, { m.export("search", search) }); {1}
Neno 的核心开发者 Dave Herman ,是 Mozilla 公司员工,ASM.js 的作者,牛逼的不要不要的。
Golang
通过 rure 项目,Rust 给 Go 语言送去性能更强的正则表达式库,让Go 社区的同学们提前用上高大上的 lazy DFA 特性。
Rure 的作者 Andrew Gallant ,是 Rust 开发组成员,Rust Regex 和 Docopt 库的主要作者。
Python
rust-cpython 使得采用 Rust 语言编写 Python 扩展库和调用 Python 代码成为现实。
#![crate_type = "dylib"] #[macro_use] extern crate cpython; use cpython::{Python, PyResult, PyObject}; py_module_initializer!(example, initexample, PyInit_example, |py, m| { try!(m.add(py, "__doc__", "Module documentation string")); try!(m.add(py, "run", py_fn!(py, run()))); Ok(()) }); fn run(py: Python) -> PyResult<PyObject> { println!("Rust says: Hello Python!"); Ok(py.None()) }
Erlang and Elixir
Rustler 使得 Rust 可以轻松编写 Erlang NIF(本地实现函数库)。
#![feature(plugin)] #![plugin(rustler_codegen)] #[macro_use] extern crate rustler; use rustler::{ NifEnv, NifTerm, NifResult, NifEncoder }; rustler_export_nifs!( "Elixir.TestNifModule", [("add", 2, add)], None ); fn add<'a>(env: &'a NifEnv, args: &Vec<NifTerm>) -> NifResult<NifTerm<'a>> { let num1: i64 = try!(args[0].decode()); let num2: i64 = try!(args[1].decode()); Ok((num1 + num2).encode(env)) }
C and others
C 同学也未被遗忘,Rust 双手奉上 Regex C API ,并希望 C 同学向各编程语言转达来自 Rust 语言的问候。Servo 也有提供 C API 。
Rust 语言内置支持与 C 语言的互相调用( FFI )。其他语言以 C 为中介可间接地实现与 Rust 交互。对于 Rust 调用 C 库的情况, rust-bindgen 很给力,可自动生成 Rust 端调用接口。新特性 cdylib 使得 Rust 编译出的 DLL/SO 文件尺寸更加小巧,更方便被其他语言嵌入、调用。Rust 当然也支持引入和输出静态库 lib 文件。
Vulkan
Vulkan 规范今年 2 月份刚发布,Rust 迅速跟进,很快就有了安全而高效的 vulkano 第三方封装库。
vulkano 的作者 tomaka ,同时也是大名鼎鼎的 glium 和前面提到的 hlua 的作者。
最受群众喜爱的编程语言
在国际知名网站 StackOverlow 主办的 2016 年开发者调查报告中,Rust 荣获最受群众喜爱的编程语言大奖。群众的眼光是雪亮的。
Rust 在国内的发展情况
- QQ 和 微信 群 / 讨论区 Rust 中文社区
- 国内多位开发者合力完成的原创性 Rust 教材 Rust Primer (诞生记)
- 国内开发者 Elton 主导并持续开发的协程项目 coio-rs
- 2015 年 6 月起,号称全球最大 IT 社区的 CSDN 网站先后多次专访国内活跃 Rust 开发者(庄晓立(Liigo) 钟宇腾(Elton/tonytoo) 唐刚(daogangtang) 王川(Fantix) 冯耀明(loveisasea) ),并推出 Rust 学习路线和 Rust 知识库,持续关注和推动 Rust 发展。
- 2016 年 3 月,PingCAP 首席架构师唐刘发表 Rust 语言入门、关键技术与实战经验(今日头条链接)
- 2016 年 4 月,本文作者庄晓立 (Liigo) 在 QCon 北京 2016|全球软件开发大会 上做专题演讲 《 Rust 编程语言的核心优势和核心竞争力》(演讲稿 PDF )。这应该是 Rust 语言第一次正式出现在国内顶级软件大会现场。
- 上文提到的 TiKV 开源项目的开发商 PingCAP 是中国公司,总部在北京市海淀区。是目前唯一一家出现在 Rust 官网 Friends of Rust 页面的国内公司。
- pencil 的作者是北京人, sapper 的作者是四川人。
- 2016 年 5 月,在北京和成都举办了庆祝 Rust 1.0 发布一周年的线下同性聚会活动。
后语
Rust 语言还是成长中的孩子。它有已经成熟的一面,且持续保持稳定,经历过至少一年的时间考验,证明它初步拥有独当一面的能力。它还有欠缺的一面,许多地方有待完善和拓展,它正视自身存在的问题,从多方面努力争取拿出最好的解决方案。过去一年的主题可以总结为:巩固已经稳定成熟的领域,发展全新的领域或有欠缺的领域。Rust 开发者们卓有成效的工作,使得 Rust 取得了可喜的进步,让我们对 Rust 的未来充满信心。Rust 社区高度活跃的现状昭示着我们不是一个人在战斗。Dropbox 等公司的加入使得队伍不断扩大。继续努力吧,务实的 Rust 编程语言,我们期待下一年取得更大的进展。
参考:
- https://www.rust-lang.org/
- https://github.com/rust-lang/rust
- https://github.com/rust-lang/rfcs
- https://www.reddit.com/r/rust
- https://this-week-in-rust.org/
- https://internals.rust-lang.org/
- https://news.ycombinator.com/
感谢郭蕾对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们。
评论