受不了Rust 这些问题,我将后端切换到了 Go

作者 | Anthony Oleinik

译者 | 平川

策划 | 刘燕

本文最初发布于 Level Up Coding 博客。

别激动!我能感受到你点击这篇文章时怀有的愤怒。我并不讨厌 Rust——在许多场景中,我都倾向于使用它。所有编程语言都是达成目的的手段。然而,就我要处理的场景而言,Rust 并不是很适合,我不得不把这个项目推倒重来,用 Golang 重写。

该项目是 Hasura 的一个简单的后端 webhook 服务。你可能不了解 Hasura,那是一个 Postgres 数据库封装器,可以即时提供 GraphQL API。对于像我这样独自开发个人兴趣项目的人来说,这非常方便:每个 REST 端点或 GQL 解析器都要编写的话会耗费大量的时间,而且每个模型的 CRUD 操作基本相同。当需要一些比较复杂的逻辑时,它就不那么有效了——为此,Hasura 允许你将 GQL 请求映射到自定义 webhook。举例来说,我就是用这种方法进行 S3 文件上传或身份验证。

问题 1:依赖注入难

Rust 依赖注入是一个有趣的问题。如果你需要一个具体的类型,如:

fn do_stuff(db: &Database) {    db.create(Stuff);         db.read(Stuff);}

你必须给 do_stuff 传递一个 Database 实例;概莫能外!你不能“子类化”Database (Rust 没有子类的概念)。所以,如果你是一个不自己测试代码的程序员,那么这完全没问题;实际上,你只会有一个 Database 的实现,因此也就没有理由让这个函数接受 Database 以外的任何东西。

那我们测试人员呢?我们必须重写函数签名。Database 需要是 trait 类型的,然后我们把那个它在 mock 对象上实现。好吧,还不算太坏。事实上,在 Golang 中,我做的事情基本相同;那到底是从哪里开始有问题的呢?

问题 2:异步 Trait

在 Rust 中,异步很简单,trait 也很简单,但异步 trait 却有些困难。我在 Rust 中找到的大多数异步 trait 示例都用了 async_trait 宏。这很有帮助,我正在用它,体验还不错。

以下是我到目前为止对这个过程的一个总结:

  1. 编写一个结构;开心。

  2. 编写一个测试;意识到无法依赖注入。难过。

  3. 将结构转换为 trait;开心。

  4. 心满意足地依赖注入。

  5. 使用 mockall crate 自动生成 mock。非常非常开心!

  6. 做一个异步 http 调用。

  7. 需要用一个特殊的宏实现异步 trait。

  8. 意识到这个宏无法很好地与 Mockall 一起工作。

  9. 难过。

事后来看,这个问题是有办法解决的。也许在切换到 Go 之前我应该再试一次,但那时,下面这一点已经让我有点沮丧了……

问题 3:编译慢(致命一击)

Rust 的编译时间很糟糕。我们已经听过无数次了;不可能有一种无所不能却没有缺点的语言。那是不可能的——Rust 的缺点是难以理解的生命周期以及糟糕的编译时间。

我有一台漂亮耐用的笔记本电脑 M1 Mac,那可是一头老黄牛。在我的 Mac 上编译 Rust 绝对没有问题。通常,在编写服务器时,我会在本地开发,并且要保证每次有修改时,本地服务器会重新加载,让我可以在提交真正的单元测试之前非常快速地测试功能。两次试验之间需要进行大量的编译;可以接受!还是说,在 Mac 上编译 Rust 没有问题。

在容器里吗?还是算了吧。

对我来说,要编排许多本地服务而又不用费事在每个服务(Hasura、Web 钩子、mock s3、mock oauth 服务器……)中运行 npm run ,最简单的方法是有一个 docker-compose.yaml 文件可以运行所有这些东西。通常就是一个 docker-composition.dev.yaml 文件,因为我实际上并不使用 docker compose 进行部署。只在本地进行开发。然而,这有一个副作用,就是我的 Rust 代码需要在容器中编译,因为:必

  1. 须自动热重载。

  2. 必须在容器里开发。

我有两个选择:要么启动一个可能会跑死整台计算的巨大镜像,以便在其中编译 Rust 代码,要么就要与 3 分多钟的编译时间周旋。开发周期陷入停滞,让我感觉非常低效。我试着改变工作流程,在手动测试之前编写代码和测试,或者不使用自动热加载,但糟糕的是,我就是没能做到。

最后,我咬紧牙关,换成了 Go。让人怀念的 Rust:我非常喜欢编写 Rust 代码。我觉得它漂亮而富有表现力,实用而优雅。

如果我正在编写本地辅助库、性能敏感代码、任何不需要在容器中运行的后端服务……那么,Rust 会是我的第一选择。特别是如果我不需要说服其他任何人使用它。

对于我提到的问题,特别是最后一个问题,如果你有任何解决方法,请务必告诉我。我想让 Rust 回到项目中,我愿意回到旧版本,并将其提升到同等水平。

本文文字及图片出自 AI前线

余下全文(1/3)
分享这篇文章:

请关注我们:

发表评论

邮箱地址不会被公开。 必填项已用*标注