有時候，我們會想要把別種語言編寫的庫嵌入到自己的程序里。這類需求在程序員之間早已有之，但出于種種原因，這始終是個充滿了危險、恐懼、折磨的艱難過程。

照常來講，如果想從 Go 中調(diào)用 Rust 函數(shù)，那我們就必須借助 cgo 這樣的跳板。但這樣效果不錯，而且至少比親自編寫 cgo 這樣的工具方便得多。

然而，問題是當我們用 cgo 將 Rust 函數(shù)鏈接到 Go 程序時，還得復(fù)制 Rust 生成的共享對象。我們沒法把這個共享對象簽入源代碼樹（不同操作系統(tǒng)、不同 CPU 架構(gòu)的各自系統(tǒng)分發(fā)都必須是唯一的，就像常見的動態(tài)鏈接二進制文件一樣）。所以雖然有效，但總體來講其開發(fā)者體驗很差。這時候就不能簡單 go build，還得記得運行 cargo build --release 并確保生成的.so、.dll 或者.dylib 位于操作系統(tǒng)動態(tài)鏈接程序所能讀取的正確路徑?？傊粓F亂麻。

這是個大問題，也是 Nix 和 NixOS 存在的原因。想象一下，當我們把通用操作系統(tǒng)組件混入其中，情況會有多么復(fù)雜。但令人驚訝的是，這樣操作又是真實有效的。那么，如果說有一種方法能讓我們從 Rust 發(fā)布一個二進制文件，它能在 Go 所支持的任何平臺上正常起效；而且只需簡單的 go build 就行、不必修改任何構(gòu)建過程呢？一想就知道能這樣可太棒了。對用戶來說，他們雖然使用相應(yīng)的包或程序，卻根本感受不到有 Rust 參與其中。我的這個 mastosan 包就是這樣的解決方案。下面我想跟大家聊聊它的開發(fā)過程以及存在的原因。

為什么要開發(fā) mastosan

Mastodon 的實質(zhì)就是把素材存儲為 HTML 格式，再將該 HTML 呈現(xiàn)了 API 使用者。HTML 特別適合瀏覽器顯示，但對 bot 來說意義不大。所以如果目標是 Slack webhook，那就不太合適。

下面來看 API 中的素材：

其內(nèi)容如下所示：

理想情況下，我們當然希望它在 Slack 中也有相同的語義，比如像這樣：

這條鏈接在 Slack 中的顯示效果跟其他超鏈接一樣。但隨著設(shè)計復(fù)雜度的提升，Mastodon 也會出現(xiàn)某些怪異語義，例如 span 不可見及其他一些煩人的 Slack 顯示錯誤。我們看看以下兩條有什么區(qū)別：

很明顯，這兩條跟人類正常思維的契合度就不一樣。

如何實現(xiàn)

UNIX 理念的核心特征之一，在于將程序視為簡單的過濾器。它既能很好地完成一項任務(wù)，又允許用戶將其組合為新的、更有趣的形式。如果大家曾經(jīng)把 curl 和 jq 配合起來執(zhí)行操作，比如從 JSONFeed 中讀取數(shù)據(jù)之類，就能理解這類實踐過程：

我用 Rust 編寫了一個小程序，它使用 lol_html 來獲取傳入的 Mastodon 風格 HTML，并發(fā)布 Slack 風格的 markdown。用法非常簡單：

就這么簡單。它會接收標準輸入并在此之上返回結(jié)果。這跟 WebAssembly 流并不直接映射，除非用 WASI 填補其中的空缺。WASI 為 WebAssembly 程序提供了類似于 POSIX 的環(huán)境，大多數(shù)基礎(chǔ)功能都可以直接起效，但這里我們只使用到它的兩個主要部分：標準輸入和標準輸出。

在 Go 中，如果將其作為普通的 OS 子進程運行，可以使用以下代碼：

但這仍然要求程序針對本機 OS 和發(fā)行版進行編譯，而且必須存在于 $PATH 文件夾內(nèi)。所以有效，但還不夠完美。

Rust 允許我們使用以下編譯器標記，構(gòu)建以 WASI 為目標的二進制文件：

這會在./target/wasm32-wasi/release/mastosan.wasm 當中生成一個幾 MB 大小的二進制文件。只要運行它，就能幫我們達成目標。

現(xiàn)在我們需要在 Go 中用這個二進制文件?？尚械霓k法很多，這里我選擇使用 wazero。它的使用流程類似于帶 os/exec 的子進程，但也略有不同，因為我們嵌入了 WebAssembly。具體方法如下：

意思基本是一樣的：設(shè)置環(huán)境、加載 WASM 模塊，然后運行。主要區(qū)別在于，這里我沒有把二進制文件作為機器碼從磁盤上加載，而是使用 go:embed 將預(yù)編譯的 WebAssembly 模塊嵌入到了二進制文件中。也就是說，只要 WebAssembly 模塊的位置符合要求，那生成的 Go 程序就能正常工作。

再快一點

這種實現(xiàn)的主要缺點就是速度略慢。每次調(diào)用該函數(shù)時，它都必須編譯 WebAssembly 模塊。

Wazero 運行時和編譯后的 WebAssembly 模塊代碼都可以被舉升到包級變量當中，具體如此補?。╤ttps://github.com/Xe/x/commit/b61b59318be6544632ac1f64b1237bb17b2e7a32）所示。這樣就能大大改善速度問題。用了這個補丁，WebAssembly 模塊只會在應(yīng)用程序啟動時編譯一次。在使用此補丁前，每次運行中的調(diào)用大概需要 0.2 秒，而使用補丁后的基準測試結(jié)果為：

可以看到，最佳用時從 0.2 秒下降到了 0.3 毫秒，意味著性能至少提升了 1000 倍。這意味著大部分時間可能都花在了 HTML 解析器上，而不是無關(guān)緊要的其他部分。

我覺得這不僅能滿足我個人的工作需求，也應(yīng)該會幫助更多朋友解決難題。后續(xù)我還會用更多隨機 Mastodon 消息做實驗，看看它能否滿足要求。這種將兩個不相容的世界融合起來的感受真棒，也期待它能真正在更多實踐場景當中發(fā)光發(fā)熱。

審核編輯 ：李倩