2 पॉइंट द्वारा GN⁺ 2023-08-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ORC memory management अब डिफ़ॉल्ट है
  • JavaScript backend अब int64 और uint64 के लिए डिफ़ॉल्ट रूप से BigInt का उपयोग करता है, इसलिए JS backend के साथ इंटरऑपरेट करने वाले कोड में इन types का उपयोग होने पर अपडेट की आवश्यकता हो सकती है
  • --experimental:strictEffects अब हमेशा सक्रिय रहता है, और callback parameters के लिए effectsOf annotation आवश्यक है
  • documentation comments की डिफ़ॉल्ट markup language पहले के RstMarkdown mode से बदलकर Markdown हो गई है, और {.doctype: Markdown | RST | RstMarkdown.} pragma तथा md2html और rst2html commands जोड़े गए हैं
  • standard library की कुछ os-संबंधित functionalities को Path abstraction का उपयोग करने वाले नए interface में अलग किया गया है, और वे std/oserrors, std/envvars, std/paths, std/dirs, std/files, std/symlinks, std/appdirs, std/cmdline modules के रूप में उपलब्ध हैं
  • कई standard library modules को Nimble packages में स्थानांतरित किया गया है, इसलिए std/punycode, std/asyncftpclient, std/smtp, std/db_*, std/md5, std/sha1, std/sums का उपयोग करते समय nimble या atlas install करना आवश्यक है
  • बिना नाम वाले block के अंदर बिना नाम वाले break के उपयोग का support deprecated किया गया है, और भविष्य के versions में यह error बन जाएगा
  • "strictFuncs" definition बदल दी गई है, जिससे ref या ptr dereference पर store करना प्रतिबंधित हो गया है
  • variables की tuple unpacking को multiple assignments में expand होने वाली syntactic sugar के रूप में माना जाता है, और nested tuple unpacking अब संभव है
  • top-down inference कई default cases में implement किया गया है, जिससे उदाहरण का seq[(float, byte, cstring)] initialization code compile हो जाता है
  • object fields के लिए default values निर्धारित की जा सकती हैं, और जिन्हें explicitly initialize नहीं किया गया है वे fields वही default values उपयोग करेंगी
  • experimental strictDefs switch जोड़ा गया है, जो यह जांचता है कि variables के उपयोग से पहले उन्हें explicit value assign की गई है या नहीं, और let variables के लिए यह भी जांचता है कि उन्हें ठीक एक बार assign किया गया है
  • C++ interoperability में virtual pragma और विस्तारित constructor pragma जोड़े गए हैं, जिससे ऐसे constructor और virtual proc definitions संभव हैं जो C++ constructors और virtual methods से map होते हैं
  • Nimble 0.14 साथ में दिया गया है, यह lock-file को support करता है, और library storage location $nimbleDir/pkgs से बदलकर $nimbleDir/pkgs2 हो गई है

1 टिप्पणियां

 
GN⁺ 2023-08-02
Hacker News की राय
  • प्रोडक्शन में Nim का संतोषजनक तरीके से इस्तेमाल कर रहा हूं। मुख्य रूप से डेटा एनालिसिस और रिपोर्ट जनरेशन टूल बनाता हूं, और उन्हें ऐसे CLI executable के रूप में compile करता हूं जिन्हें server scripts call करती हैं
    Nim तेज़ और छोटे executable बनाता है, और heterogeneous JSON data structures व dataframe library अच्छी हैं। यह stack को बहुत प्राथमिकता देता है, इसलिए sequence और table जैसे dynamic data structures में भी stack पर मौजूद pointer heap data की ओर इशारा करता है, और lifetime को stack frame manage करता है
    प्रोग्राम में dynamic references लगभग नहीं हैं और GC की चिंता नहीं करनी पड़ती। type system सरल और समझदारी भरा है, और सही code की ओर आसानी से guide करता है। default भी referential transparency के करीब हैं, और जब तक आप explicitly उससे बाहर नहीं जाते, सब कुछ immutable value passing है
    generics शक्तिशाली हैं और उम्मीद के मुताबिक काम करते हैं, और uniform function call syntax अविश्वसनीय रूप से उपयोगी है। किसी specific type को पहले argument के रूप में लेने वाली procedures और functions ही बना दें, तो methods या interfaces जैसी चीज़ लिख सकते हैं; ऐसी abstraction की ज़रूरत कम हो जाती है और code structure सरल व flat रहता है
    यह उतना ही मज़ेदार है जितना पहले D खोजने पर लगा था, बल्कि उससे भी बेहतर। अगर आप एक native-compiled, type-annotated Python की कल्पना करें, जिसमें लगभग 100% business logic हो और कोई फालतू चीज़ न हो, तो वह Nim के अनुभव के करीब है

    • वह विवरण stack पर रखे C++ vector या map जैसा नहीं है? ज़रूरत पड़ने पर internally allocate करता है, और पूरा container scope से बाहर जाते ही destroy हो जाता है
    • Nim को एक बार देखना चाहूंगा। सोच रहा हूं कि build system कैसा है। CMake सच में बहुत पीड़ादायक है
    • यह वाकई Python जैसा दिखता है। काश यह ज्यादा लोकप्रिय हो जाए, और यह काफी अधिक इस्तेमाल में आसान Rust जैसा लगता है
    • अच्छा दिखता है। सोच रहा हूं कि package management किस हालत में है, और मौजूदा ecosystem कितना मजबूत है
  • इस release को आज़माने का इंतज़ार है। 25 साल से professional programming करने वाले व्यक्ति के तौर पर, मुझे लगता है कि Nim कई दुनियाओं की खूबियों को अच्छी तरह जोड़ने वाली language है
    Python की तरह इस्तेमाल में आसान है, strongly typed है लेकिन type inference शानदार है, और defaults तेज़ व सुरक्षित रखे गए हैं। embedded से लेकर high-performance computing तक अच्छी तरह fit बैठता है
    UFCS, generics और concepts की वजह से OOP के फायदे मिल जाते हैं, लेकिन organization के लिए कमजोर data relationships की अंतहीन scaffolding code बनाने की ज़रूरत कम होती है। Python के उलट, ambiguity compile error बन जाती है
    मुझे लगता है कि वही program ज़्यादातर दूसरी languages की तुलना में कहीं छोटा, पढ़ने में आसान और समझने में आसान होता है। पीछे बहुत ज्यादा magic भी नहीं चल रहा होता, क्योंकि defaults समझदारी भरे हैं
    compile-time metaprogramming अलग ही स्तर का है। यह किसी अलग dialect या substitution tricks के बिना language design के core में शामिल है और इस्तेमाल में भी intuitive है। उदाहरण के लिए, files से custom parsing code generate करना आसान है, जिससे दोहराया जाने वाला boilerplate हट सकता है, और compile भी तेज़ होता है
    बेहतरीन type system की वजह से Python की तुलना में अच्छी तरह लिखना आसान है, लेकिन performance C/C++ के बराबर है, और छोटे, standalone executable के रूप में deploy करना भी बहुत आसान है
    C, C++, ObjC, JS के लिए native ABI, शानदार FFI, और अच्छा Python interoperability भी है। मौजूदा ecosystem को फिर से लिखे बिना सीधे इस्तेमाल कर सकते हैं
    कल्पना करें कि ESP32 के लिए Python-style pseudocode लिख रहे हैं, जो बिना खास मेहनत के बेहद efficient है, और चाहें तो bare-metal control भी संभव है। उसी efficient language से backend और frontend दोनों वाला web app लिखते हैं, तेज़ bullet-hell game बनाते हैं, और जब तक explicitly न बताएं stack allocation होता है, इसलिए GC की चिंता नहीं करनी पड़ती
    business perspective से भी यह बड़ी value है कि Python की तरह तेजी से prototype बनाया, लेकिन वह पहले से ही production के लिए पर्याप्त तेज़ और lightweight है। यह कंपनी का secret weapon बन सकता है

    • game और कुछ ऐसे उपयोगों के लिए, जिनके बारे में विस्तार से नहीं बता सकता, scripting target के रूप में Nim इस्तेमाल कर रहा हूं। वजह यह है कि इसे C और C++ में translate किया जा सकता है
      नीचे के runtime यानी C environment को खुद manage करते हुए, उसके ऊपर JSON जैसी चीज़ों को first-class तरीके से अच्छी support देने वाली modern high-level language इस्तेमाल कर पाना वाकई अच्छा है। Python पसंद करने के बावजूद, Nim मुझे बेहतर और बेहतर Python लगता है
    • backend और frontend को उसी efficient language में लिखकर web app बनाने का मतलब व्यवहार में कैसे काम करता है, यह जानना चाहता हूं
      खासकर development के दौरान JS interoperability कितनी सुविधाजनक है, और क्या यह Nim को standalone library के रूप में JS में compile करने के स्तर से आगे जाती है। क्या Nim से browser API को सीधे call किया जा सकता है, या काफी simple wrapper से call किया जा सकता है?
    • ESP32 पर 22 kSPS ADC process करने वाले code जैसे मामलों में, जहां microseconds महत्वपूर्ण होते हैं, ईमानदारी से कहूं तो करीब 2 घंटे की tuning करनी पड़ी थी। उस समय मैं Nim अभी सीख ही रहा था, इसलिए काम मुख्य रूप से extra allocations से बचने का था
      फिर भी लगभग 4 सालों में कोई बड़ा performance regression या ज़रूरी बदलाव नहीं आया
  • संबंधित सभी लोगों और पूरी Nim community को बधाई। पिछले 10 साल से Nim को अपनी मुख्य language के रूप में इस्तेमाल कर रहा हूं, और Nim 2.0 की नई features मुझे बहुत पसंद हैं
    इनमें से कुछ मेरे projects के लिए सचमुच game changer हैं। उदाहरण के लिए, object defaults theoretical रूप से Norm[1] को object instances के साथ-साथ object types के साथ भी काम करने दे सकते हैं। नए जोड़े गए overloadable enums न होते तो Karkas[2] बिल्कुल संभव नहीं होता। हालांकि इस पर अभी काम चल रहा है
    [1] https://norm.nim.town
    [2] https://karkas.nim.town

    • हाल के changes में defaults मुझे सबसे ज्यादा पसंद हैं। वे कुल मिलाकर उपयोगी हैं और initialization boilerplate को और घटाते हैं, साथ ही enums जैसी चीज़ों में compile time पर valid state guarantee करना संभव बनाते हैं। शायद यह object variants पर भी लागू होगा
  • Nim software लिखने के लिए सचमुच अच्छी language है। तेजी से deploy कर सकते हैं, मज़े से develop कर सकते हैं, और फिर भी बहुत high-performance software बना सकते हैं
    हालांकि मेरे अनुभव में अभी भी कुछ sharp edges हैं। C/C++ compiler और options को मिलाना पड़ता है, error messages बहुत कमजोर हैं, और कुछ libraries केवल specific settings और systems पर ही काम करती हैं। फिर भी community छोटी है, यह देखते हुए बहुत दोष देना मुश्किल है। VS Code integration अच्छी तरह काम करता था और लगभग crash नहीं हुआ

    • बेहद खराब error messages और tools की कमी Nim की सबसे बड़ी समस्या हैं, ऐसा मुझे लगता है। इसके अलावा कुल मिलाकर यह शानदार language है
    • कम से कम error reporting हाल में बेहतर हुई है: https://nim-lang.org/blog/2023/03/31/version-20-rc2.html
  • अगर Manning Publications इसे देखे, तो अच्छा होगा कि नई Nim version पर किताब आए, और वे ज़्यादा पढ़ने योग्य font वाली अलग typesetting पर भी विचार करें
    मैंने Dominik Picheta की शानदार किताब खरीदी थी, लेकिन paperback में font इतना पतला था कि चश्मा बनवाने के बाद भी पढ़ना बहुत मुश्किल था, इसलिए मुझे PDF इस्तेमाल करनी पड़ी। strokes और stems जैसे font components बहुत पतले हैं
    मुझे लगा शायद उम्र बढ़ने की वजह से मेरी समस्या हो, इसलिए K&R 2nd edition की original copy से तुलना की, लेकिन वह किताब अब भी पूरी तरह पढ़ी जा सकती थी

  • Reddit ने इस बारे में लिखा है कि वे Nim का इस्तेमाल कैसे करते हैं: https://www.reddit.com/r/RedditEng/comments/yvbt4h/why_i_enj...
    अधिक से अधिक बड़ी कंपनियां और startups Nim को अपना रहे हैं। Nim 2.0 को लेकर बहुत उत्साहित हूं और योगदान देने वाले सभी लोगों का बहुत आभारी हूं

    • यह दिलचस्प है कि अधिक से अधिक बड़ी कंपनियां और startups इसे अपना रहे हैं। जानना चाहूंगा कि इससे जुड़े statistics या data हैं, या यह सिर्फ anecdotal बात है
      अगर anecdotal भी है, तो क्या कुछ कंपनियों के नाम बताए जा सकते हैं?
  • Nim काफी समय से मेरी पसंदीदा language रही है, और आखिरकार 2.0 release होने से मैं बहुत उत्साहित हूं। इस release के कई features का लंबे समय से इंतज़ार था
    एकमात्र downside, जैसा कि सबसे नीचे बताया गया है, यह है कि कुछ included modules को third-party repositories में move कर दिया गया है। यह बड़ी समस्या नहीं है, लेकिन SQLite support का library में built-in होना अच्छा था। अगर आप कुछ databases को support करना शुरू करते हैं, तो और database support के लिए दबाव बढ़ना तय है। हालांकि MD5 और SHA1 support तक हट जाना थोड़ा surprising है

    • “batteries included” library में आने पर library के stagnant हो जाने की संभावना रहती है। Python 90s से कुछ dead batteries ढो रहा है, लेकिन वहां इसकी जरूरत है
      paths या logging support का standard में होना अच्छा है, लेकिन कुछ चीजें third-party के रूप में रहें तो वे बेहतर evolve कर सकती हैं
  • इससे जुड़े सभी लोगों को बधाई। Nim सच में बहुत interesting language लगती है
    मैं काम में इसे इस्तेमाल करने की वजह खोजने की कोशिश कर रहा हूं। मेरा काम mobile के आसपास है, इसलिए JS और ObjC में compile कर सकना आकर्षक है, लेकिन अभी तक मैं इसे बस थोड़ा-बहुत try करने के स्तर से आगे नहीं ले जा पाया हूं। Rust की तुलना में इसे शुरू करना काफी सरल है

    • कुछ हद तक related, Denim का इस्तेमाल करके Node.js/Bun से Nim code call किया जा सकता है: https://github.com/openpeeps/denim
      यह Node addon बनाने के तरीके से काम करता है। web apps में Nim code reuse करने या performance-critical code के लिए उपयोगी है
  • कुछ महीने पहले मैंने Nim को देखा था, और features के लिहाज़ से इसमें ऐसी कई चीजें थीं जो मैं Python में चाहता। जैसे C/C++ के साथ आसान interoperability, static typing, compilation, Android/iOS के लिए cross-compile करके run कर पाना
    लेकिन language नई नहीं होने के बावजूद ecosystem छोटा है। Python के numpy, scipy, pandas, opencv जैसी high-quality libraries बहुत ज़्यादा नहीं हैं। यह अफसोस की बात है कि बड़े players इसे adopt नहीं कर रहे, और अच्छा होता अगर Unreal Engine अपनी नई scripting language Verse बनाने के बजाय Nim को adopt करके देखता
    एक और अफसोस की बात यह है कि C/C++ libraries के साथ बिना खुद adapter बनाए तुरंत interoperability मिलती। अच्छा होता अगर सिर्फ header import करना ही काफी होता
    Rust के साथ भी ऐसी ही आसान interoperability हो तो अच्छा होगा। इससे adoption बढ़ सकता है, क्योंकि Rust में high-quality cross-platform crates मिलना आसान है जो mobile devices पर भी बिना खास समस्या के चलती हैं
    डर है कि कुछ वर्षों में तेज़ हुई Python, GIL removal, nuitka, mobile के लिए briefcase आदि के साथ Python catch up कर लेगी, या Mojo Nim की जगह ले लेगा

    • Nim के पक्ष में कहें तो numpy, scipy, pandas, opencv, pytorch, tensorflow, keras जैसी विशाल machine learning ecosystem वास्तव में लगभग केवल Python के पास है। Python के अलावा किसी language में ML/AI style का काम करना सच में मुश्किल है
      फिर भी Nim में nimpy library है, जो Python के साथ लगभग seamless interoperability देती है। यानी PyTorch, scipy, opencv को बस import करके Nim में इस्तेमाल किया जा सकता है
  • यह जानना चाहता/चाहती हूँ कि क्या किसी को Nim और Zig दोनों को सच में इस्तेमाल करने का अनुभव है। सुनना चाहूँगा/चाहूँगी कि दोनों कैसे मिलते-जुलते और अलग हैं। Nim v2 के आधार पर दोनों भाषाओं के idiomatic web server benchmarks भी देखना चाहूँगा/चाहूँगी

    • मैंने एक hobby OS project में दोनों इस्तेमाल किए हैं। Nim[1], Zig[2] इस्तेमाल किया, और मुझे Nim कहीं ज़्यादा पसंद है। कोड संक्षिप्त और elegant है, और भाषा से जूझने के बजाय core logic पर ध्यान लगाने देता है
      Zig भी अच्छा है और मुझे optional value support और error handling का approach पसंद है। लेकिन !?[]u8 जैसी शोर-भरी syntax, जो uint8 multi-pointer के optional pointer के error union को व्यक्त करती है, मुझे खटकती थी
      dynamic allocation की ज़रूरत वाले ज़्यादातर code में allocator तैयार करके pass करना पड़ता है, यह भी core logic में बाधा डालता है। string concatenation या formatting जैसे छोटे काम भी काम बन जाते हैं
      Zig में dynamic dispatch भी नहीं है, इसलिए polymorphic code लिखना मुश्किल है, और किसी तरह की duck typing से workaround करना पड़ता है। आखिरकार मैंने तय किया कि Zig मेरे लिए सही नहीं है
      [1] https://github.com/khaledh/axiom
      [2] https://github.com/khaledh/axiom-zig
    • मैं अपनी C library के लिए auto-generated bindings Zig, Nim, Odin और Rust के लिए maintain कर रहा/रही हूँ। Rust bindings को ज़्यादा idiomatic बनाने के लिए निश्चित रूप से कुछ काम चाहिए
      examples को देखें तो लगभग वही code कई भाषाओं में लिखा गया है, इसलिए big picture समझ में आती है, लेकिन language features के लिहाज़ से यह सिर्फ सतह खुरचने जैसा है। उदाहरण के लिए Zig example comptime features इस्तेमाल नहीं करता
      Zig: https://github.com/floooh/sokol-zig/tree/master/src/examples
      Nim: https://github.com/floooh/sokol-nim/tree/master/examples
      Odin: https://github.com/floooh/sokol-odin/tree/main/examples
      Rust: https://github.com/floooh/sokol-rust/tree/main/examples
    • मैंने दोनों में programs लिखे हैं, लेकिन Nim इस्तेमाल किए काफ़ी समय हो गया। code लिखने में आनंद शायद Nim में ज़्यादा था
      Zig ज़्यादा boring है, लेकिन उसके सारे कारण अच्छे हैं। व्यक्तिगत रूप से मैं OS Nim में नहीं लिखूँगा/लिखूँगी, लेकिन Zig mature होने पर उस use case के लिए शानदार लगेगा। मैंने इसे embedded software में इस्तेमाल करना शुरू किया है
      Nim को मैं CLI tools, server applications, और शायद GUI applications और games के लिए भी इस्तेमाल करूँगा/करूँगी
      Zig team पूरी compiler infrastructure पर कहीं ज़्यादा मेहनत करती दिखती है, और अनुभव के आधार पर यह सचमुच impressive है। इसमें बेहतरीन innovations हैं
    • मैंने Nim और Zig दोनों को नए projects में इस्तेमाल किया है। खास differences बहुत हैं, लेकिन सरलता से उनकी विशेषता बतानी हो तो Nim, Python जैसी Swiss Army knife को compiled language बनाने की कोशिश के ज़्यादा करीब है
      Zig कहीं ज़्यादा focused language है, जो C के successor और replacement के एक खास niche को target करती है, और उस लक्ष्य को बहुत अच्छी तरह पूरा करती है
      मेरे हिसाब से language preference इस बात पर निर्भर करती है कि आपकी मौजूदा language आपकी कौन-सी व्यक्तिगत needs और इच्छाएँ पूरी नहीं कर पा रही। मुझे C successor को target करने का approach दिलचस्प लगा, इसलिए मैं Zig की तरफ टिक गया/गई, लेकिन समझता/समझती हूँ कि दूसरे लोग Nim क्यों चुनते हैं
    • Zig का TechEmpower Benchmarks implementation दिखता नहीं है, लेकिन Nim का है: https://www.techempower.com/benchmarks/#section=data-r21&l=y...