有時(shí)候，我們會(huì)想要把別種語(yǔ)言編寫(xiě)的庫(kù)嵌入到自己的程序里。這類需求在程序員之間早已有之，但出于種種原因，這始終是個(gè)充滿了危險(xiǎn)、恐懼、折磨的艱難過(guò)程。

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

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

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

為什么要開(kāi)發(fā) mastosan

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

下面來(lái)看 API 中的素材：

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

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

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

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

如何實(shí)現(xiàn)

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

我用 Rust 編寫(xiě)了一個(gè)小程序，它使用 lol_html 來(lái)獲取傳入的 Mastodon 風(fēng)格 HTML，并發(fā)布 Slack 風(fēng)格的 markdown。用法非常簡(jiǎn)單：

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

在 Go 中，如果將其作為普通的 OS 子進(jìn)程運(yùn)行，可以使用以下代碼：

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

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

這會(huì)在./target/wasm32-wasi/release/mastosan.wasm 當(dāng)中生成一個(gè)幾 MB 大小的二進(jìn)制文件。只要運(yùn)行它，就能幫我們達(dá)成目標(biāo)。

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

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

再快一點(diǎn)

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

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

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

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

審核編輯 ：李倩