隨機焦點｜FoundationDB's Flow – Bringing・Show HN: Inkwell – 專為電子墨水裝置設計的・Flexible metaprogramming with

📰 1. FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

TITLE: FoundationDB的Flow：在C++11中實現基於Actor的並發

原文摘要

FoundationDB從一開始就給自己定了高標準：既要單節點的高性能，又要整個叢集的橫向擴展。工程師發現，他們需要的是一種像Erlang或.NET Async library那樣的高效率非同步通訊機制，但同時必須保有C++的原始速度與I/O效率。為了解決這個矛盾，他們打造了Flow——一套基於Actor模型的C++11框架。

Flow的核心概念包括：

Promise<T> 與 Future<T>：經典的承諾/未來模式，讓非同步操作可以鏈式組合。
wait()：類似協程中的暫停點，讓程式碼可以寫得像同步呼叫，實際是非同步。
ACTOR 關鍵字：標記一個函式為「Actor」，讓編譯器自動轉換成基於Promise/Future的狀態機。
PromiseStream<T> 與 FutureStream<T>：處理多個值的串流，對應 waitNext() 與 choose ... when 等選擇性等待。

Flow讓開發者能用接近同步程式碼的可讀性，寫出有效率且易於模擬測試的非同步邏輯。這套設計同時也支撐了FoundationDB著名的「模擬測試（Simulation）」方法論——在單機上模擬大規模叢集故障，以驗證容錯邏輯。

我的觀點

Flow在C++11的語法限制下，硬是擠出一套Actor風格的並發框架，確實是工程上的傑作，但我認為它終究是過渡方案，而非終極解答。

當年C++11還沒有完整的協程支援，Flow靠巨集和模板黑魔法（像是 ACTOR 關鍵字其實是透過巨集展開成複雜的狀態機）來模擬async/await行為。這讓程式碼的除錯體驗很痛苦——編譯器報錯訊息又臭又長，斷點也常常跳到奇怪的展開區塊。而且Flow的學習曲線很陡：新人得先搞懂Promise/Future的生命週期、隱含的堆積分配、以及actor之間的訊息傳遞順序，才能寫出正確的生產級程式碼。

但是，不能否認Flow對FoundationDB的核心貢獻：它讓一架構能在單C++執行緒上高效處理成千上萬個非同步連接，同時又保持狀態一致性。這種「無鎖Actor」的做法，本質上是一種更安全的並發模型——沒有鎖競爭，只有訊息佇列和排程器。比起手寫回呼（callback hell）或鎖來鎖去，Flow已經是天差地別的進步。

延伸思考

Flow的故事引發一個有趣的問題：在分散式資料庫這類需要極致效能的系統中，Actor模型真的比現代C++20的協程（std::coroutine）更適合嗎？

我傾向於認為，如果今天從零開始設計，很多團隊會直接選用C++20的協程（搭配Boost.Asio或自己寫的排程器），因為語言層級支援讓程式碼更乾淨，編譯器報錯也友善得多。但FoundationDB的歷史包袱是——他們早在C++17之前就啟動了開發，而Flow的成熟度經過長期打磨，已經與自家的模擬測試框架深度整合——要換掉幾乎等於重寫核心。

另一個值得思考的角度：Flow的設計後來影響了Apple的SwifNIO嗎？（雖然SwiftNIO更偏向事件循環而非Actor。）實際上，Apple在收購FoundationDB後，內部也將Flow的一些概念移植到其他專案。這證明即使語言生態演進，Actor-based非同步模型在需要高吞吐、低延遲的基礎設施軟體中，依舊是一帖成熟的藥方。

最後，Flow給我們的啟示是：當語言能力跟不上需求時，你可以用框架和程式碼生成（巨集、模板）來「擴張」語言的邊界——但這需要投入大量的工程精力去維護工具鏈。不是每個團隊都該學FoundationDB自己造輪子，但他們解決問題的思路（先釐清本質模型，再用最適合的語言手段實作）是放諸四海皆準的。

📝 編輯說：: 這篇文章在Hacker News上引發了C++社群對於「該不該自己實作協程框架」的熱烈討論，筆者認為最有價值的觀點是Flow證明了「即使語言不支援，好的架構設計依然能產出高品質的分散式系統」。

📰 2. Show HN: Inkwell – 專為電子墨水裝置設計的RSS閱讀器

🔗 原文連結

你還記得上次用 Kindle 內建瀏覽器上網的體驗嗎？慢、卡、圖片載不出來，連個 RSS 文章都看得心浮氣躁。Hacker News 上有人丟出了一個專案叫 Inkwell，說它是一個「為電子墨水裝置量身打造的 RSS 閱讀器」。我點進去看了一下，覺得這傢伙還真把痛點摸透了。

原文摘要

Inkwell 是一款自託管的 RSS/Atom 閱讀器，它的核心設計是：背景任務會預先提取每篇文章，並對所有嵌入圖片進行轉碼，然後把文章轉換成對 Kindle 內建瀏覽器友善的靜態 HTML。使用者點一下，裝置直接從本機磁碟抓取渲染好的內容。整個流程繞過了一般 RSS 閱讀器需要即時下載、渲染網頁的延遲，也避免了大型圖片塞爆電子墨水螢幕的問題。專案還提供 Docker 容器、反向代理設定、OPML 匯入、Kindle 認證等功能，基本上你想得到的自託管痛點它都幫你處理好了。

我的觀點

這個專案最值得注意的數字是「零等待渲染」——背景任務事先把每一篇文章轉成靜態 HTML，並且把圖像轉碼成灰階、重新調整尺寸。這看起來只是一個排程最佳化，卻直接解決了 Kindle 內建瀏覽器最大的瓶頸：即時渲染網頁時，CPU 太弱、記憶體太少、網路請求太多。Inkwell 的設計等於是把運算負擔從 Kindle 移到伺服器端，讓 Kindle 只負責顯示終端內容。這個取捨很聰明，但也帶來一個風險：如果背景任務沒跑完（例如新增了上百個 Feeds），使用者點開文章可能還是要等一下，或者看到快取失效的結果。不過考慮到這是一個自託管工具，伺服器在自己手上，排程週期可以調，風險不算致命。我的判斷是，Inkwell 是小眾市場的精品解決方案，特別適合那些已經在跑自託管服務（像是 NAS、樹莓派）的科技宅，而且你剛好有一台堆灰的 Kindle。

延伸思考

電子墨水裝置的應用場景其實一直被低估。大多數人只把 Kindle 拿來看書，卻忘了它天生適合「慢閱讀」——沒有通知干擾、沒有社群動態、沒有藍光疲勞。Inkwell 巧妙地填補了 Kindle 瀏覽器的缺陷，讓它也能變成一個還算堪用的資訊閱讀器。這也反映了自託管生態的一個趨勢：與其追求「所有裝置完美支援」，不如聚焦在「最難用的裝置上做出最佳體驗」。RSS 雖然老派，但在反演算法的聲浪中正悄悄回溫，而像 Inkwell 這類專注特定硬體的工具，反而能讓 RSS 的優勢（離線、無廣告、自由訂閱）重新被看見。如果你手上也有閒置的 e-ink 裝置，或許可以試著把它變成你的「專屬資訊終端」。

📝 編輯說：: 這篇文章在 Hacker News 上引發不少討論，筆者認為最有價值的觀點是「背景預提取 + 轉碼」這個架構設計，完全針對電子墨水裝置的硬體限制，是少數真的為爛瀏覽器環境優化的方案。

📰 3. Flexible metaprogramming with Rhombus

🔗 原文連結

TITLE:Rhombus：靈活的元程式設計

原文摘要

Rhombus 是 Racket 家族的新語言，目標很單純：把 Racket 那種強大的巨集（macro）與元程式設計能力，包進一套更像 Python 的語法裡，再給你合理的標準庫預設值。根據 LWN 報導，這個專案由猶他大學的 Matthew Flatt 與香港中文大學的 Wing Hei Chan 領軍，雖然兩位都在學術圈，但 Rhombus 不只是習題——6月22日剛慶祝 1.0 版本，已經有人用它來寫卡牌遊戲 Economancy 的工具。

核心技術上，Rhombus 幾乎就是騎在 Racket runtime 上，所以可以直接使用大量 Racket 函式庫，還有最佳化編譯器（直譯、bytecode、原生機器碼都能選）。它跟傳統 Lisp 最大的差別之一是資料結構：Lisp 很愛用單向鏈結串列（效率爆炸），Rhombus 改用不可變樹狀結構，讓多數操作的時間複雜度大幅降低。授權是 MIT 或 Apache 2.0，不過動態函式庫裡有 LGPL 3.0 程式碼。

我的觀點

如果你曾經在 Python 裡為了實作一句 DSL（領域特定語言）而寫了一堆裝飾器或 AST 黑魔法，或者你對 Lisp 那種「括號海」感到頭痛，但又不甘心放棄巨集的靈活性——那你應該會對 Rhombus 很有感。

我試玩了一下它的語法範例，真的滿像 Python：沒有括號地獄，用縮排區塊，list 長得像 [1, 2, 3]，dict 長得像 {"a": 1}。但上面那層語法只是糖衣，底下你依然可以隨時切到巨集模式，定義自己的語法結構。這種「語法可擴充」的設計在業界很少見——Elixir 的巨集很強，但得先適應 Erlang VM；Julia 的巨集也不錯，但效能調校門檻高。相比之下，Rhombus 給人的感覺是「把教育語言的親切度 + 頂級巨集系統」打包在一起。

當然，現實是血淋淋的：第一，Racket runtime 本身就很大，而且部分授權還是 LGPL，對商業封閉軟體可能有點麻煩。第二，社群還很小，別指望能在 Stack Overflow 找到一堆解答。但如果你是語言設計愛好者，或者想在專案裡偷偷用點元程式設計又不想嚇到同事，Rhombus 1.0 已經值得花一個下午玩玩。

延伸思考

Rhombus 的出現提醒我們：元程式設計一直不是「非黑即白」的事。Lisp 社群證明巨集可以讓程式碼極度優雅，但也讓初學者嚇跑；主流語言則選擇保守，頂多給點反射或 annotation 就收手。Rhombus 想走中間路線：保留巨集的威力，但把語習慣穿成「普通人」的樣子。

這條路有沒有商業潛力？我認為短期內很難，因為開發工具鏈（IDE支援、debugger、套件管理器）才剛開始。但從教育角度看，Rhombus 很適合拿來教「程式語言是如何設計的」——學生可以先用 Python-like 語法寫程式，再逐步學習如何自訂語法，而不用被母語的括號轟炸。未來如果 Racket 基金會願意認真推廣，或許能像 Julia 那樣在小眾領域（例如研究、腳本語言改造）站穩腳跟。

📝 編輯說：:筆者認為這篇報導最有價值的觀點是Rhombus試圖在不犧牲巨集能力的前提下解決傳統Lisp語法的痛點，對所有對語言設計有興趣的開發者都有啟發。

📚 本日原文來源

本文由JK Space News彙整，不代表任何投資建議。