Gleam: Erlang VM पर एक type-safe भाषा
Erlang VM के लिए एक नई statically typed, ML-शैली की भाषा, Gleam का लक्ष्य मज़बूत type safety को BEAM की प्रसिद्ध concurrency और fault-tolerance के साथ जोड़ना है, साथ ही JavaScript में compile करना भी। टिप्पणीकार इसकी साफ़ syntax, Hindley–Milner type system, Rust-आधारित compiler, और बढ़ते ecosystem की प्रशंसा करते हैं, लेकिन OTP maturity, testing tools, और C#, Java, या TypeScript जैसी mainstream stacks की तुलना में niche भाषा पर दांव लगाने से होने वाले लंबे‑अवधि के hiring जोखिमों पर सवाल उठाते हैं। वेबसाइट पर परियोजना की स्पष्ट राजनीतिक स्थिति भी इस बहस को जन्म देती है कि क्या ऐसे संदेश तकनीकी tooling में होने चाहिए।
Gleam और BEAM के बारे में समग्र भावना
- कई टिप्पणीकार उत्साहित हैं: BEAM पर type-safe ML-शैली की भाषा, JS compilation, अच्छा समुदाय, बढ़ता ecosystem।
- कुछ लोग इसे Rescript के लिए एक मज़बूत विकल्प और Phoenix/LiveView के लिए एक अच्छा complement मानते हैं।
- कुछ लोग BEAM को लेकर उत्सुक हैं लेकिन production में चलाने को लेकर हिचकिचाते हैं, BEAM को एक “black box” मानते हैं; जबकि अन्य जवाब देते हैं कि BEAM के पास उत्कृष्ट introspection और debugging tools हैं और इसे Node/JVM की तुलना में अक्सर inspect करना आसान होता है।
Type system और language design
- Type system Hindley–Milner है, Haskell की तुलना में OCaml के करीब: algebraic data types, generics, type aliases; type classes नहीं, purity नहीं।
- कुछ लोगों को यह “barebones” लगता है और वे structural/set-theoretic types चाहते हैं; अन्य पूछते हैं कि इससे कौन-सी वास्तविक समस्याएँ हल होंगी।
- Pattern matching को मज़बूत माना गया है; syntax को सामान्यतः साफ़-सुथरा सराहा गया है।
- Labelled arguments पर व्यापक चर्चा हुई: कुछ इसे delightful मानते हैं और readability तथा API design के लिए अच्छा; अन्य इसे अतिरिक्त जटिलता और redundancy मानते हैं।
- Pipe operator का व्यवहार (first arg के रूप में auto-inserting) विवादास्पद है: कुछ brevity पसंद करते हैं, जबकि अन्य को लगता है कि इससे clarity कम होती है।
- Elixir की तुलना में function overloading की कमी पर संक्षेप में अफ़सोस जताया गया।
OTP, ecosystem, और interop
- Native OTP support
gleam_otpऔरgleam_erlangके माध्यम से है; इसे experimental बताया गया है लेकिन production में पहले से उपयोग हो रहा है, जिसमें एक webserver भी शामिल है जो Cowboy से तेज़ बताया गया। - नीचे का सारा OTP अभी भी FFI के जरिए उपलब्ध है।
- Rust NIFs और ports उपलब्ध हैं (जैसे Rustler जैसे tools के माध्यम से), लेकिन इन्हें BEAM के process/scheduler model में फिट करने के लिए सावधानी चाहिए।
Tooling, implementation language, और Rust में compilers
- Gleam Rust में लिखा गया है और Rust-आधारित language implementation के एक मज़बूत उदाहरण के रूप में उद्धृत किया गया है।
- Thread में compiler work के लिए Rust बनाम Haskell/OCaml के pros/cons पर चर्चा है: Rust ecosystem (parsers, LSP, diagnostics, incremental tooling) की प्रशंसा की गई है, लेकिन कुछ लोगों को ASTs के लिए Rust के enums/ownership awkward लगते हैं।
Language choice, hiring, और “non‑mainstream” stacks
- एक दृष्टिकोण: ordinary businesses में niche BEAM languages का उपयोग hiring को नुकसान पहुँचाता है और costly rewrites के लिए मजबूर कर सकता है; mainstream stacks (C#, Java, Python, TypeScript, शायद Go) “safer” हैं।
- counter-view: ability के आधार पर hire करें, भाषा सिखाएँ; Erlang/Elixir सीखना आसान है, और non‑mainstream stacks बेहतर caliber के developers आकर्षित कर सकते हैं। कई anecdotes का दावा है कि Elixir hiring और onboarding कठिन नहीं हैं।
Use cases और “typed scripting” debate
- कुछ लोग Gleam को typed scripting option के रूप में चाहते हैं; अन्य तर्क देते हैं कि BEAM और explicit types quick scripts के लिए string-centric shells की तुलना में खराब fit हैं, लेकिन बड़े distributed systems के लिए उत्कृष्ट हैं।
Testing story
- Testing वर्तमान में
gleeunitपर केंद्रित है, जो JS target पर भी काम करता है। - यह जानबूझकर minimal है; mocks को जानबूझकर support नहीं किया गया है, और dependency injection को प्राथमिकता दी गई है। कुछ उपयोगकर्ता अधिक guidance या features चाहते हैं।
Community guidelines और politics
- Project site सामाजिक/राजनीतिक स्थितियाँ स्पष्ट रूप से बताती है (जैसे anti-racist/anti-fascist, pro-trans rights)।
- इससे एक side debate शुरू होता है: कुछ लोग इसे project values की उपयुक्त अभिव्यक्ति मानते हैं; अन्य इसे polarizing मानते हैं और कहते हैं कि वे इसी वजह से इसका उपयोग नहीं करेंगे या हतोत्साहित करेंगे। दोनों पक्ष एक-दूसरे पर technical spaces में “bringing politics” का आरोप लगाते हैं।