Gleam अब Erlang source में compile नहीं करता

Gleam, जो Erlang VM और JavaScript को target करने वाली एक statically typed functional language है, ने अपना Erlang backend बदलकर human-readable Erlang source के बजाय Erlang abstract forms (एक AST format) emit करना शुरू किया है। Commenters इसे एक तकनीकी maturation मानते हैं जो Gleam को अन्य BEAM languages के साथ align करता है, जबकि compilation targets, performance, और tooling के आसपास design trade-offs पर भी फिर से चर्चा होती है। बातचीत में Gleam की बढ़ती अपील—खासकर web services और JS के साथ full-stack उपयोग—के साथ-साथ इसकी community, simplicity, और evolving ecosystem की प्रशंसा भी शामिल है।

Gleam के Erlang Backend में बदलाव

  • Gleam अब human-readable Erlang source के बजाय Erlang “abstract forms” (Erlang compiler AST/IR) emit करता है।
  • कई commenters बताते हैं कि यह वही representation है जो BEAM ecosystem में व्यापक रूप से इस्तेमाल होती है (Elixir और parse transforms सहित)।
  • एक commenter शुरू में source text generate करने के पुराने विकल्प की आलोचना करता है, उसे redundant और error-prone कहता है।
  • एक core contributor मूल निर्णय समझाता है: उस समय abstract forms स्पष्ट “standard” नहीं थे, Core Erlang का API बाहरी Rust compiler के लिए stable नहीं था, और source emit करने से Erlang तक एक escape hatch मिलता था तथा Erlang के build tools का लाभ लिया जा सकता था।
  • अब Gleam सीधे Erlang Term Format लिखता है; अभी भी एक Erlang source generator मौजूद है, मुख्यतः tests के लिए।

“Transpiler” बनाम Compiler

  • लेख का यह point कि “transpiler” अपने-आप में pejorative नहीं है, बहस छेड़ता है।
  • कुछ लोग नोट करते हैं कि पुराना pipeline वास्तव में खराब था, लेकिन implementation की वजह से, इसलिए नहीं कि वह source produce करता था।
  • अन्य तर्क देते हैं कि अगर abstract forms को फिर से Erlang text में pretty-print किया जा सकता है, तो “AST” और “source” का अंतर आंशिक रूप से semantic है।

Targets, Use Cases, और Interop

  • Gleam को एक general-purpose, statically typed, ML-like functional language के रूप में वर्णित किया गया है, जिसका लक्ष्य simplicity, safety, और अच्छा tooling है।
  • प्राथमिक server target: BEAM (Erlang VM)। द्वितीयक target: JavaScript, मुख्यतः web/front-end या अन्य JS-hosted contexts के लिए (जैसे Lustre web apps)।
  • एक commenter सवाल करता है कि यदि Gleam “UI के लिए” नहीं है तो JS target क्यों है; दूसरे जवाब देते हैं कि JS UI से परे भी व्यापक रूप से उपयोगी है, और server, SSR, और typed front end के लिए एक ही language होना आकर्षक है।
  • Elixir के साथ interop संभव है, लेकिन अलग type systems के कारण यह “seamless” नहीं है।

Native / अन्य Backends

  • कुछ लोग चाहते हैं कि Gleam native target पर compile हो (जैसे Rust, Go, C, Wasm, LLVM IR)।
  • एक core contributor तर्क देता है:
    • Rust एक खराब compile target है: compiler धीमा है, व्यापक रूप से installed नहीं है, और humans के लिए उसके design का backend IR के रूप में अच्छा मेल नहीं बैठता।
    • Go का GC और goroutine model Gleam की immutable, process-based शैली के लिए आदर्श नहीं है।
    • यदि native route अपनाया जाए, तो C, Wasm, LLVM, Cranelift जैसे lower-level IR अधिक उपयुक्त होंगे।
  • Gleepack जैसे तरीके से BEAM को single executable में bundle करना पहले से ही छोटे, portable binaries दे सकता है।

Language Comparisons और Learning Curve

  • तुलना: Gleam की तुलना Rust से अधिक OCaml/Standard ML/Elm/F# से की जाती है।
  • कुछ लोग सोचते हैं कि Rust users को Gleam syntax और pattern matching approachable लग सकती है; अन्य चेतावनी देते हैं कि Rust से आने वाली conceptual expectations (ownership, borrowing) transfer नहीं होतीं और confusion पैदा कर सकती हैं।
  • Erlang बनाम Elixir बनाम Gleam:
    • Gleam: typed, minimal, macros नहीं, function heads में pattern matching नहीं (simplicity के लिए एक trade-off)।
    • Erlang: कुछ लोगों द्वारा matchers/guards और आश्चर्यजनक रूप से pleasant syntax के लिए सराहा गया।
    • Elixir: macros, OTP integration, excellent REPL, और mature web framework के लिए valued; कुछ Rust users इसे Gleam की static typing के बावजूद पसंद करते हैं।

Community, Ecosystem, और Adoption

  • कई टिप्पणियाँ Gleam community की असाधारण friendliness की प्रशंसा करती हैं, जिसमें live streams और educational talks शामिल हैं।
  • Users real projects (जैसे web APIs/services, Gleam + Lustre + Tauri के माध्यम से apps) बनाने के अच्छे अनुभव बताते हैं।
  • कुछ लोग Gleam को अपना default stack बनते हुए देखते हैं; अन्य अफसोस करते हैं कि उनके पास work projects नहीं हैं जिनमें वे इसे इस्तेमाल कर सकें।
  • एक commenter चिंता जताता है कि LLM-based coding के युग में “LLM friendliness” niche languages के adoption के लिए gate बन सकती है, जिसे वे निराशाजनक मानते हैं।

Miscellaneous Side Threads

  • अंग्रेज़ी में comma usage और grammar norms पर विस्तृत tangent; निष्कर्ष: style अलग-अलग होती है, और formal contexts के बाहर अधिकांश लोग बहुत परवाह नहीं करते।
  • Gleam-generated code को WhatsApp Erlang debugger जैसे tools के साथ integrate करने पर छोटी चर्चा; compile flags पास होने पर इसे trivial माना गया।
  • Gleam की branding पर संक्षिप्त आलोचना कि यह “like girl toys” लगती है, जिस पर दूसरों ने इसे insecure और irrelevant बताया।