背景

Lily 是一款專注於表達力與型別安全的直譯式程式語言，其核心特色包含內建模板模式、可嵌入 C 語言環境、單繼承類別、泛型以及代數資料型別。這款語言在 Hacker News 上引發了關於「腳本語言是否需要靜態型別」以及「開發新語言的必要性」的深入討論。

社群觀點

針對 Lily 的出現，社群最直接的反應是追問其存在的必要性。許多開發者指出，當前技術領域已存在大量成熟的語言，如 Python、Ruby 或 Lua，若新語言無法清楚說明其解決了哪些現有痛點，很難吸引使用者。部分留言者認為，Lily 試圖在腳本語言的靈活性與靜態型別的安全性之間取得平衡，這確實是一個值得探索的方向。支持者認為，型別化腳本語言可能是未來的趨勢，因為它們能在開發早期透過型別檢查偵測錯誤，避免在生產環境中出現低級失誤。

然而，關於「腳本語言」的定義與效能，社群內部存在顯著分歧。有觀點質疑，若一個語言需要經過複雜的編譯或型別檢查，是否還能稱之為腳本語言；相對地，也有人反駁「腳本」僅是一種應用場景，無論是 Rust 還是 C，只要工具鏈整合得當，都能勝任腳本任務。在效能方面，有開發者分享了現代即時編譯（JIT）技術的進步，指出像 F# 這樣的語言在特定場景下效能已逼近 C 或 Rust，打破了直譯語言必然緩慢的舊有偏見。

在功能對比上，Lily 提供的代數資料型別與泛型成為討論焦點。雖然有留言者認為 Ruby 或 Python 透過鴨子型別或第三方套件也能達成類似效果，但反對者指出，語言層級的原生支援與編譯時期的型別檢查，在開發體驗上與執行時期的動態處理有本質上的差異。此外，Lily 採用的引用計數結合垃圾回收機制來處理循環參照的設計，也被認為是借鑒了 Lua 等嵌入式語言的優點並試圖改進。

最後，討論也延伸到了人工智慧對程式語言發展的影響。部分開發者預測，未來可能會出現專為 AI 代理人設計的語言，優化 Token 消耗並提高生成準確度。但也有人持保留態度，認為 LLM 需要大量的訓練數據，新語言若缺乏生態系與代碼庫，反而難以被 AI 有效利用。對於許多開發者來說，創造新語言往往帶有一種「詩意」的創作衝動，即便 99% 的新語言最終可能無法普及，這種探索過程本身仍具備技術價值。

延伸閱讀

在討論過程中，社群成員提到了多個與 Lily 定位相似或值得參考的專案：

• Luau：由 Roblox 開發的 Lua 方言，具備靜態型別支援，已在大型遊戲專案中得到驗證。
• mruby：專為嵌入式設計的輕量級 Ruby 實作，易於與 C 語言整合。
• Teal 與 Nelua：為 Lua 提供型別系統的不同嘗試。
• Terra：一種嵌入在 Lua 中的低階語言，常用於高效能元程式設計。
• Pallene：與 Lua 深度整合的系統程式語言，旨在提供接近 C 的效能同時保有 Lua 的易用性。