Golang का इस्तेमाल जारी रखने के लिए हम खुद से बोले जाने वाले झूठ (2022)

 (fasterthanli.me)
3 पॉइंट द्वारा GN⁺ 2024-11-27 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Go की आलोचना पर बार-बार आने वाले “बड़ी कंपनियां भी इस्तेमाल करती हैं”, “इसमें अच्छी बातें भी हैं”, “सटीकता की लागत बड़ी है” जैसे जवाब language design की खामियों के लंबे समय में लागत बनकर जमा होने वाले मुद्दे को धुंधला कर सकते हैं
  • Go में async runtime, GC, package management, refactoring और cross-compile tools मजबूत हैं, लेकिन इसके साथ custom toolchain और build system, calling convention, एकमात्र GC, और ecosystem भी अपनाने पड़ते हैं
  • sum type की कमी, mutability control की कमी, zero value, और nil slice·map·channel के अलग-अलग व्यवहारों के कारण compiler कई invariant conditions की रक्षा नहीं कर पाता
  • cgo के बिना दूसरी भाषाओं·tools के साथ integration मुश्किल है, और cgo इस्तेमाल करने पर GC और pointer rules, runtime शामिल करने, और बड़ी static library का बोझ आता है, इसलिए network boundary सबसे व्यावहारिक integration point बनती है
  • “prototype सिर्फ Go में बनाकर बाद में rewrite कर देंगे” वाली उम्मीद असल में rewrite से बचने, मौजूदा Go code के साथ coupling, linter·documentation·manual verification के बोझ के कारण operational cost बढ़ा सकती है

Go आलोचना पर बार-बार दोहराई जाने वाली बचाव-तर्क

  • 2020 के लेख I want off Mr Golang’s Wild Ride के बाद Go की आलोचना पर प्रतिक्रियाएं लगातार दोहराई जाती रही हैं
    • Windows वाला मामला वह क्षेत्र नहीं है जिसमें Go अच्छा है, ऐसी प्रतिक्रिया
    • यह प्रतिक्रिया कि Go की अच्छी बातें नहीं बताई जातीं
    • यह प्रतिक्रिया कि Go ने जो trade-offs चुने हैं उन्हें समझा नहीं गया
    • बड़ी कंपनियां Go इस्तेमाल करती हैं, इसलिए यह बहुत खराब नहीं हो सकता, ऐसी प्रतिक्रिया
    • समस्याओं को “सही ढंग से” model करने की लागत बड़ी है, इसलिए correctness पर चर्चा निरर्थक है, ऐसी प्रतिक्रिया
    • Rust में भी कमियां हैं, इसलिए Go की आलोचना अमान्य है, ऐसी प्रतिक्रिया
  • मूल बात यह नहीं है कि Go में फायदे हैं या नहीं, बल्कि यह है कि Go का इस्तेमाल जारी रखने के लिए बार-बार दोहराई जाने वाली defensive reasoning असली लागतों को छिपाती है या नहीं

आलोचक की योग्यता पर पहले हमला करने का तरीका

  • जब ऐसा feedback आता है जिसे सुनना नहीं चाहते, तो अगर बोलने वाले को अक्षम या छिपे मकसद वाला मान लिया जाए, तो सामग्री की जांच करने की जरूरत नहीं रहती
  • किसी समस्या को पहचानने के लिए हमेशा बहुत ऊंची skill जरूरी नहीं होती, और senior developer कभी-कभी आदत पड़ चुकी असुविधाओं को उलटे नजरअंदाज कर सकते हैं
  • Junior developer अभी अजीब बातों के आदी नहीं हुए होते, इसलिए वे असुविधा को जल्दी महसूस कर सकते हैं और सवाल पूछ सकते हैं
  • Feedback की कीमत इस पर देखकर जांची जानी चाहिए कि वास्तव में समस्या है या नहीं, न कि किसने कहा

“दूसरी कंपनियां भी इस्तेमाल करती हैं” वाले आधार की सीमा

  • किसी technology choice में दूसरी कंपनियां क्या इस्तेमाल करती हैं, यह देखना discovery के लिए उपयोगी है, लेकिन adoption के आधार के रूप में पर्याप्त नहीं
  • Company tech blogs आम तौर पर adoption cost को पूरी तरह दिखा पाना मुश्किल समझते हैं
    • कई बार वे निर्णय हो जाने के बाद लिखे जाते हैं
    • उनका उद्देश्य company image अच्छा दिखाना और hiring में मदद करना होता है
    • मजबूत technical criticism अक्सर company की बजाय individual से आती है
  • Tailscale का Go इस्तेमाल उस case के करीब है जहां Go expert team लागत को जानती है और संभाल सकती है
    • netaddr.IP: a new IP address type for Go IPv4 या IPv6 address को व्यक्त करने की प्रक्रिया में Go की constraints दिखाता है
    • Hey linker, can you spare a meg? Go linker से जुड़े ऐसे मुद्दे से निपटता है जिसके लिए गहरी जानकारी चाहिए
  • netaddr.IP में दिखा दर्द Go की कई constraints के मेल से पैदा होता है
    • Go में sum type नहीं है, इसलिए “IPv4 या IPv6” type को express करना awkward है
    • slice को 64-bit machine पर 24-byte cost वाले general-purpose data structure की तरह इस्तेमाल किया जाता है
    • operator overloading नहीं होने से a == b और a.equals(b) जैसा फर्क बनता है
    • immutable data support नहीं होने से copy pass करनी पड़ती है और internal mutation से सावधान रहना पड़ता है
    • opaque newtype बनाना मुश्किल है, इसलिए अलग package और interface workaround की जरूरत होती है
  • Tailscale जैसी teams Go के internal behavior और edge cases को गहराई से संभाल सकती हैं, लेकिन हर organization के पास Google या Tailscale जैसे Go experts और engineering budget नहीं होते

Go असल में जिन हिस्सों में अच्छा है

  • Go काफी अच्छा async runtime, opinionated defaults, दो tuning knobs वाला modern GC, और अच्छा toolchain देता है
  • Async runtime language के center में होने से ऐसे tools भी मिलते हैं जिनसे Rust developers को ईर्ष्या हो सकती है
    • चल रही सभी goroutines के backtrace आसानी से dump किए जा सकते हैं
    • deadlock detection संभव है
    • इसका अपना profiler है
    • function coloring के बारे में कम सचेत रहना पड़ता है
  • Package management, refactoring, और cross-compile tools C ecosystem के pkg-config, autotools, CMake की तुलना में शुरुआत में सुधार जैसे लगते हैं
  • लेकिन Go का सुविधाजनक runtime अलग से चुनकर इस्तेमाल नहीं किया जा सकता
    • custom toolchain
    • build system
    • calling convention
    • single GC
    • included standard components और ecosystem
    • संयोग से बने language design तक साथ में अपनाने पड़ते हैं

Type system और language design की खाली जगहें

  • Go TCP, HTTP, TLS, HTTP/2, DNS, web service implementation के लिए runtime को केंद्र में रखता है, और Java/C/C++/Python सीख चुके Google developers को परिचित लगने वाला रूप अपनाता है
  • C की तरह error handling को खुद बहुत अधिक नहीं संभालता, और बहुत सारी mutable state को developer को if और else से सीधे manage करना पड़ता है
  • Java की तरह value और reference का फर्क धुंधला कर देता है, और केवल call site देखकर यह जानना मुश्किल होता है कि value बदलेगी या नहीं
    • method receiver A है या *A, इसके आधार पर main का local variable a बदल भी सकता है और नहीं भी
  • Mutability और immutability को type से साफ तौर पर सीमित करना मुश्किल है, इसलिए reference pass करते समय internal value बदल जाने या लंबे समय तक store होकर release न होने का जोखिम रहता है
  • Go निम्न error groups को पर्याप्त रूप से रोक नहीं पाता
    • mutex को गलती से copy करके निष्प्रभावी कर देना
    • struct field initialize न करना, जिससे zero value आ जाए
    • गलत nil, zero, empty string का system के अंदर गहराई तक फैल जाना

zero value और “ध्यान रखेंगे तो हो जाएगा” की सीमा

  • struct में नया field जोड़कर function input का रूप वस्तुतः बदल जाए, फिर भी composite literal में नया field छोड़ देने पर compiler नहीं रोकता
    • उदाहरण में Params में b int32 जोड़ा गया, लेकिन caller सिर्फ a: 47 दे तो b=0 के साथ run होता है
    • इसके उलट function argument सीधे जोड़ने पर argument count कम होने से compile error आता है
  • Go के principles में से एक यह है कि zero value उपयोगी होती है, लेकिन वास्तविक अर्थ हर type में अलग होता है
    • nil slice पर len call करने से 0 आता है, इसलिए वह empty slice की तरह behave करता है
    • nil map में value डालने पर panic: assignment to entry in nil map होता है
  • channel के लिए भी अलग rules हैं
    • nil channel में send करने पर हमेशा के लिए block हो जाता है
    • nil channel से receive करने पर हमेशा के लिए block हो जाता है
    • closed channel में send करने पर panic होता है
    • closed channel से receive करने पर zero value तुरंत return होती है
  • Go में sum type नहीं है, इसलिए “ज्ञात options में से केवल एक की अनुमति” वाले input को type से express करना मुश्किल है, और यह C की तरह “बस सावधान रहो” वाले तरीके के करीब है
  • सभी समस्याओं को नहीं रोका जा सकता, इसलिए कुछ समस्याओं को भी रोकने की जरूरत नहीं—यह रवैया गलत द्विभाजन है, और जिन समस्याओं में type system मदद कर सकता है उन्हें भी manual caution पर छोड़ देता है

Rust comparison “perfect replacement” की बहस नहीं है

  • रुख यह नहीं है कि Rust perfect है, और Go और Rust को अलग-अलग तरीकों की success stories माना जा सकता है
    • Go की success included components और opinionated defaults पर काफी निर्भर है
    • Rust की success gradual adoption और दूसरी languages के साथ integration की ease पर काफी निर्भर है
  • Rust adoption के असली cases पूरे replacement से ज्यादा incremental porting जैसे हैं
    • Firefox बड़े C++ codebase के अंदर कई core Rust components शामिल करता है
    • Android ने Bluetooth stack को Rust में फिर से implement किया
    • Rust cryptography code Python में गया, और Rust HTTP code curl के कई backends में से एक के रूप में गया
    • Linux kernel Rust patch बार-बार improve हो रहा है
  • Rust users भी build time, language features की कमी, और अन्य drawbacks के बारे में सक्रिय रूप से बात करते हैं
  • मुद्दा Go और Rust में से किसी एक को हर हाल में चुनना नहीं, बल्कि यह है कि mutability·lifetime·abstraction को type से express कर पाने वाले tools कौन-सी समस्याएं घटाते हैं
  • Rust में भी हर case को सख्ती से model करना जरूरी नहीं हो सकता
    • उदाहरण के लिए अगर low-level ls जैसा tool नहीं है, तो camino का उपयोग करके सिर्फ UTF-8 path संभालने का फैसला कर सकते हैं
    • Error handling में कुछ महत्वपूर्ण variants list करके बाकी को Other, Internal, Unknown रखा जा सकता है
    • Option<T> पर unwrap() call करना इस तरह है कि value मौजूद है, यह स्पष्ट रूप से assert किया जा रहा है

Go दूसरे ecosystems से अलग एक द्वीप जैसा है

  • cgo इस्तेमाल न करें तो Go सामान्य assembly, linker, debugger, memory checker, calling convention से दूर है
  • Go C/C++ की तुलना में closed-world language के ज्यादा करीब है, और Node.js·Python·Ruby की तुलना में FFI के प्रति अधिक hostile है
  • इस फर्क के फायदे भी हैं
    • TLS और HTTP stack के internals को business logic की तरह ही profiler में देखा जा सकता है
    • यह dynamic languages में stack trace के OpenSSL पर रुक जाने के contrast में है
    • runtime non-blocking I/O और scheduling संभाल सकता है
  • लेकिन कई मौजूदा tools और institutional knowledge को जस का तस इस्तेमाल करना मुश्किल है, और Go को दूसरी languages के साथ integrate करना भी पेचीदा है
  • Go integration के तरीकों में हर एक की अपनी लागत है
    • Go से C call करने पर FFI boundary cost के साथ GC को न बिगाड़ने के लिए manual descriptor tracking चाहिए
    • दूसरी language से Go call करने पर GC सहित पूरा Go runtime साथ में डालना पड़ता है, जिससे बड़ी static library और operational burden आता है
  • Go से जुड़ने वाली सबसे बेहतर boundary लगभग network boundary है
    • REST-ish HTTP/1, JSON-RPC, gRPC जैसे RPC over TCP latency cost संभाल सके तो अपेक्षाकृत कम दर्दनाक हैं
    • फिर भी दोनों तरफ invariant conditions बनाए रखने पड़ते हैं, और Go side पर validation package लगातार इस्तेमाल न किया जाए तो compiler guarantee नहीं देता

Prototype के लिए Go वाली उम्मीद का trap

  • Go सीखना आसान है और hiring आसान है, इसलिए पहले prototype बनाकर, बाद में मुश्किल होने पर rewrite करने या expert लाने का विचार होता है
  • लेकिन “throwaway code” वास्तविकता में लगभग मौजूद नहीं होता
    • Rewrite में समय लगता है
    • smooth transition coordination मुश्किल होता है
    • details खो सकती हैं
    • नए features का development रुक जाता है
    • लोगों को नई technology के हिसाब से फिर train करना पड़ता है
  • जैसे-जैसे Go components बढ़ते हैं, मौजूदा Go code के साथ interact करने के लिए Go को लगातार चुनने के कारण बढ़ते हैं
  • Linters कुछ मदद करते हैं, लेकिन वे उतना नहीं कर सकते जितना उस भाषा का compiler कर सकता है जिसने मूल रूप से समस्या को गंभीरता से संभाला हो, और development speed भी धीमी करते हैं
  • भाषा में जो complexity नहीं है, वह codebase में चली जाती है
    • Type से express न की गई invariant conditions को code में सीधे लिखना पड़ता है
    • सिर्फ function signature से यह जानना मुश्किल है कि data बदलेगा या नहीं, store होगा या नहीं, zero value allowed है या नहीं, goroutine शुरू होगी या नहीं, nil channel संभव है या नहीं, interface{} में वास्तव में कौन-से types pass किए जा सकते हैं
    • Documentation पर निर्भर होना पड़ता है, और documentation में update cost और न update करने की cost दोनों बड़ी होती हैं

आखिर में संक्षेप में दिखने वाले “झूठ”

  • Go का इस्तेमाल जारी रखने के लिए हम खुद से जो बातें कहते हैं, उन्हें इस तरह संक्षेप किया जा सकता है
    • दूसरे लोग इस्तेमाल करते हैं, इसलिए हमारे लिए भी अच्छा होगा
    • चिंता जताने वाला व्यक्ति elitist या rude है
    • आकर्षक async runtime और GC बाकी सभी कमियों की भरपाई कर देते हैं
    • language design की हर कमी अकेले भी और मिलकर भी ठीक है
    • “सावधान रहकर”, linters, और ज्यादा reviewers से पार पा सकते हैं
    • लिखना आसान है, इसलिए production software development भी आसान है
    • language सरल है, इसलिए बाकी सब भी सरल है
    • थोड़ा ही इस्तेमाल करेंगे या सिर्फ शुरुआत में इस्तेमाल करेंगे, और आसानी से निकल पाएंगे
    • बाद में कभी भी rewrite कर सकते हैं
  • चुना गया tool अगर complexity खत्म नहीं कर पाता, तो वह complexity दूसरे developers, operators, और customers पर चली जाती है
  • जहां nil value नहीं आनी चाहिए वहां आकर production में रात को जगाने वाली स्थिति Billion Dollar Mistake की पुनरावृत्ति बन जाती है

संबंधित पढ़ाई

2 टिप्पणियां

 
tsboard 2024-11-28

मैं Go भाषा के साथ बहुत ही थोड़े समय से गहराई से काम कर रहा एक शौकिया व्यक्ति हूँ, इसलिए सोच रहा था कि क्या मुझे यह लिखना भी चाहिए... Go भाषा के फायदे और नुकसान सचमुच बहुत स्पष्ट हैं, इसलिए इसे चुनने वालों के पास भी और इससे बचने वालों के पास भी साफ वजहें दिखती हैं। व्यक्तिगत रूप से मुझे नहीं लगता कि इसकी तुलना Rust से करनी चाहिए; Kotlin(Java) से तुलना करना ज़्यादा सही लगता है.

Go की goroutine वाकई शानदार हैं, लेकिन वे कोई जादू नहीं हैं। खासकर backend में सिर्फ एक MySQL इस्तेमाल करने वाले छोटे प्रोजेक्ट्स में, इस concurrency को संभालना वास्तव में काफी पेचीदा होता है। JS/TS runtime में जिन बातों पर बहुत ध्यान नहीं देना पड़ता, जैसे MySQL resource exhaustion या pool management, वे सोच से ज़्यादा कठिन निकलते हैं। आखिरकार इस स्थिति में DB ही bottleneck बन जाता है, इसलिए Go भाषा की concurrency वाली बढ़त कुछ हद तक फीकी पड़ जाती है। (JS/TS runtime का async I/O या event loop उल्टा ज़्यादा उपयुक्त हो सकता है) अभी hey जैसे टूल से -c 100 डालकर चलाइए, समझ में आ जाएगा।

और भले ही इसमें शानदार GC है, इसका मतलब यह नहीं कि आप बेधड़क सिर्फ pointer पास करके object इस्तेमाल करते रहें और बाद की सफाई की परवाह ही न करें। हर चीज़ में trade-off होता है, लेकिन Go भाषा में भी जहाँ संभव हो, छोटे object को value copy से पास करके इस्तेमाल करना और function खत्म होते ही उनका निपट जाना बेहतर है। हो सकता है मैं पुराने सोच में अटका हुआ हूँ, लेकिन C/C++ की तरह efficiency के नज़रिए से pointer को बहुत हल्के में लेना सही नहीं था।

error को function return में लगभग हर बार लौटाना और हर बार if err != nil {} से जाँचना सचमुच झंझट वाला है, लेकिन यही इसकी खूबी भी है। क्योंकि इसकी लागत try catch से कम होती है। और finally {} जैसी भूमिका निभाने वाला defer keyword भी शानदार है। resource release का समय अलग से सोचने की जरूरत नहीं पड़ती, यह अच्छी बात है। सिर्फ standard library से ही एक बेहतरीन backend server configuration तुरंत तैयार हो जाना भी अच्छा है (1.23 या बाद का संस्करण)। सबसे बढ़िया बात यह है कि target OS के हिसाब से build कर दें, तो किसी दूसरे runtime या pre-installation की जरूरत नहीं पड़ती।

मैंने Go भाषा को बहुत लंबे समय तक इस्तेमाल नहीं किया है, लेकिन लगता है कि मैं बहुत निजी राय पर कुछ ज़्यादा ही लंबा लिख रहा हूँ, इसलिए यहीं रुकता हूँ। हाहा, मुझे Go भाषा भी पसंद है और दूसरी भाषाएँ भी!
 
GN⁺ 2024-11-27
Hacker News की राय

  • यह लेख Go की कई कमियों को अच्छी तरह पकड़ता है, लेकिन मुझे नहीं लगता कि explicit error handling उनमें से एक है
    मुझे exception handling हमेशा नापसंद रही है, क्योंकि यह “magic” की एक ऐसी layer जोड़ देती है जिसे बहुत आसानी से बिगाड़ा जा सकता है; और भले ही यह तकनीकी रूप से परफेक्ट तर्क न हो, दशकों के अनुभव के आधार पर मैं उस तरीके को तरजीह देता हूँ जिसमें error उसी जगह handle हो जहाँ वह पैदा हुआ है
    कहा जा सकता है कि Rust इसे अधिक elegant ढंग से करता है, और व्यक्तिगत projects में मुझे Rust ज्यादा पसंद है, लेकिन अलग-अलग skill level के developers के आने-जाने वाले बड़े projects में Go की philosophy modern error handling तरीकों में काफ़ी reasonable लगती है
    मेरे इलाके में Go अपनी simplicity की वजह से दूसरी “नई” languages की तुलना में कहीं ज्यादा अपनाया जा रहा है। यह सबसे अच्छी language नहीं है, लेकिन इसमें खुद को नुकसान पहुँचाने से रोकने वाली बहुत-सी built-in समझदारी है, इसलिए general-purpose language के रूप में यह अक्सर सबसे अच्छा विकल्प बन जाती है

    • Go की error handling में कई कमियाँ हैं। लेखक Rust की तरफ़ काफी झुके हुए हैं, इसलिए विकल्प exceptions नहीं बल्कि Result sum type है
      stack trace नहीं होता और errors को wrap करना पड़ता है, इसलिए unique error message के साथ-साथ हर call site के लिए unique wrapping message भी बनाना पड़ता है, ताकि message को grep करके stack trace जैसी किसी चीज़ का अंदाज़ा लगाया जा सके
      “return tuple” एक अजीब-सा उपकरण है जो सिर्फ errors की वजह से मौजूद है, और language में बाकी कहीं tuple इस्तेमाल भी नहीं कर सकते। awkward variable initialization rules के कारण किसी दिन आप गलत err variable इस्तेमाल कर बैठेंगे
      Go में enums होने चाहिए थे, या errors के लिए बने इस अजीब “return tuple” की जगह Rust के ? जैसी बेहतर syntactic sugar होनी चाहिए थी। मौजूदा तरीका उबाऊ है और गलती होने की संभावना बढ़ाता है
      Go में ज़िद है, लेकिन बहुत बार यह ऐसी ज़िद लगती है जो language को आलोचना से बचाने की कोशिश करती है। अफ़सोस, programming language के लोकप्रिय होने में marketing, यानी झूठ, भी अहम होता है, और यह काम कर जाता है
    • मैं 30 साल से ज्यादा समय से programming कर रहा हूँ और करीब 10 साल C# भी इस्तेमाल किया है, लेकिन exceptions को मैं programming के इतिहास के सबसे खराब ideas में से एक मानता हूँ
      exceptions एक भयानक goto हैं जिसे कोई भी library मेरे code में फेंक सकती है, और वे लगभग कभी ठीक से handle नहीं होते। exception “handle” हो जाने के बाद भी application आम तौर पर अज्ञात state में चली जाती है और उसके बारे में reason करना संभव नहीं रहता
      Go errors को junior engineers भी आम तौर पर आसानी से debug कर लेते हैं, लेकिन Java exceptions की असली वजह समझना अनुभवी principal के लिए भी मुश्किल होता है
    • Go की error handling की तारीफ़ करने वाले लोगों को मैंने बिना अपवाद हमेशा सिर्फ exceptions से तुलना करते देखा है, जैसे exceptions ही एकमात्र विकल्प हों
      इसके उलट, Maybe, Option, Result जैसे sum types से परिचित और फिर भी Go के तरीके को थोड़ा भी ठीक मानने वाला व्यक्ति मुझे अब तक नहीं मिला
    • error handling वाला यह हिस्सा लगभग पूरी तरह धार्मिक बहस जैसा है, और Go के सबसे बुनियादी सिद्धांतों में से एक—“code लिखने में आसान होने से ज्यादा पढ़ने में आसान होना चाहिए”—के भी खिलाफ जाता है
      जब किसी method की logic पढ़नी हो और 75% हिस्सा error noise हो, जबकि केवल 25% lines ही वास्तविक behavior समझने के लिए ज़रूरी हों, तो उसे पढ़ना मुश्किल हो जाता है
      किसी codebase को पहली बार देखते समय मैं error edge cases से पहले यह जानना चाहता हूँ कि वह क्या हासिल करना चाहता है, और उसके बाद देखना चाहता हूँ कि वह इसे सही तरीके से कैसे सुनिश्चित करता है
      इस मामले में Go की error handling बुरी तरह विफल रही है। समस्या यह नहीं कि explicit error handling खराब है, बल्कि समस्या यह ज़िद है कि success path और error handling को एक-एक line करके मिलाकर लिखना ही होगा। dedicated error handling section में भी explicit तरीके से handle किया जा सकता है
    • मैं इस दावे से असहमत हूँ कि explicit error handling बहुत ज्यादा हो जाती है
      जिस बात से मैं सहमत हूँ, वह यह है कि यह आपको code से बनने वाली हर संभावना के बारे में सोचने पर मजबूर करती है। हालांकि यह दूसरी languages की तुलना में C के ज्यादा करीब वाला सवाल है
      code को abstract करते समय कभी-कभी error को तुरंत handle करने की जरूरत नहीं होती, या आप उसे call stack में नीचे की तरफ handle करना चाहते हैं
      language को किसी खास तरीके पर अड़ाए रखने के लिए readability की काफी कुर्बानी दी जाती है

  • Rust और Go बहुत अलग हैं, और लगता है लोग एक ऐसा बीच का रास्ता चाहते हैं जो फिलहाल मौजूद नहीं है
    यानी ऐसी भाषा जिसमें garbage collection हो, जो अपेक्षाकृत सरल हो और static linked binary में compile हो जाए, लेकिन Rust जैसा type system और rest type जैसी चीज़ें भी हों
    Syntax के लिहाज़ से Gleam और Kotlin कुछ हद तक करीब हैं, लेकिन पूरी तरह नहीं। मुझे Rust पसंद है, लेकिन मेरे हिसाब से यह उन कई लोगों के लिए बहुत जटिल है जो कुछ बना तो सकते हैं, पर न तो computer science graduate हैं और न ही programmer के तौर पर काम करते हैं
    अगर आप भाषा का इस्तेमाल केवल कभी-कभार करते हैं, तो vtable क्या है, value कब और कैसे free होती है जैसी बातें याद नहीं रहतीं। “perfect language” कोई नहीं है, लेकिन Go और Rust दोनों ने बेहतरीन चीज़ें दी हैं, और उम्मीद है कोई इन दोनों से प्रेरणा लेकर एक सरल भाषा बनाएगा जिसे व्यापक रूप से इस्तेमाल किया जा सके

    • Kotlin एक बीच के रास्ते के तौर पर दिलचस्प है, लेकिन मुझे लगता है ज़्यादातर कामों में यह Go से काफी कम productive है और जिन कामों के लिए Rust निकाला जाता है, उनके लिए भी फिट नहीं बैठता
      असल Kotlin बहुत जटिल है, और smart बनने की कोशिश में समय खर्च करवा देती है। काम करने के 1000 तरीके हैं, और operator overloading, proxy, property, companion object, exception और result type सब मौजूद हैं
      अगर मान लें कि Gradle इस्तेमाल कर रहे हैं, तो build system go build के आदी लोगों के लिए लगभग यातना जैसा है
      Coroutine API, Goroutine की तुलना में एक साथ अधिक जटिल और अधिक सीमित महसूस होती है। यह ज़्यादा structured है, लेकिन कम flexible है और इस्तेमाल करने में ज़्यादा मेहनत लगती है
      Access control भी अटपटा है। किसी type को package-only बनाने का तरीका नहीं है; या तो file-only है या पूरे module में public। इसलिए अनचाहे API surface बढ़ जाता है, या complexity को कई files में बाँटा नहीं जा सकता
      Kotlin/Native और Kotlin/JVM असल में अलग-अलग चीज़ें हैं। Kotlin/JVM परिपक्व है, लेकिन JVM पर चलता है, इसलिए जिन use cases में Rust निकालने लायक होता है उनमें से कुछ हट जाते हैं
      Kotlin/Native ecosystem बहुत कमजोर है और documentation भी कम है। issue tracker में डराने वाले bugs भी हैं
      Kotlin/Native source-only libraries distribute भी नहीं कर सकता, इसलिए हर operating system और architecture के लिए binaries build करने वाली जटिल CI चाहिए। नहीं तो libraries distribute ही नहीं की जातीं, और यह भी शायद कमजोर ecosystem को और खराब करता है
    • निजी तौर पर मुझे लगता है कि Go में लोग जिन Rust features की कामना करते हैं, उनमें से ज़्यादातर अब भी Go की “concept” के अंदर फिट हो सकते हैं
      जैसे generics जोड़े गए थे, वैसे ही बस तीन चीज़ें जोड़नी होंगी: errors के लिए generic container Result, बेहतर nil handling के लिए Optional, और Elvis operator जैसा छोटा syntax sugar
      Go की सफलता को लगभग अकेले समझा देने वाला बड़ा फायदा यह है कि इसे एक विशाल कंपनी ने बनाया और खुद इस्तेमाल किया, इसलिए उसके पास बेहतरीन tools और open-source libraries बनाने की क्षमता थी। भाषा की सफलता का सबसे बड़ा निर्णायक factor यही लगता है कि वह पहले से इस्तेमाल में है और libraries मौजूद हैं
    • इस विषय पर मेरी सोच, फिर से कहूँ तो, यह है: शुरुआत JavaScript से की जाए
      इसकी basic syntax बहुत सीधी है, adoption पहले से ही बहुत बड़ा है, ecosystem बड़ा है, runtime लगातार बेहतर हो रहा है, और WASM में compile भी किया जा सकता है
      इसमें से अजीब हिस्से हटाए जाएँ—जैसे बहुत ज़्यादा redefinition flexibility, global scope का दुरुपयोग, numbers से जुड़ी विचित्रताएँ—और types, sum types/product types, Result, Maybe, decimal आदि जोड़े जाएँ
      फिर अगर हर चीज़ को expression मानने वाला style, pattern matching, currying जैसे functional features और comprehensive standard library जोड़ दी जाए, तो ऐसी भाषा निकल सकती है जो बहुत लोगों की चाहत के सबसे करीब हो
      Developer tools में एक और बड़ा सुधार जो मैं देखना चाहूँगा, वह है HTML को overhaul करके अच्छे advanced controls built-in देना और inline CSS से आसानी से styling करने योग्य बनाना। इससे client पर ज़रूरी JS की मात्रा घटेगी
      मेरे हिसाब से ये दोनों चीज़ें web-related development की programming productivity को काफी बढ़ाएँगी
    • मैं लेखक हूँ; Gleam किस मायने में उस स्तर तक नहीं पहुँचता? मैं भी ऐसा बीच का रास्ता खोज रहा हूँ, इसलिए Gleam को लेकर काफी उत्सुक हूँ
    • C# और F# स्पष्ट रूप से सबसे करीब हैं। दूसरे विकल्पों में इनके बराबर अच्छा type system या tooling नहीं है
      dotnet publish -p:PublishAot=true से static native binary में compile किया जा सकता है। F# में print* की जगह Console.* methods इस्तेमाल करने पड़ते हैं, क्योंकि print में %A format specifier के structural output की वजह से अंदर unbounded reflection होता है, जो binary size पर बुरा असर डालता है और compiler शिकायत करता है
      खासकर F# को “ज़्यादा आसान और business-oriented Rust alternative” के तौर पर recommend किया जा सकता है। यह expression-oriented है, discriminated unions, पूरा HM type inference और gradual typing अच्छी तरह मेल खाते हैं। data analysis और domain modeling भी बहुत आरामदायक हैं
      Systems programming के लिए C# विकल्प बनता है। यह शानदार concurrency primitives, तेज़ और कभी-कभी लगभग zero-cost native interop, Go से छोटे native binaries, और portable SIMD समेत कई low-level APIs देता है
      Go ऐसे कामों के लिए अक्सर ठीक से fit नहीं होता, या workaround के बिना कई बार कर ही नहीं पाता। .NET इस क्षेत्र की non-game community में लोकप्रिय हो रहा है और कई high-performance libraries भी बन रही हैं। साथ ही sibling comment में सुझाई गई niche languages के उलट, इसे विशाल मौजूदा ecosystem का लाभ मिलता है, इसलिए सारी बुनियादी चीज़ें खुद करने की ज़रूरत नहीं पड़ती

  • Go: “मैं एक सरल भाषा हूँ!”
    यूज़र कुछ समय तक Go इस्तेमाल करता है
    यूज़र: “मुझे तुमसे नफ़रत है, तुम तो एक सरल भाषा हो!”
    शायद मेरी उम्र 50 से ऊपर है, इसलिए मुझे सरल भाषाएँ पसंद हैं
    यह “आलोचना” बहुत संतुलित नहीं लगती, और टेक्नोलॉजी में हर चीज़ trade-off होती है, इसलिए असंतुलित निर्णय कमज़ोर लगता है
    बेशक मेरा निष्कर्ष अलग है: https://www.inkmi.com/blog/why-we-chose-go-over-rust-for-our...

    • Go की आलोचना पर अक्सर चिपकाई जाने वाली यह एक विकृति है। जैसे, “तुम सरलता समझते ही नहीं, तुम्हारे दिमाग में Java का कीड़ा घुस गया है”
      लेख में भाषा की परेशान करने वाली असंगतियों की ओर इशारा करने वाले कई उदाहरण हैं, और वे सरलता के उलट हैं
      मुझे Rob Pike की Go प्रस्तुति पसंद है, और कुछ हिस्सों ने मेरी आँखें खोलीं। बस चाहता हूँ कि असल में दिखने वाला Go, Go प्रशंसकों द्वारा अमूर्त रूप में बताए जाने वाले Go के कहीं ज़्यादा करीब हो
    • काश Go को “सरल” भाषा कहने वाला विमर्श खत्म हो जाए
      दिखावे के विपरीत, Go इस्तेमाल करना शुरू करते ही जल्द पता चल जाता है कि यह सरल नहीं है। इसमें छिपी जटिलताएँ और pitfalls बहुत हैं। उदाहरण: https://archive.ph/WcyF4
      फिर भी यह उपयोगी भाषा है और काफी इस्तेमाल होती है, लेकिन “सरल” नहीं है
    • Go की समस्या यह है कि इसे यूज़र्स के लिए सरल भाषा के रूप में नहीं, बल्कि maintainers के लिए लागू करना आसान भाषा के रूप में डिज़ाइन किया गया था
      मेरे हिसाब से सरल भाषा में बहुत अधिक consistency होनी चाहिए। नियम कम हों, लेकिन हर जगह सार्वभौमिक और consistent हों। लेकिन Go में अजीब चीज़ें, असंगतियाँ और workaround हर जगह हैं
      एक अच्छा उदाहरण type omission है। array, slice, map declaration में यह संभव है, लेकिन struct में नहीं। struct में भी अनुमति देने से readability के लिहाज़ से कई फायदे होंगे, और anonymous struct arguments के ज़रिए named parameters भी संभव हो जाएँगे, जिससे मौजूदा बदसूरत workaround की तुलना में डिज़ाइन कहीं बेहतर हो सकता है
    • Scheme एक सरल भाषा है, लेकिन Go complexity को तब तक छिपाता है जब तक वह सबसे बुरे समय पर फट न पड़े
      बेशक Go के अधिकतर वाजिब alternatives भी इस नज़रिए से और खराब हैं। Python, Ruby, JS जैसी चीज़ें
    • Go केवल तब “सरल” है जब आप सरल काम कर रहे हों। KV store या database खुद लिखकर देखें, थोड़े और modern language features की ज़रूरत जल्दी महसूस होने लगेगी

  • मुझे उत्सुकता है कि किसी भी भाषा को इतना लंबा नीचा दिखाने की प्रेरणा क्या होती है। लेख के कुछ सही बिंदु भी constructive अंदाज़ में नहीं लिखे गए, इसलिए मैं इसे निंदा कहूँगा
    ऐसी कौन-सी भाषा है जिसकी आलोचना नहीं हो सकती?
    क्या यह लेख उस प्रोजेक्ट में अपनी असफलता का दोष भाषा पर डालकर बेहतर महसूस करने के लिए लिखा गया है? या फिर यह समझ न पाने से कि हर कोई उसी तरह नहीं सोचता और काम करता, और जो चीज़ किसी को असहनीय रूप से खटकती है वह दूसरे को लगभग दिखती भी नहीं?
    जो भाषाएँ वास्तविक ज़रूरतें पूरी नहीं करतीं, वे आम तौर पर अपने-आप गायब हो जाती हैं, और उन्हें शायद ही किसी मदद की ज़रूरत होती है
    Go “ज़्यादा refined” भाषाओं से अलग हो सकता है, फिर भी जिन projects में मैंने इसे देखा वहाँ इसने शानदार काम किया। आशा है लेखक को Go में काम करने के लिए मजबूर न किया जाए। बाकी community services बनाती रहेगी, Go team को feedback देती रहेगी, और production तोड़े बिना भाषा को धीरे-धीरे evolve होते देखेगी

    • “किसी को इतनी लंबी निंदा लिखने के लिए क्या प्रेरित करता है” इसका जवाब लेख में ही है
      मूलभूत complexity आँखें बंद कर लेने से गायब नहीं होती
      अगर आप complexity की परवाह न करने का चुनाव करते हैं, तो आप बस उस complexity को संगठन के दूसरे developers, operations staff, customers, किसी और पर धकेल रहे होते हैं। अब उन्हें सब कुछ smoothly चलाने के लिए आपकी assumptions को bypass करना पड़ेगा
      आजकल मैं अक्सर वही “कोई और” होता हूँ, और अब थक चुका हूँ
      यह स्वाभाविक है कि Go आपके सामने आए projects में शानदार चला। C, C++, PHP, JavaScript भी चलते हैं। हमारी दुनिया में बहुत-सी चीज़ें “काम करती” हैं। एक और lane जोड़ना भी काम करता है, police state भी काम करती है
      लेकिन क्या कोई दूसरी चीज़ कहीं बेहतर काम नहीं कर सकती?
    • यह बस किसी का ब्लॉग है और उसने खुलकर शिकायत की है। ठीक है, इसे इतना गहराई से देखने की ज़रूरत नहीं
      उसने क्यों लिखा, शायद इसलिए कि मूल लेखक को लगा होगा कि उसके विचार “दुनिया में” पर्याप्त रूप से प्रतिनिधित्व नहीं पा रहे। मैं भी Go fan नहीं हूँ, इसलिए 2022 में Go की लोकप्रियता मुझे उलझन भरी लगी। क्योंकि इसके काफी स्पष्ट नुकसान ignore होते दिख रहे थे
      PHP एक खराब भाषा है, इस पर लंबे ब्लॉग पोस्ट अब लोग कम लिखते हैं, क्योंकि उस पर पहले ही बहुत लिखा जा चुका है
    • हर कोई केवल उबाऊ और clinical reviews पसंद नहीं करता; कुछ लोग थोड़ा passion और humour वाले लेख भी पसंद करते हैं
      यह ब्लॉग पोस्ट आपकी पसंद के अंदाज़ में नहीं लिखा गया, इसका मतलब यह नहीं कि दूसरों के लिए इसकी कोई value नहीं
    • Go को लगभग नापसंद करने लगने के मेरे बहुत subjective और irrational कारणों में से एक यह है कि वर्षों तक Go fanatics ने Go के हर हिस्से को लेकर सबको gaslight किया
      Go ने जो भी किया, चाहे वह सबसे बुनियादी implementation हो या कुछ ऐसा जो दूसरी भाषाएँ पहले से बेहतर कर रही थीं, उसे essential, best, और उस समस्या को हल करने का एकमात्र तरीका बताया गया
      Go ने जो नहीं किया, उसे पूरी तरह अनावश्यक माना गया, और हम अज्ञानी non-Go users को syntax sugar का आदी बनाने की Big Complexity की साज़िश जैसा बताया गया। proper null handling, error handling, कम boilerplate, generics, या हर चीज़ के लिए special case बनाए बिना consistent solution बनाने जैसी सुविधाएँ भी इसी तरह थीं
      इस thread में भी strawman जारी है। error handling की बात आते ही Go की error handling कहीं बेहतर हो सकती है, इस स्पष्ट बात को मानने के बजाय JavaScript जैसी चीज़ उठा ली जाती है। जैसे Go की आलोचना करने वाला व्यक्ति JavaScript को error handling की पराकाष्ठा मानता हो
    • Bjarne ने सबसे अच्छे से कहा था। भाषाएँ केवल दो तरह की होती हैं। जिनकी लोग शिकायत करते हैं, और जिन्हें कोई इस्तेमाल नहीं करता

  • हर बार जब किसी दूसरी भाषा में काम करता/करती हूँ, तो Go भले ही परफेक्ट भाषा न हो, फिर भी हमेशा वापस उसी पर लौटने का मन करता है
    मुझे यह बात पसंद है कि यह सचमुच बस चल जाता है। Go इंस्टॉल करें, कोड डाउनलोड करें, कोड लिखें—बस हो गया
    यह पता लगाने की ज़रूरत नहीं पड़ती कि कौन-सा version, runtime, configuration, build tool या package manager इस्तेमाल करना है। बस इंस्टॉल करें और Go इस्तेमाल करें
    शायद Rust ही कोई दूसरी भाषा है जो ऐसा ही अनुभव देती है
    हो सकता है यह वह झूठ हो जो मैं खुद से बोलता/बोलती हूँ, लेकिन हर बार Python, TypeScript, Java इस्तेमाल करते हुए मैं बस कोड लिखना चाहता/चाहती हूँ, और settings, package managers, build tools, versions से जुड़ी समस्याएँ debug या समझने में programming से डर लगने लगता है

    • Go की ताकत integrated toolchain है। लेख में जैसे कहा गया है, यह interoperability को मुश्किल बनाता है, लेकिन मेरे व्यक्तिगत और सीमित अनुभव में वह कोई बहुत आम use case नहीं है
    • यही Go का सबसे ज़्यादा सराहा जाने वाला पहलू होना चाहिए, और Rust ने भी channels के साथ इस बात को अपनाया है

  • Go की आलोचना पढ़ते समय हर बार यही सोचता/सोचती हूँ। फिर भी मैं Go इस्तेमाल करता/करती रहूँगा/रहूँगी
    मैं समझता/समझती हूँ कि बहुत-सी समस्याएँ ऐसी हैं जिन्हें सिद्धांततः आसानी से document किया जा सकता है और लोग सच में उनसे अक्सर टकराते भी हैं, लेकिन फिर भी practical काम में यह अब भी बेहतर programming languages में से एक लगती है
    जिन चीज़ों को अक्सर कमियों के रूप में गिनाया जाता है, उनमें कुछ से मैं सहमत नहीं हूँ; उदाहरण के लिए, हर जगह errors को explicit तरीके से handle करने का तरीका मुझे पसंद है। बाकी हिस्सों से सहमत हूँ, लेकिन वे दूसरी programming languages की कमियों से कहीं ज़्यादा परेशान करने वाली नहीं लगतीं
    जिन लोगों को Go के असफल क्षेत्रों से खास संवेदनशीलता है, उन्हें शायद उम्र भर इसकी शिकायत करनी पड़ेगी—यह थोड़ा अफसोसजनक है
    लेकिन किसी project के लिए कौन-सी भाषा चुननी है, यह तय करते समय मैं “सबसे अच्छी भाषा कौन-सी है” जैसी तर्कपूर्ण दलीलों का ढेर नहीं लगाता/लगाती। मैं ऐसी भाषा चुनता/चुनती हूँ जो मेरे लिए ठीक बैठे, जिसमें मुझे लगे कि मैं लगातार अच्छा software लिख सकता/सकती हूँ, और जिसमें काम करना अच्छा लगे
    correctness को महत्व देने वाले व्यक्ति के रूप में इच्छा है कि यह भाषा Rust के ज़्यादा करीब होती, लेकिन अभी ऐसा नहीं है। ऐसा भी नहीं कि मुझे Rust पसंद नहीं, लेकिन जल्दी में जिस भाषा की तरफ हाथ जाता है वह Rust नहीं है
    अब Go कितना भयानक है, इस पर काफी लेख लिखे जा चुके हैं। कम से कम अब समझ आ गया कि कुछ साल पहले PHP fan होना कैसा लगता होगा। यह अतिशयोक्ति है, लेकिन मेरे हिसाब से बहुत बड़ी अतिशयोक्ति नहीं

    • “जो लोग Go के असफल क्षेत्रों के प्रति संवेदनशील हैं, वे जीवन भर शिकायत करेंगे” — यह बात इस लेख के लिए शानदार endorsement जैसी लगती है। क्योंकि असल में लेख का मूल यही है
      आप Go इस्तेमाल करेंगे
      और आपको पछतावा होगा
      लेकिन तब तक बहुत देर हो चुकी होगी, और आप उससे बंध चुके होंगे
      लेखक काफी convincing तर्क दे रहा है, और उसका खंडन करना भी बहुत मुश्किल है। स्पष्ट रूप से गिनाए गए कई मामलों में और ऐसी कई professional स्थितियों में जहाँ technical competence कम वाली company गलत technology चुनती है, Go एक खराब choice है और production में डालने के बाद आपको पछतावा होगा
      कंपनियों को boring tools से चिपके रहना चाहिए। personal project हो तो बेशक जो चाहें करें
    • मुझे Go कुछ हद तक पसंद है। explicit error handling कभी-कभी थोड़ी झुंझलाहट देती है, लेकिन यह काम निपटाने का एक तरीका भर है
      इसके अलावा मैं simplicity को इसकी ताकत मानता/मानती हूँ। इस्तेमाल में अच्छा लगता है, सीखना आसान है, और आम तौर पर performance भी काफी ठीक रहती है। हर स्थिति के लिए इसे नहीं चुनूँगा/चुनूँगी, लेकिन कई स्थितियों में यह अच्छा tool है
      इसी तरह Java और Python भी मुझे कुछ हद तक पसंद हैं, और दोनों में मैं काफी अच्छा/अच्छी हूँ। ये भाषाएँ जिन मकसदों के लिए बनी हैं, उनके लिए अच्छे tools हैं
      समझ नहीं आता कि लोग programming languages से इतने जुनूनी तरीके से क्यों चिपक जाते हैं। भाषा एक tool है। कोई tool आपको ज़्यादा पसंद हो सकता है, लेकिन इससे वह tool अमान्य नहीं हो जाता जो आपको पसंद नहीं
    • “जो भाषा मेरे लिए ठीक बैठे, उसे चुनता/चुनती हूँ” — यह किसी के लिए भी सबसे समझदार चुनाव है। Golang समस्या तभी बनता है जब manager आपको इसे जबरन इस्तेमाल करवाए
    • मुझे Go पसंद है, लेकिन बहुत ज़्यादा Go code लिखने और पढ़ने के बाद सपने में if err != nil वाले दानव मेरे चेहरे पर तमाचे मारते हैं
      इस समस्या को ठीक करने के लिए कई अच्छे proposals आए थे, लेकिन बेहद conservative और ऊँची आवाज़ वाली community के एक हिस्से ने लगभग जहरीले feedback से हर proposal को मार दिया
      अब Go team मनोवैज्ञानिक रूप से ऐसे लोगों से डरती है और error handling improvement की लड़ाई छोड़ चुकी है
      हर Go developer survey में community भारी बहुमत से error handling improvements के पक्ष में vote करती है, लेकिन कुछ मुट्ठीभर extremists ने सारी progress पटरी से उतार दी
    • बहुत-से लोग Go से सचमुच नफरत इसलिए करते हैं क्योंकि उन्होंने दूसरी language features का अनुभव किया है
      Go ने यह अहंकारी रवैया अपनाया कि वह खुद तय करेगा कि आपको कौन-सी features चाहिए, और काम के लिए आपके हाथ में बहुत कम चीज़ें दीं

  • उस समय की चर्चा:
    (130 points, 148 comments) https://news.ycombinator.com/item?id=34188528
    (748 points, 544 comments) https://news.ycombinator.com/item?id=31205072

  • इसमें एक हिस्सा है: “मैं syntax की तुलना में semantics पर कहीं ज़्यादा ध्यान देने लगा/लगी, इसलिए Zig, Nim, Odin वगैरह भी नहीं देखे। अब मुझे ‘बेहतर C’ में दिलचस्पी नहीं है”
    मुझे लगता है लेख काफी लंबा-चौड़ा है। Go के “accidental” होने वाला हिस्सा बकवास है, क्योंकि origin और design के लिहाज से Rust भी उतना ही “accidental” है
    एक बात जो ध्यान खींची, वह यह कि Nim किसी भी तरह “बेहतर C” नहीं है। इसमें garbage collection है, और reference counting भी इस्तेमाल की जा सकती है। चाहें तो इसे बेहतर C की तरह इस्तेमाल किया जा सकता है
    Nim का type system Go की कई समस्याओं से बचता है, लेकिन Rust जितना strict नहीं है
    आखिरकार Go में बहुत-सा software लिखा और deploy किया गया है, वह तेज़ चलता है, downtime कम है, कुल मिलाकर प्रभावी है, और security issues भी कम दिखते हैं। Rust में deploy किए गए software projects कहीं कम लगते हैं, और Firefox अब भी 95% से ज़्यादा C++ है

    • “Rust में deploy किए गए software projects काफी कम हैं और Firefox भी 95% से ज़्यादा C++ है” — यह बात मुझे 2022 का यह tweet[0] याद दिलाती है, इसलिए मजेदार है
      इस बहस में मेरा कोई stake नहीं है, और काम पर मैं Python और C++ संतोष से इस्तेमाल करता/करती हूँ। भले ही Rust में लिखा software बहुत कम हो, फिर भी कहा जा सकता है कि Rust में बहुत-सा software लिखा और deploy किया गया है। बड़ी कंपनियों के investments को भी नजरअंदाज नहीं किया जा सकता
      0: https://x.com/m_ou_se/status/1599173341117435905

  • समझ नहीं आता कि Go की तुलना हमेशा Rust से क्यों की जाती है। सबसे उचित तुलना Java से है

    • मेरे हिसाब से Go को समझने का सही तरीका यही है। Go उन environments में server बनाने की language है जहाँ code की मजबूत consistency और junior engineers का कम onboarding time अहम होता है। यानी यह Java के इस्तेमाल वाले बड़े enterprise scenarios के लिए perfect है
      Go और Rust की तुलना ज़्यादा आम लेकिन कम useful शायद इसलिए है कि दोनों नई language wave का हिस्सा हैं, और दोनों default तौर पर statically linked binaries बनाते हैं
    • Go, Java की पुनरावृत्ति नहीं बल्कि C की पुनरावृत्ति है
      जिन situations में Java अच्छा विकल्प होता है, वहाँ Go वाकई खराब विकल्प है। language सीमित है ही, ecosystem भी Java की तुलना में बहुत सीमित है
      मैं Go, C#, TypeScript को अपनी मुख्य languages के रूप में रखता हूँ, और यह combination शानदार coverage देता है। अगर कभी 6 महीने मिलें जिनमें productivity drop झेल सकूँ, या कोई ऐसा project मिले जिसकी quality requirements कम हों, तो Rust जोड़ूँगा
      language सीखने में 1–2 हफ्ते लगते हैं, लेकिन ecosystem के अंदर engineering करना सीखने में समय लगता है
    • Go असल में C++ compile होने का इंतज़ार करते समय बनाया गया था। लक्ष्य network services के लिए C++ से बेहतर कुछ बनाना था, और इसमें सफलता मिली। बस benchmark काफ़ी low था
      जिन अधिकांश companies में performance concern बहुत बड़ा नहीं होता, वे network services के लिए C++ नहीं इस्तेमाल करतीं। अगर Rust तब तक mature हो चुका होता तो वह अच्छा विकल्प होता, लेकिन शुरुआती core problems में से एक compile time था, और Rust codebase में यह और भी खराब हो सकता है
      असल में मैंने Rust के बजाय Go इस्तेमाल करने के cases देखे हैं, और सबसे बड़ा कारण यह था कि Go बहुत तेज़ compile होता है
    • जो व्यक्ति यह तय कर रहा हो कि कोई नई चीज़ किस language में लिखनी है, वह Go और Rust दोनों पर साथ में विचार करने की काफ़ी संभावना रखता है। Java पर विचार करने की संभावना बहुत कम है
      अगर पूछा जाए कि क्या Rust और Go इतने अलग हैं कि उन्हें अलग-अलग cases में चुना जाना चाहिए, तो जवाब है हाँ। इसी वजह से दोनों पर साथ में विचार करके उनमें से एक चुना जाता है

  • कभी मैं “बेहतर” Python ढूँढ रहा था। ऐसी language चाहिए थी जो C/C++ से सरल और सुरक्षित हो, लेकिन Python से तेज़ हो, और सबसे बढ़कर single binary बना सके
    इसलिए मैंने Rust से लेकर Hare जैसी कम-ज्ञात languages तक सब देखा
    Go obvious choice होना चाहिए था, लेकिन न जाने क्यों उसकी syntax पसंद नहीं आई। Rust समझ आता है। उसमें याद रखने और non-QWERTY keyboard पर टाइप करने में मुश्किल बहुत सारे special characters हैं, और दूसरी pain points भी हैं। कई Lisp में parentheses और reverse Polish notation समस्या थे। लेकिन Go मुझे क्यों पसंद नहीं आया, इसका कोई rationalization नहीं कर पाता
    अंत में Python code को Nuitka से compile करने का फैसला किया। speed improvement का पता नहीं, लेकिन अब binaries दे सकता हूँ
    C# को भी धीरे-धीरे ज़्यादा देख रहा हूँ, क्योंकि AOT compilation बेहतर हो रहा है। हालांकि default mode की verbosity और Windows से बहुत ज्यादा बंधे होने वाली बात पसंद नहीं है
    Nim और Crystal मुझे काफी पसंद आए, लेकिन छोटी community barrier थी। फिर भी Nim इतनी छोटी community के साथ जो कर पा रहा है उससे मैं सच में प्रभावित हुआ, और मुझे लगने लगा कि यह शानदार language है
    मैंने जिन languages का ज़िक्र किया है, उनमें से एक सीखने के लिए खुद को motivate करने की कोशिश करूँगा

    • .NET Core, WPF जैसे specific frameworks और credential store को छोड़कर Windows से बंधा नहीं है। WPF के भी ऐसे alternatives हैं जो हर जगह काम करते हैं
      आजकल इसे इस्तेमाल करना वाकई काफी अच्छा है
    • Nuitka की compatibility अच्छी है, लेकिन उसमें Python C-API की कमियाँ जस की तस रहती हैं
      एक और approach यह है कि C-API छोड़कर Go या Rust जैसी languages तक जाने वाला bridge बनाया जाए
      मैंने कई साल py2many पर काम किया है। इस approach पर feedback पाना चाहूँगा