【译】谈谈2019年的RUST和WebAssembly

原文：Rust and WebAssembly in 2019 作者：Nick Fitzgerald 日期：2018.12.14

将 Rust 编译到 WebAssembly 对 Web 来说是快速、可靠的最佳选择。另外，Rust 与本地 C 语言调用约定和库集成的方式相似，Rust 还应该与 Web 的 JavaScript 和 HTML5 集成。这就是 Rust 和 WebAssembly 工作组的价值。

在2018 年，我们让 JavaScript 替换为 Rust 编译的 WebAssembly成为了可能。因此，我建议 2019 年应该更大规模地使用 Rust 和 WebAssembly。

#RustWasm2019: 为了给这些博客提供内容， Rust 和 WebAssembly 工作组目前正在为 2019 年的路线图征求建议。我们鼓励大家参与讨论发出你的声音!

水涨船高

我们应该构建一个松耦合的工具包，使 Rust 和 WebAssembly 的开发是实用。无论你是小心翼翼地将一个小型 wasm 模块插入到现有的 JavaScript 系统中、还是构建大型的 wasm 嵌入Web ，这个工具包都应使保证你的效率。

人们使用高级的库和框架而不是直接使用 Web API，因为他们想要有更好表达的抽象的方法。例如:

• 我更喜欢描述DOM的就像它看起来那样，而不是去描述修改列表，将其当前状态转换成我需要的状态。
• 我更喜欢 Rust 的类型，而不是序列化 HTTP 响应中的原始字节，或者Index DB 中的对象。

为了能达到抽象级别，我们将会用到需要一组有不同功能的库来实现 Web 的各种功能:

• 网络、fetch 和 WebSocket
• 表单和<input>
• 定时器和setTimeout
• Web GL 和 Web 音频
• 持久化 Indexed DB
• 一个基于console.log 的后端，用 env_logger 和 Rust 日志实现
• URL 路由和window.history
• 自定义组件 Web components
• ...

在2018 年我们通过 wasm-bindgen、js-sys 和 Web-sy 直接访问底层 JavaScript 和 Web API 已经让这一切变成了可能，但这等于直接面向 libc 编程。到了2019 年，我们应该创建更高级别的抽象，以封装后的底层 API，从而获得更好更实用的开发体验。Green-field Rust 和 WebAssembly 应用将会把整个工具包连接在一起，然后再封装出单个的接口。一点点的选择相关的库把小型的有针对性的 wasm 模块集成到现有 JavaScript 应用程序中。

我们应该一起构建这些更高级别的库和工具包，把它们连接在一起。这个工具包的构建将反映我们工作组的价值:

• 快速: 让我们向大家展示Web可以达到的速度 ;-) 从零成本抽象开始。不会让你享受快乐的同时也不会放弃性能。
• 可靠: 我喜欢 Rust 社区的一个原因是大家都严于律己，追求卓越。我们应该利用 Rust 的类型系统来检查代码正确行，使用quick check编写基于属性的测试代码，并在无头浏览器中运行全面的自动化测试。我们打算构建一个坚实的基础，找不到质疑其它的完整性的理由。
• 与 JavaScript 和 Web 的集成:我们必须支持 Rust 和 WebAssembly 的增量应用，毕竟重写代码是不现实的。还有很多JavaScript代码用Rust重写是没有意义的，因为它已经很不错了。

除了支持我们的核心价值外，我们的工具包还应:

• 模块化: 能从工具包中分离出单独的模块。我们不想建立一个围起来的大观园！我们的目标是扩大共享、兼容性和改进，努力减少 Rust 和 WebAssembly 中的重复工作。
• 人类工程学: Rust 的抽象不仅成本低，而且富有表现力! 我们应该利用这一点来构建出快乐的的 API。glium create 是一个很好的例子。

上述一些 Web API 已封装在已存在的高级别 API 中。然而，很少有现成的 crates 能完全满足我们的需求。最常见的情况就是缺乏模块化。因此我们应该合作改进现有的 crates，把它们拆分成小型的单一原则的库，那样才会有意义。

最后，开发松耦合工具包的灵感来自 Rust 网络工作组的 Tide 项目和 Choo JavaScript 项目。谢谢！

工具

现在，wasm-pack 能帮助你完成构建和测试工作，通过生成一个package.json 文件来帮助你实现和 JavaScript 工具集成。它将发布你用 Rust 生成的 WebAssembly 包到 NPM，使分发变得容易。

但是有几件在 2018 年没有完成的事情仍然没有得到处理:

• 集成和自动执行二进制项目的 wasm-opt 工具。
• 支持生成能在 Web 和 Node.js 中运行的 NPM 包。
• 允许 crate X 在package.json 声明 NPM 包的依赖关系， wasm-pack 为 crate X提供它的依赖 crate Y。
• 将本地资源(特别是 JavaScript 代码)打包进 wasm-pack 生成的 NPM 包中。

我觉得最后两点对于构建我们的工具包是很有必要的。我们应该完成这些任务，并把 wasm-pack打磨成1.0工具。在这之后，我们应该让经验和需求来指导我们的努力方向。

关于工具的最后一点说明:Internet Explorer 11 是最后一个拥有一定市场份额却不支持 wasm 的浏览器。也许通过 wasm2js 工具将wasm 编译为 JavaScript可以支持 IE11。但 wasm2js 仍然缺少一些核心功能，实现 Rust 和 wasm 应用在IE 11 中任重道远。

多线程

我们必须把 Rust 并发 fearless concurrency 带到Web中! 在各种能在Web中共享内存的语言(C、C# 和 Rust)中，只有 Rust 可以安全地执行此操作。多线程所需的 Web API 将很快在浏览器中默认启用。我们应该准备好了。

然而由于是 Web 平台提供的原生 API，我们不能只是让 std:: 线程在 wasm 中透明地工作。即使在 worker 线程中，我们也不能无限地阻塞事件循环，并且我们需要更改全局变量给主线程上锁和解锁。有关详细信息请阅读 Alex 的 Multithreading Rust and WebAssembly。

因此，我认为多线程的优点在于它可以为整个 wasm 生态系统创建一个可共享的线程池库，然后在它之上构建通道和其他抽象。我们的线程池还应该得到 wasm 线程和 crates 的支持。这实际上与库和工具包工作没有区别，但由于它的规模、独特性以及在 Web 上多线程带来多大巨大变化还是值得研究的。

#RustWasm2019

在我看来2019年对于Rust和WebAssembly是一个非常光明的未来。