Advent of Code के लिए Gleam इस्तेमाल करने का अनुभव

• Advent of Code 2025 के 12 दिनों की पहेलियों को Gleam में हल करते हुए, भाषा के Rust-स्तर के error messages और pipeline-केंद्रित functional style विशेष रूप से प्रभावशाली लगे
• echo, fold_until, list.transpose जैसी built-in functions ने debugging और combination problems को हल करना आसान बनाया, और option type-आधारित safety grid puzzles को संभालने में उपयोगी रही
• standard library में file IO और regex features शामिल न होना, list pattern matching की सीमाएँ, और explicit comparison syntax जैसी बातें बार-बार उपयोग में असुविधाजनक लगीं
• Erlang VM और JavaScript target के बीच integer handling के अंतर के कारण bigi का उपयोग करना पड़ा, और कुछ puzzles में external tool (glpsol) को कॉल करके समस्या हल की गई
• कुल मिलाकर, functional सोच में बदलाव ने puzzle solving को अधिक स्पष्ट बनाया, और Gleam को वास्तविक projects (जैसे web server development) में आज़माने की इच्छा व्यक्त की गई

---

Advent of Code 2025 और Gleam का चयन

• हर साल Advent of Code पूरा करने वाले लेखक ने इस बार Gleam भाषा चुनकर 12 दिनों की पहेलियाँ हल कीं
  • इस वर्ष आयोजन 25 दिनों के बजाय 12 दिनों तक सीमित था, और हर समस्या की कठिनाई अधिक थी, लेकिन सीखने के लिए इसकी संरचना उपयुक्त रही
• puzzles तेज़ी से आगे बढ़े और toolset पूरी तरह तैयार होने से पहले ही जटिल समस्याएँ सामने आ गईं, जिससे यह नई भाषा सीखने के लिए आदर्श वातावरण बन गया

Gleam के भाषाई फायदे

• इसकी खासियतें हैं संक्षिप्त syntax, उपयोगी compiler error messages, और Rust-स्तर का मददगार feedback
• pipe operator पर आधारित functional style, AoC समस्याओं की संरचना (parsing→transform→fold) से बहुत अच्छी तरह मेल खाती है
• IntelliJ के लिए Gleam extension और LSP स्थिर रूप से काम करते रहे, जिससे development environment आरामदायक रहा
• functional programming (FP), imperative code की तुलना में सोच को समस्या के मूल स्वभाव को व्यक्त करने के तरीके की ओर मोड़ती है

प्रमुख फीचर्स और code उपयोग के उदाहरण

• echo: pipeline के बीच में value देखने के लिए एक साधारण output function, जिससे string formatting के बिना debugging संभव हुई
  • string interpolation feature न होने के कारण text बनाते समय <>" operator का अधिक उपयोग करना पड़ा, जिसे असुविधा के रूप में बताया गया
• option type (dict.get): grid puzzles में boundary checks के बिना सुरक्षित neighbor traversal संभव हुआ
• list utilities
  • list.transpose: matrix transpose operation के जरिए puzzle structure सरल हुई
  • list.combination_pairs: 3D point pairs बनाते समय nested loops के बिना एक पंक्ति में काम हो गया
  • fold_until: शर्त पूरी होने पर जल्दी समाप्त होने वाली fold function, जो puzzle iteration calculations में प्रभावी रही

Gleam की सीमाएँ और असुविधाएँ

• standard library में file IO का अभाव, जिसे simplifile package से पूरा किया गया
• regex functionality के लिए भी external dependency (gleam_regexp) की ज़रूरत पड़ी
• list pattern matching की सीमाएँ: [first, ..middle, last] जैसे रूप संभव नहीं हैं
• comparison operations का explicit handling: order type का उपयोग करना पड़ता है, जिससे साधारण comparisons में syntax लंबा हो जाता है

उन्नत उपयोग और puzzle-विशेष उदाहरण

• bigi: JavaScript target में integer overflow से बचने के लिए उपयोग किया गया
• XOR bitmask: Day 10-1 में light toggle समस्या को XOR operation से model करके प्रभावी ढंग से हल किया गया
• glpsol call: Day 10-2 में linear equations हल करने के लिए LP file बनाकर external command चलाई गई
• memoization key: Day 11-2 में node और state को साथ में key के रूप में उपयोग किया गया, जिससे तुरंत computation पूरी हो गई
• अंतिम puzzle input assumptions पर निर्भर थी, और इसे साधारण area comparison (heuristic_area <= max_area) से हल किया गया

निष्कर्ष और आगे की योजना

• Gleam ने standard library की सीमाओं के बावजूद safety और expressiveness में मजबूत पक्ष दिखाए
• pipelines, option/result types, list functions, fold_until जैसी चीज़ों ने puzzle solving को अधिक स्पष्ट बनाया
• आगे web server development जैसे वास्तविक projects में उपयोग की योजना है, और अगले साल के Advent of Code में भी Gleam का उपयोग जारी रखने की इच्छा जताई गई
• पूरा source code GitHub repository में सार्वजनिक है (tymscar/Advent-Of-Code/2025/gleam/aoc/src)

[GN⁺]

Hacker News की राय

• Gleam सचमुच एक खूबसूरत language है। लगता है Elixir को type system के मामले में इसी दिशा में विकसित होना चाहिए था
  Gleam भी Erlang VM BEAM पर चलता है, और इसकी वजह से concurrency और queue handling बहुत आसान हो जाती है
  ecosystem भी शानदार है। लेकिन LLM युग के बाद से लगता है कि 2021 के बाद language development रुक-सा गया है, यह चिंता रहती है
  फिर भी Gleam उस दरवाज़े के बंद होने से ठीक पहले अच्छी तरह आ गया, और उम्मीद है कि LLM भी जल्द इसकी बराबरी कर लेंगे

  • यह जानने की जिज्ञासा है कि आपको क्यों लगता है कि LLM language development को रोक रहे हैं। नए models में इस साल तक का ज्ञान शामिल है, और वे कुछ examples मिलने पर नई languages भी काफ़ी अच्छी तरह सीख लेते हैं
    languages syntax और philosophy के स्तर पर पूरी तरह अलग नहीं हो सकतीं, इसलिए शायद यह कोई बहुत बड़ी समस्या नहीं है
  • यह कहना ठीक नहीं है कि Gleam OTP के ऊपर बना है। Erlang VM BEAM है, और OTP Erlang की libraries और design principles का संग्रह है
    Gleam अपने स्तर पर type-safe OTP subset देता है। संबंधित library के लिए gleam-lang/otp देखें
  • सही है, Erlang VM BEAM है, OTP नहीं। Gleam का OTP implementation Elixir या Erlang जितना परिपक्व नहीं है
  • मैंने भी हाल ही में Elixir में LLM features वाला अपना पहला project बनाया, और उल्टा लगा कि यह रुझान language adoption को बढ़ावा भी दे सकता है
  • Elixir भी धीरे-धीरे set-theoretic typing अपना रहा है। संबंधित दस्तावेज़: gradual-set-theoretic-types

• इस साल Advent of Code मैंने Gleam में हल किया, और यह काफ़ी प्रभावशाली लगा
  फ़ायदों में performance अच्छी है, और language server हैरान करने लायक मज़बूत है। auto formatting, auto import, pattern matching completion जैसी चीज़ों के कारण development experience बेहतरीन है
  कमियाँ यह हैं कि formatter code को ज़रूरत से ज़्यादा vertical बना देता है, और simplicity पर ज़ोर होने से list.map जैसी दोहराई जाने वाली लिखावट बहुत होती है। साथ ही library ecosystem अभी कमज़ोर है

  • मैं भी performance देखकर हैरान था। C जितनी नहीं, लेकिन उम्मीद से काफ़ी तेज़ है। language server भी लगभग हर IDE में अच्छी तरह काम करता है
    list.map को import gleam/list.{range, map} जैसे लिखकर छोटा किया जा सकता है। C libraries को port करना भी दिलचस्प हो सकता है
  • ये कमियाँ झेली जा सकती हैं, लेकिन if/else या guard न होना असुविधाजनक है। boolean branching बहुत verbose हो जाती है
  • मैंने AoC F# में किया था, और अनुभव मिलता-जुलता था। List.map जैसी namespace repetition discoverability को कम कर देती है
  • argument formatting शायद Prettier algorithm की वजह से है। फिर भी मेरे हिसाब से यह clang-format के binpacking से कहीं बेहतर है

• मुझे Gleam पसंद है, लेकिन recursive function call restrictions खटकती हैं। internal function calls उतनी स्वतंत्र नहीं हैं
  syntax के लिहाज़ से यह Scheme जितना elegant नहीं है, और conceptually Erlang से अधिक सरल है। फिर भी static typing इसका फ़ायदा है
  मैंने OCaml भी इस्तेमाल किया है, लेकिन opam lock file की समस्या जैसी वजहों से environment reproducibility कमज़ोर लगी। लगता है SML ecosystem और बड़ा होना चाहिए था

  • मेरी भी लगभग यही राय है। Haskell सिद्धांत में शानदार है, लेकिन साधारण hello world भी resource consumption के मामले में भारी पड़ता है
    Idris 2 में dependent types और सुंदर design है, लेकिन ecosystem छोटा है, और PureScript Haskell से ज़्यादा practical होते हुए भी JS runtime से बँधा है
  • अगर आपको ML family पसंद है, तो ReScript v12 की सिफ़ारिश करूँगा। यह OCaml और Gleam के बीच संतुलित जगह पर है

• echo feature को देखकर लगा कि debugger में ऐसी intermediate result inspection सुविधा default रूप से होनी चाहिए
  array slice या filter chain के बीच के results code बदले बिना देख पाना अच्छा होगा
  और 2D array को grid की तरह इस्तेमाल करना अक्षम लगता है। 1D array + boundary info अधिक सुरक्षित और कुशल है

• मैं Gleam को ज़्यादा नहीं जानता, लेकिन list.map(fn(line) { line |> calculate_instruction })
  क्या इसे बस list.map(calculate_instruction) नहीं लिखा जा सकता?

  • हाँ, सही है। मैं भी कभी-कभी ज़्यादा जटिल processing लिखकर बाद में मिटा देता हूँ और वह रूप रह जाता है
  • जी, बिल्कुल सही

• Gleam एक शानदार language है। मुझ पर इसका बहुत गहरा असर नहीं पड़ा, लेकिन लोगों को इसे पसंद करते देख अच्छा लगता है
  लगता है Gleam + Lustre का मेल एक नया Elm बन सकता है

  • backend developer के रूप में Elm आकर्षक था, लेकिन creator के साथ टकराव और releases रुक जाने की वजह से उससे दूरी बन गई। फिर भी उसकी architecture दूसरे projects में भी उपयोगी रही
  • मैंने भी हाल ही में Gleam + Lustre से एक छोटा app बनाया, और वह Elm + PostgREST से काफ़ी बेहतर रहा। अब इसे बड़े projects में भी इस्तेमाल करने का इरादा है
  • मैंने Lustre को देखा, लेकिन ecosystem अभी छोटा है। authentication से जुड़े examples भी नहीं थे, इसलिए LiveView चुना। फिर भी ergonomics अच्छी है, इसलिए उम्मीद है यह बढ़ेगा

• आजकल LLM के दौर में यह सोचता हूँ कि क्या नई language सीखना अभी भी मूल्यवान है
  अगर LLM ने उस language को नहीं सीखा है, तो डर है कि tool के रूप में उसकी utility कम हो जाएगी

  • लंबी अवधि में अगर LLM नई languages सीख ही नहीं पाते, तो general intelligence के लक्ष्य में वे असफल माने जाएँगे
  • 1–2 साल पहले ऐसी चिंता थी, लेकिन अब Claude Code Elixir code भी काफ़ी अच्छा लिखता है। training data कम हो तब भी यह बड़ी समस्या नहीं है
  • Claude Gleam को भी अच्छी तरह संभालता है। documentation और diagnostic message quality अच्छी होने से LLM के लिए सीखना आसान है। यह Rust स्तर के diagnostics देता है
    वहीं Swift का syntax जटिल है, इसलिए LLM के लिए उसे संभालना कठिन है
  • अगर language को एक tool की तरह देखें, तो market demand की कमी शायद उससे भी बड़ी सीमा हो सकती है
  • उम्मीद है कि LLM की सीमाओं की वजह से नई languages रुकेंगी नहीं

• जब मैंने पहले Gleam को देखा था, तो लगा था कि इसमें dynamic dispatch (interface या type class) नहीं है; अब स्थिति क्या है, यह जानना चाहता हूँ

  • आम तौर पर इसे “function struct पास करो” जैसी शैली से हल किया जाता है। यह explicit approach है, और उल्टा generic complexity से मुक्ति देता है, जो अच्छा लगता है
  • Gleam first-class functions को support करता है, इसलिए dynamic dispatch संभव है। type class या interface आख़िरकार higher-order functions से ही व्यक्त किए जा सकते हैं

• [first, ..rest] या [first, second] संभव है, लेकिन [first, ..middle, last] नहीं।
  शायद cost ज़्यादा होने की वजह से इसे जानबूझकर रोका गया है

• शुक्र है कि blog title police जल्दी पहुँच गई
  संबंधित लिंक