背景

Gleam 是一門新興的函數式程式語言，其語法深受 Rust 啟發，並能編譯至 Erlang 或 JavaScript 平台。然而，Gleam 目前並未原生支持將專案打包成單一執行檔的功能，這對於希望簡化部署流程或分發工具的開發者來說是一大挑戰。本文作者透過實驗多種工具，探討了如何利用 Erlang 的 escript、Elixir 的 Burrito，以及 JavaScript 生態系的 Deno、Node.js SEA 與 Bun 等方案，將 Gleam 專案封裝成獨立的二進位檔案。

社群觀點

針對這份技術指南，社群討論呈現出期待與現實之間的落差。有評論者指出，雖然這份整理提供了實用的操作路徑，但其本質上是將 Gleam 專案編譯後，再依賴其他語言生態系的工具進行二次加工，例如先轉譯為 JavaScript 再利用 JS 打包工具處理，或是轉為 escript 後再透過 Elixir 的 Burrito 封裝。這種做法雖然可行，但對於熱愛 Elixir 與關注 Gleam 的開發者而言，更希望看到的是 Gleam 官方生態系能更深入地整合這類功能，而非單純依賴外部工具鏈。

此外，社群也對不同打包方案的實務表現提出了進一步的需求。目前的討論認為，僅僅列出操作步驟是不夠的，開發者更關心的是不同方法所產生的最終結果差異。例如，使用 Bun 或 Deno 打包雖然極為便利且速度快，但由於內嵌了完整的運行環境，導致執行檔體積往往超過 100MB。評論者建議，若能針對各方案的建置時間、最終二進位檔案的大小、啟動速度以及執行效能進行高層次的對比分析，將會使這類指南更具參考價值。這種觀點反映出開發者在選擇打包工具時，除了考量開發體驗的便利性，也極為重視產出物的品質與資源消耗。

整體而言，社群對於 Gleam 能夠跨足不同運行環境的能力表示肯定，但也期待未來能有更具「Gleam 原生感」的解決方案。目前透過 JavaScript 目標進行打包被認為是相對成熟且快速的路徑，特別是 Bun 的整合體驗受到好評，但在追求極致效能或輕量化部署的場景下，如何優化 Erlang 目標的打包流程，仍是開發者社群持續關注的議題。