Rust语言 - Rust值得吗？

一只不确定的螃蟹

Rust 值得吗？

从 JavaScript 到 Rust，三年过去了。

几年前，我放下一切，百分之百专注于 WebAssembly。当时，Rust 拥有编译 WebAssembly 最好的支持，而最全面的 WebAssembly 运行时都是基于 Rust 的。Rust 是菜单上最好的选择。我迫不及待地想看看所有的热议究竟是什么。

从那时起，我（和一些其他优秀的人）创建了 Wick，这是一个将 WebAssembly 作为核心模块系统的应用框架和运行时。

Wick 是我们 Rust 实验的主要目标

经过三年、多次生产部署、一部 电子书，以及大约 100 个在 crates.io 上发布的包，我觉得是时候分享对 Rust 的一些看法了。

好的方面

你可以用更少的工作维护更多

我非常支持测试驱动开发。我习惯了在 Java 和 JavaScript 等语言中进行测试。我开始像在其他语言中一样在 Rust 中编写测试，但发现我写的测试是 无法失败 的。一旦你的测试可以运行——也就是说，你的 Rust 代码编译成功——Rust 已经考虑了很多错误，以至于许多常见的测试用例变得无关紧要。如果你避免使用 unsafe {} 块和容易引发 panic 的方法如 .unwrap()，你就开始以一个默认规避许多问题的基础。

Rust 的借用检查器的严格性、Rust 类型系统的丰富性、函数式模式和库的存在，以及没有“空”值，这一切都使得在测试等工作中维持更多的内容变得更加省力。我在 Wick 项目中维护的 70,000 多行代码所需的测试数量远远少于我在其他语言中需要的数量。

当你需要写测试时，随时添加测试没有问题。Rust 的集成测试工具让你可以在代码旁边轻松添加测试，几乎不需要思考。

我在其他语言中的编码更好了

用 Rust 编程就像处在一段情感虐待的关系中。Rust 每天都会对你吼叫，常常是关于在另一个生活中你认为完全正常的事情。最终，你会习惯这种耍脾气的方式。它变成了常态。你学会了走钢丝，以避免激怒编译器的脾气。就像在现实生活中，那些行为的改变会永远留在你身上。

情感虐待通常不被认为是一种 健康 的鼓励改变的方式，但它确实会引起变化。

当行数混乱或返回值没有检查时，我无法在其他语言中编写代码而不感到不适。此外，当我遇到运行时错误时，也会变得非理性地生气。

你是说“ done 不是一个函数？为什么不给我说说“ done 可能不是一个函数？

Clippy 很棒！

Clippy 是 Rust 的代码检查工具，但称其为代码检查工具是不够的。在一个可以让你哭泣的语言中，Clippy 更像是一个温柔的朋友，而不是简单的代码检查工具。

Rust 标准库是 巨大的。当功能分散在数不胜数的细粒度类型、特征、宏和函数中时，很难找到你知道存在的函数。许多 Clippy 规则（例如，manual_is_ascii_check）查找可以更好地由 stdlib 方法或类型替代的常见模式。

Clippy 有 数百条规则，解决性能、可读性和不必要的间接化问题。它将在可能的情况下频繁给你替换代码。

看起来（很快）你将 终于 能够为项目配置全局代码检查。直到现在，你必须黑客解决方案以保持项目中的一贯检查。在 Wick 中，我们使用一个脚本自动更新 内联代码检查配置，以适应数十个 crate。Rust 社区花了 多年 才找到这样的解决方案，这引出了……

坏的方面

有些空缺你必须学会接受

每次我重新审视上面 Clippy 的问题时，我都在怀疑自己的理智。肯定是我错了。一定是我错过了某个配置。我无法相信这一点。至今仍无法。一定 有办法能够全局配置检查。我 四次 - 检查 当 我 写 这个 时 确保我没有错乱。这些问题现在都关闭了，但它们已开放多年。

Clippy 很棒，但这个使用案例只是 Rust 世界许多的一个例子。我经常碰到库或工具，我的使用案例没有被覆盖。这在较新的语言或项目中并不罕见。软件需要时间（使用）来成熟。但 Rust 并不 那么 新。Rust 有些地方给人不同的感觉。

在开源中，边缘案例通常由早期采用者和新用户处理。他们是有边缘案例的人。它们的 PR 精炼了项目，使其对下一个用户更好。Rust 被评选为“最受欢迎的语言”已经十多年了。它在吸引新用户方面毫无问题，但并没有导致库或工具的显著改善。结果是处理特定用例的一次性分支。我也对此感到内疚，但并不是因为缺乏试图进行 PR 的努力。

我不知道为什么。也许是维持稳定的 API 的压力，加上 Rust 的细粒度类型系统，使库所有者难以迭代。如果结果是大版本提升，即便是小的更改也很难被接受。

或者，也许是因为编写适用于所有人的 Rust 代码极为困难，没人愿意应对这一点。

Cargo、crates.io 和如何结构项目

我根据我看到的其他一些流行项目对 Wick 仓库结构进行了建模。看起来合理，并且在它无法正常工作之前运行得很好。

你可以利用 Cargo 容易地构建、测试和使用感觉像模块大小的 crate，但将其部署到 crates.io 呢？那是完全不同的故事。

除非 每个 被引用的 crate 都单独发布，否则你无法将包发布到 crates.io。这是有一定道理的。你不想依赖一个依赖于仅存在于作者本地文件系统中的包的 crate。

然而，许多开发人员自然会将大型项目分解成更小的模块，你无法发布有子 crate 的父 crate，这些子 crate 只存在于它内部。你甚至无法发布带有本地开发依赖项的 crate。你必须选择在发布随机实用工具 crate 和重构项目以避免此问题之间。这个限制感觉是任意而不必要的。显然，你可以构建像这样的项目，但你就是无法发布。

编辑： Ed Page 联系了我 指出只要在 Cargo.toml 中不包含 version，你 可以 通过本地开发依赖项发布。

不过，Cargo确实有很好的工作区支持！Cargo 的工作区管理大型项目的体验比大多数语言更好。但是它们并不能解决部署问题。结果是，你可以以多种方式设置工作区，没有 一种方式能让部署更轻松。

你可以在大量旨在简化发布工作区的 实用库 中看到问题的显现。每个库都与某个配置子集协作，而“唯一真正的方式”设置工作区仍然让我感到困惑。当我发布 Wick 时，往往需要一个小时以上的努力来结合手动、重复的任务与仅部分可用的工具。

Async

Rust 在创建后将异步添加到了语言中。这感觉像是一种事后想法，表现得像一个事后想法，并且经常因为难以理解和解决的错误而妨碍你。当你寻找解决方案时，你必须根据各种运行时及其异步变体进行筛选。想使用异步库？你可能无法在特定的异步运行时之外使用它。

在经历了两年的 JavaScript 及不错的 Go 经验后，这是与 Rust 的 最主要的 挫折和摩擦来源。这不是一个不可克服的问题，但你必须始终准备好应对异步怪物的出现。其他语言中的异步几乎是隐形的。

难看的地方

重构可能会很费劲

Rust 丰富的类型系统是一个福音，也是一个诅咒。在 Rust 类型中思考是一种梦想，但管理 Rust 的类型可能是一个噩梦。你的数据和函数签名可以具有泛型、泛型生命周期和特征约束。这些约束可能还有自己的泛型类型和生命周期。有时，你的类型约束比实际代码还要多。

约束超越逻辑

你还需要在每个 impl 中定义所有泛型。第一次写时，这很繁琐。然而，在重构时，它可能会将小更改变成连锁混乱。

简单的泛型 ID 被一次又一次地重复。

当你需要调整 14 个不同的定义才能前进一步时，快速进展变得困难。

编辑以解决外部评论：问题不在于可表达性，而在于没有语言或工具解决方案以减少重复。有人经常需要相同的约束或引用相同的泛型列表，但没有办法为中央定义创建别名或以其他方式引用。不确定是否应该这样，但这并不改变重复的负担。

裁决

我爱 Rust。我喜欢它能做的事，以及它的多功能性。我可以用与 CLI 应用程序、网络服务器和网络客户端相同的语言编写系统级代码。通过 WebAssembly，我可以使用相同的二进制文件在浏览器中运行 LLM https://wasm.candle.dev/llama2 和在命令行中运行。这仍然让我感到震惊。

我爱 Rust 程序的坚如磐石。在你学会欣赏 Rust 保护你免受的内容之后，很难再回到其他语言。我曾短暂地回到了 Go。我很快又被开发速度所陶醉。然后我遭遇了运行时 panic，玻璃破碎了。

但是 Rust 也有它的缺点。招聘困难、学习缓慢，且迭代太过严谨。尤其是处理异步代码时，故障排除内存和性能问题都很困难。并非所有库在安全代码方面都如此优秀，开发工具也还有待改进。你总是处于劣势，面临许多阻碍。如果你能克服这些障碍，最终将遥遥领先。这是一个很大的“如果”。

我们真的值得 Rust 吗？现在还为时已晚。我们在小团队中做了惊人的事情，但也遇到了巨大的障碍。我们还有一些技术原因，使 Rust 更加可行。

那对你而言值得吗？如果你需要快速迭代，可能不值得。如果你有已知的范围，或者可以承受更多的前期成本？绝对值得考虑。最终你会得到无懈可击的软件。随着 WebAssembly 的发展每月迫近，编写完美软件 一次 并在 所有地方 重用的前景越来越早地成为现实。

• 原文链接： jsoverson.medium.com/was...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～