探索Go程序的进化可能性

有时候，我们会想要把别种语言编写的库嵌入到自己的程序里。这类需求在程序员之间早已有之，但出于种种原因，这始终是个充满了危险、恐惧、折磨的艰难过程。

照常来讲，如果想从 Go 中调用 Rust 函数，那我们就必须借助 cgo 这样的跳板。但这样效果不错，而且至少比亲自编写 cgo 这样的工具方便得多。

然而，问题是当我们用 cgo 将 Rust 函数链接到 Go 程序时，还得复制 Rust 生成的共享对象。我们没法把这个共享对象签入源代码树（不同操作系统、不同 CPU 架构的各自系统分发都必须是唯一的，就像常见的动态链接二进制文件一样）。所以虽然有效，但总体来讲其开发者体验很差。这时候就不能简单 go build，还得记得运行 cargo build --release 并确保生成的.so、.dll 或者.dylib 位于操作系统动态链接程序所能读取的正确路径。总之，一团乱麻。

这是个大问题，也是 Nix 和 NixOS 存在的原因。想象一下，当我们把通用操作系统组件混入其中，情况会有多么复杂。但令人惊讶的是，这样操作又是真实有效的。那么，如果说有一种方法能让我们从 Rust 发布一个二进制文件，它能在 Go 所支持的任何平台上正常起效；而且只需简单的 go build 就行、不必修改任何构建过程呢？一想就知道能这样可太棒了。对用户来说，他们虽然使用相应的包或程序，却根本感受不到有 Rust 参与其中。我的这个 mastosan 包就是这样的解决方案。下面我想跟大家聊聊它的开发过程以及存在的原因。

为什么要开发 mastosan

Mastodon 的实质就是把素材存储为 HTML 格式，再将该 HTML 呈现了 API 使用者。HTML 特别适合浏览器显示，但对 bot 来说意义不大。所以如果目标是 Slack webhook，那就不太合适。

下面来看 API 中的素材：

其内容如下所示：

理想情况下，我们当然希望它在 Slack 中也有相同的语义，比如像这样：

这条链接在 Slack 中的显示效果跟其他超链接一样。但随着设计复杂度的提升，Mastodon 也会出现某些怪异语义，例如 span 不可见及其他一些烦人的 Slack 显示错误。我们看看以下两条有什么区别：

很明显，这两条跟人类正常思维的契合度就不一样。

如何实现

UNIX 理念的核心特征之一，在于将程序视为简单的过滤器。它既能很好地完成一项任务，又允许用户将其组合为新的、更有趣的形式。如果大家曾经把 curl 和 jq 配合起来执行操作，比如从 JSONFeed 中读取数据之类，就能理解这类实践过程：

我用 Rust 编写了一个小程序，它使用 lol_html 来获取传入的 Mastodon 风格 HTML，并发布 Slack 风格的 markdown。用法非常简单：

就这么简单。它会接收标准输入并在此之上返回结果。这跟 WebAssembly 流并不直接映射，除非用 WASI 填补其中的空缺。WASI 为 WebAssembly 程序提供了类似于 POSIX 的环境，大多数基础功能都可以直接起效，但这里我们只使用到它的两个主要部分：标准输入和标准输出。

在 Go 中，如果将其作为普通的 OS 子进程运行，可以使用以下代码：

但这仍然要求程序针对本机 OS 和发行版进行编译，而且必须存在于 $PATH 文件夹内。所以有效，但还不够完美。

Rust 允许我们使用以下编译器标记，构建以 WASI 为目标的二进制文件：

这会在./target/wasm32-wasi/release/mastosan.wasm 当中生成一个几 MB 大小的二进制文件。只要运行它，就能帮我们达成目标。

现在我们需要在 Go 中用这个二进制文件。可行的办法很多，这里我选择使用 wazero。它的使用流程类似于带 os/exec 的子进程，但也略有不同，因为我们嵌入了 WebAssembly。具体方法如下：

意思基本是一样的：设置环境、加载 WASM 模块，然后运行。主要区别在于，这里我没有把二进制文件作为机器码从磁盘上加载，而是使用 go:embed 将预编译的 WebAssembly 模块嵌入到了二进制文件中。也就是说，只要 WebAssembly 模块的位置符合要求，那生成的 Go 程序就能正常工作。

再快一点

这种实现的主要缺点就是速度略慢。每次调用该函数时，它都必须编译 WebAssembly 模块。

Wazero 运行时和编译后的 WebAssembly 模块代码都可以被举升到包级变量当中，具体如此补丁（https://github.com/Xe/x/commit/b61b59318be6544632ac1f64b1237bb17b2e7a32）所示。这样就能大大改善速度问题。用了这个补丁，WebAssembly 模块只会在应用程序启动时编译一次。在使用此补丁前，每次运行中的调用大概需要 0.2 秒，而使用补丁后的基准测试结果为：

可以看到，最佳用时从 0.2 秒下降到了 0.3 毫秒，意味着性能至少提升了 1000 倍。这意味着大部分时间可能都花在了 HTML 解析器上，而不是无关紧要的其他部分。

我觉得这不仅能满足我个人的工作需求，也应该会帮助更多朋友解决难题。后续我还会用更多随机 Mastodon 消息做实验，看看它能否满足要求。这种将两个不相容的世界融合起来的感受真棒，也期待它能真正在更多实践场景当中发光发热。

审核编辑 ：李倩