背景

Skir 是一款由具備十五年 Protocol Buffer 使用經驗的開發者所推出的現代化數據定義語言。它旨在解決 Protobuf 在開發體驗、模式演進（Schema Evolution）以及跨語言一致性上的痛點，提供單一來源的數據類型定義，並能自動生成 TypeScript、Python、Java 與 C++ 等語言的原生代碼。

社群觀點

Hacker News 社群對於 Skir 的出現展現了兩極化的反應。支持者認為 Skir 在語言設計上確實觸及了 Protobuf 長久以來的軟肋，特別是其「嚴格構造函數」的設計。在 Protobuf 中，新增欄位往往會導致現有代碼保持默認值而不會報錯，這在大型生產環境中曾引發多起事故；而 Skir 強制開發者在新增欄位後更新所有構造調用點，這種編譯時的約束被認為是更安全的預設行為。此外，Skir 將 Rust 風格的列舉（Enum）與聯合類型（Oneof）統一，也被視為比 Protobuf 更優雅且現代的語言設計。

然而，質疑聲浪主要集中在「遷移成本」與「必要性」上。部分資深開發者指出，要讓團隊放棄已經身經百戰且生態豐富的 Protobuf，新工具必須具備十倍以上的效能或生產力提升，而 Skir 目前看來更像是對 Protobuf 的精緻改良而非革命性突破。針對 Skir 推崇的「緊湊 JSON」（Dense JSON）格式，社群也展開了激烈的辯論。雖然這種格式在體積與可讀性之間取得了折衷，但反對者擔心一旦失去 Schema，人類將完全無法解讀如數組般的數據，這在除錯與日誌分析上可能成為災難。

關於開發工具的成熟度，社群成員也提出了務實的批評。有人發現官方文檔中的語法範例與實際解析器不符，這對於強調類型安全與嚴謹性的工具來說是個不小的打擊。同時，目前版本尚缺乏 Go、Rust 與 Swift 等主流後端與行動端語言的支持，這限制了它在多語言微服務架構中的實用性。作者對此回應表示，這些語言已列入開發時程，並強調 Skir 的定位並非要取代所有已存在的 Protobuf 項目，而是為新專案提供一個更符合現代開發直覺、具備內建包管理器且更易於維護的替代方案。

最後，關於產品定位的討論也十分有趣。有留言建議作者將標語從「比 Protobuf 更好」改為「更清新的 Protobuf 替代品」。這反映了技術社群的一種共識：一個僅有數月歷史的專案很難在穩定性上宣稱超越累積數十年工程經驗的工業標準，但它確實可以憑藉著「後發優勢」，避開前輩留下的歷史包袱，提供更簡潔、易於理解且符合現代工程實踐的開發體驗。

延伸閱讀

在討論串中，開發者們也推薦了其他值得關注的序列化與 RPC 方案。Cap'n Proto 被多次提及，特別是其創作者 Kenton Varda 近期推出的 Cap'n Web，它針對 Web 環境優化並支持承諾流水線（Promise Pipelining）技術。此外，OpenRPC 被推薦給需要集中化錯誤定義與 RPC 規範的團隊；而對於追求極致數據吞吐量的場景，Apache Arrow Flight 與 wRPC 則是更具競爭力的選擇。針對 Protobuf 的現代化增強，buf.build 提供的插件系統也被視為在不更換底層協議下提升開發體驗的成熟方案。