本文是筆者與風格多元、十分有趣的 Stray Pointers Podcast 主持人 Jim Lawless 對談的逐字稿，經過輕度編輯並刪除了語助詞。訪談於美國時間 1 月 15 日錄製，我們聊了 Forth、C、CGI、Python、Go 與 AWK。

您可以在節目網頁或 YouTube 上收聽。

Jim：今晚很高興邀請到工程經理兼軟體工程師 Ben Hoyt。Ben，歡迎來到節目！

Ben：非常感謝。

Jim：嗨 Ben，我注意到你是新版《The AWK Programming Language》一書的技術編輯／審校者，就這樣一路追蹤下去，發現你在程式語言方面有段相當有趣的經歷。所以想聊聊你的程式背景——你是怎麼入門的，最早用了哪些語言？

Ben：這要回溯很久了。我小時候就開始了，大概是 80 年代末、90 年代初。我記得的第一台電腦是 Sega SC-3000，一台鍵盤與主機一體的小電腦，內建了 BASIC。我想是爸爸讓我接觸到這些的——他現在還在，不過已經退休了——他本業是牧師，晚上則是個業餘程式設計師，寫 Forth 的那種。

所以他在那台電腦上做了一些嘗試，我記得他把 Forth 移植上去，還弄了其他東西，所以我們從小就接觸到這些。不過那時候我大多只是在上面玩遊戲，像小精靈之類的，但家裡到處都有電腦雜誌，後面都會附那種好笑的小 BASIC 遊戲程式，你得從雜誌最後幾頁把程式碼一字一句手打進去。我打過幾個，但從來沒成功過，因為只要打錯一個字，整個程式就跑不起來。不過我想就是那樣加上爸爸的興趣，讓我入了門。

Jim：我對你對 Forth 的興趣特別好奇。你還在青少年時期，就和 Hans Bezemer 合寫了一篇刊在Forth Dimensions 雜誌上的文章，是這樣嗎？

Ben：對，沒錯。我想那是我第一次發表的技術文章。後來我還滿喜歡技術寫作的，現在也有自己的部落格。但那篇文章大概有點操之過急，沒怎麼經過同儕審閱，不過以當時的程度來說還算不錯。文章談的是 Forth 裡的查表（lookup tables）有多好用，我算是跟他合寫的。

Jim：你怎麼會跟 Hans 認識的？他在 Forth 圈子裡現在算是小有名氣，以他的 4tH 編譯器（數字 4 加 T-H）聞名。

Ben：對，沒錯，我想那時候他就已經小有名氣了，他在這圈子很久了。從那之後我其實就沒再跟他聯絡過，但我們當時是在 comp.lang.forth 或某個新聞群組上認識的，我說我在玩查表，覺得它們超棒。他說他也喜歡，要不要一起為《Forth Dimensions》寫篇文章？我忘了是不是他提議的——我想應該是他提的——要一起合寫。

所以那是個不錯的機會，我就寫了一些程式碼，然後整理出我的發現，說明它比其他技巧快多少。我想我有點投機取巧——只要姿勢擺對、笑得夠燦爛——它們就比較快，但大多數時候其實沒有，我就那樣寫了。所以我才說有點操之過急。當時那是個閃亮的新玩具，我就是想用查表。它成了我的鎚子，什麼問題都想拿它來敲。

Jim：當然。就像每個稱職的 Forther 一樣，你自己實作了一個 Forth。可以跟我聊聊那件事嗎？

Ben：可以。我爸非常熱衷 Forth，也寫過自己的 Forth 編譯器，或說好幾個編譯器。所以我開始認真寫程式時，最早的兩種語言就是 x86 組合語言和 Forth。然後我在 DOS 時代用 8086 組合語言寫了自己的 Forth。Forth 最棒的地方就是它非常小巧，你用大概兩千行左右的程式碼就能寫出一個可以自我引導（fully-bootstrapping）的編譯器。裡面有個用組合語言寫的小核心——他們稱之為原語（primitives），也就是構成 Forth 核心的基本操作。然後在那之上，你用 Forth 本身來寫其餘的部分。所以我的第一個版本是用 A86 組譯器寫的核心，如果你熟悉那個工具的話，那是個很棒的工具。

Jim：對，那是當時很受歡迎的共享軟體組譯器。

Ben：對，沒錯。而且我記得我只用過免費版，因為那時還是青少年，沒錢付費。但那真是個很棒的小組譯器。所以我的第一版 Forth 就是用 A86 寫核心，再加上用 Forth 寫的上層。過了幾個版本後，我搞懂了 Forth 社群所說的 meta-compiling，也就是用 Forth 來打造 Forth，用 Forth 來建構你自己的 Forth 編譯器。要做到這點，你幾乎需要一個用 Forth 寫的組譯器，所以我想我是從網路上抓了一個來改，幾乎像是為了搞懂它而重新打了一遍。那時候很多東西都是這樣學來的。

Jim：Bill Ragsdale 在 80 年代初於Dr. Dobb's Journal 上發表過一個很有名的、用 Forth 寫的 6502 組譯器。你是用那個當範本，還是當時有更適合 x86 的版本？

Ben：不是，那是一個專門給 x86 用的。我不記得它的名字了。讓我看看程式碼註解裡有沒有……看起來我當時甚至沒在程式碼註解裡標註來源。所以沒有，它是基於某個 x86 組譯器，我已經不記得是哪一個了。

Jim：好，那麼在你打造了這些 Forth 系統之後，你用 Forth 寫了些什麼？寫了什麼樣的軟體？

Ben：Forth 最棒的地方就是：你不會用它寫任何軟體，你只會用它來寫 Forth 編譯器。[笑] 我寫了什麼？一些小遊戲和繪圖程式。跟我玩 Forth 的同時，我也沉迷於 demoscene，不熟悉的聽眾可能不知道，那是一個程式設計師的次文化，大家喜歡寫些小型的繪圖展示和音樂展示來炫技。還有各種比賽，像是 4K demo——看你在 4K 的程式碼空間裡能塞進多炫的繪圖。所以我透過 BBS 在紐西蘭稍微參與了那個圈子，我就是在 BBS 上學習的，那些都是繪圖和遊戲類的東西，所以我用 Forth 也做了一點那方面的嘗試。

然後我用 Forth 做的另一件事是——那是幾年後的事了——為 386 寫了自己的 32 位元作業系統，一個 Forth 作業系統。非常精簡——我說是作業系統，其實極度陽春，大概只有鍵盤驅動程式、磁碟 I/O 和螢幕驅動程式，就這樣而已。

Forth 真的形塑了我的思考方式，大概到現在還是。你知道，我現在已經不用它了，但它確實形塑了我的思維。它有點像 Lisp 那類語言，在思維上、哲學上會讓你腦洞大開、非常酷。也正因如此，我一直偏好小巧、快速、輕量的東西，能夠從核心到底層都完全理解的那種。

不過，我做 demoscene 的時候也接觸了 Turbo Pascal——那是很多 sceners 會用的工具。也稍微玩了一下 C——但在那個階段，對我來說 C 還是有點艱澀。大概就在那個時期，我高中畢業去念大學，讀電機工程。關於電機系有個好笑的故事——他們有個很奇怪的規定：在三年制課程一開始，你可以選修一門程式設計課，如果你通過那門課的測驗——一個小小的 C 語言測驗，寫點 C、回答幾個問題——只要通過了，接下來整個學程就不用再修任何程式課了。我當時就通過了，結果那是個錯誤，因為我雖然會寫程式，卻不懂軟體工程和更大局面的東西。所以一直到畢業後進了職場，我才真正把 C 學起來，學會怎麼組織較大的程式、做軟體工程，算是邊做邊學。C 是我第一個真正專業的語言。

Jim：那時你是電機工程師嗎？

Ben：我念的是電機，但在第一份工作就慢慢往寫程式靠攏，而那正是當時公司需要的，所以從那之後我就一直寫程式，電機那塊就放掉了——可以說，我沒再用過我的學位。

Jim：那是嵌入式 C，還是一般應用程式的開發？

Ben：好問題。第一份工作中大概有一半是嵌入式，我會為小型的微控制器寫小小的 bootloader 或小小的裝置驅動程式。這讓我想到最近大家常談的「嵌入式 Linux」，我心裡都會想：那才不叫嵌入式！你講的是 2GHz 處理器配 1GB 記憶體！我說的嵌入式，像我當時做的，是只有 2KB 記憶體的小小 16 位元或 8 位元微控制器。公司用的其中一顆晶片是 MSP430，之後才慢慢進到 ARM7，開始接觸一些 32 位元的東西。

Jim：那時候你是在一個團隊裡嗎？

Ben：那是一家非常小的公司，團隊——如果能稱得上團隊的話——就只有另一位非常優秀的電機工程師兼韌體開發者，他是我的第一位導師，人非常好——他叫 Gary——算是帶著我學習程式設計中真正關於軟體工程的那一面。

Jim：兩人的團隊也能學到那些嗎？我是說版本控制、共享原始碼、建構流程之類的？

Ben：那些是後來才有的。他教了我一些軟體工程和資訊科學的基礎，或者說我在那裡耳濡目染學到一些。當時他其實不太相信版本控制，所以我那時也沒學到。所以那不是當時的東西——先說清楚，我現在可是非常相信版本控制的。

Jim：這是好事。

Ben：是非常好的東西！我現在什麼都用 Git。所以版本控制和持續整合（CI）那些都是職涯後期才接觸到的。在那家公司學到的主要是程式設計的基本功和架構組織。所以我用 C 做了些嵌入式的工作，但那是我當時唯一真正會的專業工具，所以當我們要為正在做的氣象系統寫後端時，需要渲染網頁、畫出漂亮的圖表、輸出一些 GIF 檔，而我只會 C，就用 C 寫了那些 CGI 程式。這對 CGI 和網頁來說是個糟透了的選擇，但它確實完成了任務，撐了很多年。我敢肯定我離職後接手的人一定在心裡咒罵我，但當時那確實解決了眼前的問題。

Jim：接下來你又學了哪些程式語言和技術？

Ben：離開那裡之後，我和兩個兄弟一起創業。我們叫它 microPledge——這個可以多聊，但我先聚焦在程式這塊——我是透過那次創業學會 Python 的。在那之前我就對 Python 有興趣，心想用它來寫網頁應用程式肯定比 C 好得多，事實也的確如此。所以我是跟兄弟一起做那個新創時學會 Python 的。

我其中一個兄弟當時已經是個很強的 Python 開發者，所以我學會了 Python，也學會了測試、學會了版本控制——那些都是那次創業經驗的一部分。那個新創本身失敗了，但在職涯技能上算是成功的，讓我在 Python 和軟體工程方面學到很多。所以 Python 就是那個語言，到現在都還是我工作上的主要語言。那真的是很久以前一次很棒的經驗。

Jim：你提到你曾對 Python 的 os.scandir 有過貢獻？

Ben：對，那是幾年後的事了——讓我看一下時間軸。我在 2016 年寫過那件事，但其實早幾年前就開始了——好吧，是 2012 年。當時我想找個方法遞迴走訪目錄結構，而我那時是在 Windows 上用 Python。我注意到 Windows 的檔案總管，你對著一個目錄按右鍵看內容，它算出遞迴目錄大小的速度非常快，你可以看見它在掃描，但速度很快。而你在 Python 裡用 os.walk 做同樣的事——卻慢得多。我就開始研究為什麼會這樣？Python 照理說應該能跟檔案總管一樣快才對。

結果發現，是因為 os.walk 的設計和實作方式，它做了很多額外的系統呼叫——基本上是對每個檔案多做一次 os.stat 呼叫，外加 Windows 用來取得檔名的 FindFirst 和 FindNext 呼叫。其實你根本不需要那些額外的 stat 呼叫。所以 Python 等於是呼叫了那些函式、然後把一半的資訊丟掉，又再做額外的呼叫，而 scandir 讓你在遞迴遍歷目錄時，不用丟掉一半資訊就能取得你需要的資料。

Jim：不過這在所有平台上都能通用吧？

Ben：對，它在 Windows 和 Linux 上用了不同的 OS 呼叫，但概念是一樣的。Windows 從 FindFirst 和 FindNext 給你的資訊比較多：它會直接給你所有的檔案屬性。Linux 則不會給你大小等資訊，只會給你檔案類型——是目錄還是檔案。但即使這樣，在 Linux 上還是省下了一次 os.stat 呼叫來判斷——喔，是目錄，好，遞迴進去；不是，就不用遞迴。所以即使在 Linux 上也明顯變快了，在 Windows 上提升更明顯。而在網路檔案系統上又更快，因為可以想見，減少網路呼叫次數效益更大。

Jim：那 os.walk 後來就被棄用了嗎？

Ben：沒有。os.walk 是改用 scandir 重新實作的。所以 scandir 算是比較底層的工具，而整個想法就是要讓 os.walk 變快。所以我們得以用 scandir 來重寫 os.walk，結構大致相同，只是把原本用 listdir 加 os.stat 的部分改成 scandir。這樣我們完全不用改 os.walk 的介面，大家在自己的腳本裡沿用它，就能免費獲得效能提升，根本不需要知道 scandir 的存在。這點讓我印象很深刻：你可以完全換掉某個東西的內在——事後看來很理所當然——但你可以徹底改變實作，大家就能免費獲得加速。而當時有很多腳本都在用 os.walk，所以很多人都受惠了。

Jim：你提到你寫過一些 CGI 程式，後來又和兄弟一起創業用 Python 做網站，所以我想你一定也得學一些其他技術才能做出完整的網站：像是 HTML、JavaScript、資料庫之類的？

Ben：對，學了不少。所以資料庫和 HTML——我想 HTML 是我在做那份 C 的工作時就學了——但 SQL 資料庫對當時的我來說是全新的，當我加入兄弟的新創時才第一次接觸。第一次碰到關聯式模型時，確實有點燒腦，思考方式很不一樣。所以我花了一段時間才上手，但真的非常強大，從那之後就一直用到現在。所以確實有資料庫，也接觸了一些 JavaScript。那還是早期，JavaScript 比較像是附加的東西，而不是像現在這樣，所有網站都用它來寫。老實說我到現在還是不喜歡大家什麼都先用 JavaScript，明明很多東西用 HTML 就能做。

Jim：你在那篇叫做〈小小網路之美（the small web）〉的文章裡就有談到這點。

Ben：完全是。那也呼應了我前面提到的：我一直喜歡又快又輕又小的東西。而現在的網頁往往肥大、臃腫又慢，有些人很在意，努力縮小圖片、減少拖慢速度的 JavaScript 之類的——我很喜歡這些。在這方面現在也有點像是個運動：「small web」（小網路）算是其中一個比較鬆散的說法，「indie web」（獨立網路）也是另一個說法，大家開始自己動手做網站、回歸基本功，更在乎這些。

Jim：不只是網路。現在有用 Electron 寫的桌面應用程式，那些是建立在厚重的網頁技術上的，等於把所有肥大都帶到了桌面。

Ben：對，沒錯。我知道——我能理解重用那些技術的價值。我覺得這部分是個打包（packaging）的問題，我也看過一些相關的嘗試，像是：我們不要直接打包 Electron，而是用作業系統原生的瀏覽器技術，或是用機器上已經有的瀏覽器，但做成桌面應用程式。我忘了那些工具叫什麼，但如果要走那個方向，那似乎是個更好的做法。

Jim：那之後你的技術能力又有了哪些演進？接下來學了什麼技術？

Ben：大概是——我是說，稍微快轉一下——有 Postgres、JSON 那些網頁相關技術，但那很多年來我主要還是用 Python。不過大概在——讓我想想，是什麼時候，我的部落格寫是 2017 年——2017 年我學了 Google 的 Go 語言。我是為了個人專案而學的，但很快地，下一份工作就大量使用 Go，所以在專業上也非常有用，到現在都是。

Jim：你為什麼會選 Go 來學？外面有那麼多語言可以學，是 Go 的哪一點吸引了你？

Ben：我喜歡它的樣子。我喜歡——你知道，它背後有幾位老 Bell Labs 的大神。也許我有看到 The Go Programming Language 這本書是由 Brian Kernighan 和現在還在 Google Go 團隊的 Alan Donovan 合寫的。但光是 Brian Kernighan 的名字在上面，就很吸引人，而設計 Go 的三位——Ken Thompson、Rob Pike 和 Robert Griesemer——其中兩位我記得就是以前 Unix 和 Bell Labs 的人。

不過，最初吸引我注意的倒不是這個，你知道，我在 Hacker News 等地方就看過它，我就是喜歡它的設計哲學。它的語法很簡單，有種 Keep It Simple, Stupid（保持簡單、愚蠢）的語言設計態度，但即使在當時，工具鏈就已經非常專業、非常好用。Go 團隊對這點也很直白：這個語言本身沒什麼新東西。有幾個獨特的概念，但沒有什麼革命性或開創性的東西。真正最大的賣點是工具和整體整合起來的品質，還有函式庫的品質。編譯器的速度。只要打 go test 就會自動跑所有測試。只要打 go build 並設定一個環境變數就能交叉編譯——就是這類事情。

Jim：你說你後來找到了 Go 的工作。是你主動去找 Go 的職缺，還是純屬巧合？

Ben：算是巧合，但到最後我大概也是部分因為他們有用 Go 才選擇了那份工作。某種程度上他們也挑上了我，像那次面試就是以 Go 為主，我記得有做一題 Go 的題目，所以他們也欣賞我的 Go 能力。

Jim：後來你用 Go 打造了 AWK 程式語言的直譯器和轉譯器。你最早是在哪裡接觸到 AWK 的？

Ben：我最早在哪裡碰到 AWK？我很早就知道有 AWK 這個東西。它是個 70 年代的老工具，但我其實從來沒真正用過——部分原因是我的背景是 DOS 和 Windows，而不是 Linux 和 Unix。所以 AWK 並不在那個環境裡，但我早就耳聞它，後來開始用 Mac 開發，Mac 是以 Unix 為基礎的，之後又真正用 Linux，才比較常看到 AWK。

但真正讓我投入的，是讀了 Brian Kernighan 和 AWK 的三位創造者 Al Aho、Peter Weinberger 和 Brian Kernighan 合寫的The AWK Programming Language 的前兩章。我想那本書主要還是 Brian 執筆——至少我的印象是這樣——而我開始讀那本書，它的風格跟 The C Programming Language、也就是 K&R 那本一樣：簡潔、資訊密度很高。

所以讀完第二章你就學會了整個 AWK，他們已經把 AWK 全部教完了，後面的章節則是深入細節，用 AWK 寫個小編譯器、用 AWK 寫個小資料庫系統——能用 AWK 做出這些，真的很酷。所以它把 AWK 從那種玄妙的一行指令語法，拓展成——喔，原來概念這麼簡單：它逐行讀取、切成欄位，如果符合篩選條件就執行你的動作。概念很簡單，但底下卻是個完整的程式語言。就這樣讓我靈感大開。

而當時我正好在玩解析和程式語言直譯相關的東西，我把兩者結合起來，心想我可以用 Go 來寫個 AWK 的小小子集試試。於是我就動手了——一開始只寫了個極簡版的 AWK，只支援單一篩選條件和單一動作，然後就越加越多，直到某天我意識到，啊，乾脆把它做成一個完整的 POSIX 實作好了。那時我們全家在紐約住了大約 10 年——我每天通勤到市區上班，公車轉地鐵單程就要一個小時。所以我每天早上在公車上坐個三、四十分鐘，就在那上面埋頭寫我的 GoAWK 專案。所以它真的是在開往紐約的 New Jersey Transit 公車上寫出來的。

Jim：那你是怎麼會被納入新版《The AWK Programming Language》第二版的呢？

Ben：對，那是——我想我和 Brian Kernighan 的第一次聯繫，是我看到一個 Kernighan 的訪談，他提到 AWK，以及他正在更新他那個被稱為「唯一正宗的 AWK（one true AWK）」的版本，要加入對 CSV（逗號分隔值） 檔案的支援。而那也是我想在 GoAWK 裡加入的功能。或者也許當時我已經加好了？我忘了時間順序。我確實有在 GoAWK 裡加入 CSV，我忘了確切的時間點，但我看到那個訪談時心想，哇，我也在做同樣的事。

所以我開始看 Brian 的程式碼，Kernighan 的程式碼，心想太好了，他也在做一樣的事。然後我發現了一些我認為是效能問題的地方——我想那確實是合理的效能疑慮——關於他處理 UTF-8 的方式。那也是他當時正在做的另一件事：CSV 和為 AWK 加入 UTF-8 或 Unicode 支援，時隔這麼多年。順帶一提，AWK 其實本來就能很好地支援 Unicode，只要你處理的是 UTF-8，因為 UTF-8 是 Unicode 的一種 8 位元編碼，所以只要你不是逐字元處理 Unicode 字元，大多數情況下都運作得很好。所以大多數 AWK 腳本即使在舊版 AWK 上也能正常運作，但有某些功能需要逐字元處理，所以那正是他要加入的東西。

所以如果你要取得字串長度，在逐字元的 Unicode 處理下，你會想要取得字串中 Unicode 字元的數量，而不是位元組數。而效能問題就在於，strlen 函式——也就是 AWK 裡的 length 函式——會變成一個線性時間（order-N）的操作，會隨著字串長度線性成長，因為它必須逐一走訪位元組並解碼 UTF-8，才能算出裡面有多少字元。

所以字串的 length 操作就從一個 order-1、超快的常數時間操作，變成一個跟字串長度成線性關係的操作。而大多數時候這沒什麼關係，因為字串都很短，但如果你在用 AWK 處理 JSON 檔，或做些你本來不該用 AWK 做、但有些人還是會做的事——像是處理很長的字串——那麼如果你在迴圈裡重複做 length，很快就會變成 N 平方的問題，因為你在迴圈裡做 length，突然間就變成不自覺的 N 平方問題。所以，長話短說，我把這個問題提出來了。

我在 GoAWK 裡也曾改成類似的 Unicode-aware 做法，也把 length 改成了 order-N 的操作，結果有個使用 GoAWK 的人說：「啊，這把我的腳本搞壞了，因為它讓我的小 JSON 處理器在處理一個中等大小的 JSON 檔時要跑 25 分鐘！」就是因為這種指數型的行為。所以我在 GoAWK 裡又把那個改動撤回了，心想，不行，這太棘手了，我還是回到以位元組為準。也就因為我在 GoAWK 裡已經踩過這個坑，我才去聯繫 Kernighan 說：「聽著，我在 GoAWK 裡碰到這個效能問題，你大概也會把某些類型的 AWK 用法——像是處理 JSON——的效能給拖垮。」他也承認那是個問題；他最後決定不撤回，他說：「我想保留這個行為，我不認為會影響到太多腳本。」他可能是對的——大多數實際使用上不會受到影響，但那確實是個小小的效能陷阱。

所以就是這樣開始跟 Kernighan 聊起 AWK 的事，過了幾年，我想他有看到 GoAWK 上我的名字，也肯定這個專案，所以當他在重做他的書、也就是《The AWK Programming Language》第二版時，他就寫 email 來問我：「嘿，你要不要來審閱這本書，當技術審校者之一？」

Jim：那一定是很棒的感覺。

Ben：對啊，真的很棒。你知道，能把自己的名字列在 Kernighan 的書的技術審校名單裡，是有點值得驕傲的時刻。

Jim：的確如此。那麼 Ben Hoyt 接下來有什麼計畫呢？

Ben：我目前在 Canonical 工作，他們大量使用 Go 和 Python。其實我會進 Canonical 也是透過 GoAWK 這個專案。對我來說那只是個 side project，但 Canonical 裡一位職位不低的人主動聯繫我說：「嘿，我在 Canonical 裡做一個小 side project 有用到你的 GoAWK，滿酷的。對了，你有在找工作嗎？」

而那時我剛好也在留意工作機會，所以就這樣進了 Canonical。你知道，我在工作上其實沒有真的在用 GoAWK，它在 Canonical 並沒有被實際採用，但它幫我得到了這份工作。所以我現在就是這樣：在 Canonical 做雲端、網路和基礎架構相關的事，目前主要是用 Python，但他們也大量使用 Go，所以我參與的一些專案也有用到 Go。兩種主要語言我都會用到。

Jim：對 Rust 或 Zig，或那些正逐漸受歡迎的語言有興趣嗎？

Ben：我一直有在關注 Rust，我喜歡它的願景——我喜歡它的承諾，但討厭它的語法。你知道，那種由定義而來的安全性、或是透過型別系統來保證安全，以及它追蹤所有權（ownership）等方式。但我還沒學過，所以就不多做評論。它似乎有非常陡峭的學習曲線，學過 Rust 的人都承認這點，像是它的語法很多，所以大概——它沒那麼吸引我，但向那些開始使用它的人致敬。

不過 Zig 不知為何就很合我的思維模型，就我目前看到的而言。所以我對 Zig 滿有興趣的。據我目前的觀察，Zig 是個更好的 C，而 Rust 比較像是個更好的 C++，這是我大致的看法。所以我喜歡 Zig，喜歡我目前看到的 Zig——還沒實際用過——但那種明確性（explicitness）以及所有記憶體配置都被明確化的方式。它也用了 Go 的一些特性，那些是從 Go 借鑑來的。我喜歡 Zig 的樣子，很想去學學看。

Jim：還有其他想征服的世界嗎？

Ben：來看看——我有個小小的 side project，是一個叫 GiftyWeddings.com 的網站，那是個婚禮禮物清單網站，只是個好玩的小 side project，已經經營一陣子了。那某種程度上——它每個月能賺幾塊錢，你知道，就只是零用錢等級的收入——但我主要把它當作嘗試新語言和工具的試驗場。所以每隔一段時間我就會把後端或前端重寫，試試新工具。所以那一直是個不錯的——我就是透過那個 side project 學會 Go 的。

我最近在看 htmx，你有聽過那個函式庫或工具組嗎？它似乎正獲得不少關注，而我還滿喜歡它的運作方式——你知道，保留你現有的後端工具、保留 HTML，然後去擴充它，而不是「讓我們用一堆 JavaScript 來取代它」。當然它還是會用到 JavaScript，但它是種很不一樣的模式——對，我覺得 htmx 看起來不錯。所以我想試試看，也許會在我的 Gifty Weddings 專案上試。

Jim：很好。Ben，謝謝你今晚的時間，很高興跟你聊聊。